this also makes a small change in the savefile format: [endlevel] ->
[end_level_data] in snapshots.
we still have the "store_carryover" function in playcampaign.cpp which does the visual message.
Note that the real carryover happens after linger mode while that message happens before linger mode this simplifies linger mode saves.
we move code from playcampaign.cpp to saved_game.cpp
we also change the savefile format so that ingame savegames don't
contain [carryover_sides_start] anymore becaus all that was already
merged to both [snapshot] and replay_start.
This commit is likley to break something. If so that will be fixed in
later commits.
This test was broken in this commit
342ff4f718d678bea50419f11ad7d9a6ad1e7d58
We need to rerun the characterization to test to get the new
correct values, or it will fail. I'm disabling in the meantime.
After this commit e4eb0a3ede83ee338994708ebd48257627b47242 the
replay viewer would segfault during prestart events. However, it
turns out that nothing in the replay viewer, or in that commit,
was directly causing the segault. Instead, the display object
was holding dangling pointers for no reason, when it could have.
been simply computing the correct value (very cheaply). We clean
up the code in the display objects to fix the segfault.
game_display and display versions of set_team were identical, in
header and in implementation, so we simply delete the game_display
one, as a strict refactor.
This use of handle-body idiom saves *alot* of includes, since a
huge number of objects include unit indirectly, and make no use
of the ai formula features.
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.)
