It turned out that alot of compilation units were using resources
but not including the header, and only getting circuitously
through the display.hpp header which got it from unit.hpp. This
is an improvement since unit itself doesn't need the header,
and most classes probably don't either.
std::vector<std::pair<k,v>> has worse look-up performance than
std::map<k,v> in general, not that the difference is too noticeable for
such a small dataset like campaignd's handlers table, that is built in
such a way its items are arranged in descending order of usage
frequency.
It still feels like this is the best thing to do to keep future
maintainers sane.
Fixes the minimap buttons sans the minimap unit/village drawing pair
being in an indeterminate overlay-less (blank) state for the duration of
the initial 'start' WML event in scenarios, unless they are interacted
with first.
set_button_state() has to be called after play_controller::init_gui()
finishes because that method calls game_display::begin() game first,
which in turn instantiates the theme UI GUI1 buttons. Notice that
set_button_state() is also called when the End Turn button is enabled
(e.g. after 'start' is finished).
The reason I'm not calling this from play_controller::init_gui()
directly is that I am concerned about possible interactions with the
replay_controller, which currently seems to do even sloppier work of the
GUI before the end of the 'start' event. I might move this call there if
that issue is sorted out, since it'll be needed for the
replay_controller anyway.
After this commit, the replay_controller constructs
tod_manager_start_ using the same parameters as the play_controller
constructs tod_manager_. So the copy construction after this is
superfluous.
https://github.com/wesnoth/wesnoth/commit/84556b11
According to valgrind, the tokenizer::next_token function is called
several million times during a typical unit test. This commit
changes the parser to allocate the tokenizer as a member variable
of the class (on the stack) rather than on the heap using new,
thus it eliminates millions of calls to new.
This allows the synthetic add-on name to be used in the absence of an
[info] title= attribute, e.g. for add-ons downloaded with older versions
of Wesnoth or wesnoth_addon_manager.
This is needed to properly parse a list of locations from strings,
to have the dimensions available.
This allows to refactor tod_manager and not use resources:: ptrs
in its implementation, instead using the objects from the relevant
context.
Because the odds of someone altering the early init sequence in the
future and failing to realize the purpose of this code aren't low
enough. (I really should've included it in the main commit.)
Not being able to initialize fonts is usually the direct consequence of
a failure to read data/hardwired/fonts.cfg, possibly because the game
data dir was incorrectly set or detected. Thus, it's the ideal point
during early initialization to provide a hint on stderr for players.
I specifically avoided mentioning anything about "installing" the game
so as to not contribute to the common misconception that the game needs
to be installed to run.
get_wml_location() returns an empty string on failure, and there is
really no point in calling preprocess_file() on that -- it only results
in a confusing error message.
Replaces this sequence often found when Wesnoth can't resolve the path
to its data directory:
20140612 23:37:05 error filesystem: Trying to open file with empty name.
20140612 23:37:05 error config: Could not open file
could not initialize fonts
... with the following one:
20140612 23:38:52 error font: could not resolve path to fonts.cfg, file not found
could not initialize fonts
... which should be a little bit more helpful in pointing users in the
right direction in the aforementioned case.
This commit adds virtual functions covering "observers",
"displayed_unit_hex", and "playing_side", in display:: object.
This allows to avoid dynamic casts in the reports.cpp file, and
to eliminate a header. It avoids the possibility of segfault when
using the editor if the reports context isn't set up correctly.
This allows to remove all remaining resources:: links from the
reports generator code, and to finish removing several expensive
dependencies from that compilation unit.
It uses a shared_ptr, to prevent crashes during play_controller
initialization. But it only holds a weak_ptr, to preserve
previous behavior of skipping whiteboard ops when the ptr is
NULL.
It requires also for us to construct the whiteboard before
constructing the gui, so that we have a valid pointer to pass.
Most likely all of the managers will have to be moved forward,
in this commit we move forward the whiteboard and pathfinding
module, anticipating future commits.
If we try to send a message immediately after signaling SIGHUP to
wesnothd, it won't get caught by wesnothd, probably because the control
socket is being reopened just as the message arrives. Thus, we need a 1
second delay after the signal.
This was fixed in production a while ago but I forgot to commit the
change.
At least on baldras' version of screen, the stuff command argument here
absolutely needs to be wrapped in single or double quotes to work.
I actually fixed this months ago but forgot to commit.
