When returning std::unique_ptr instead of raw pointers, the return type can't
be a co-variant, which is why the clone() functions are all being changed to
return the base class.
All of the instances of editor_action_ptr were replaced, except those in
commented-out code. Many of these replacements were with the `auto` keyword;
for the others the reason that I didn't use editor_action_ptr was that I find
`std::unique_ptr<editor_action>` quicker to read than remembering if
editor_action_ptr is a unique_ptr, a shared_ptr or a plain raw pointer.
A large amount of commented-out code in mouse_action_item.cpp and
mouse_action_unit.cpp gets removed, but the commented-out code in
action_item.cpp is left for a future refactor. I think the classes in these
files should end up being refactored with the responsibilty for putting items
on the map moving from mouse_action_item.cpp to action_item.cpp, leaving only
the parts specific to the input method in mouse_action_item.cpp. However,
that's for a separate commit (and separate PR).
Dune Rider xp changed from 42 to 47.
Sunderer line dodge on hills changed form 60% to 50%.
Scorcher gold cost changed from 23 to 25.
Dragoon gold cost changed from 27 to 28.
Elvish Rider gold cost changed form 32 to 28.
Grek and his units are on the left corner of the screen,
the same place where the portrait is overlayed.
Better using the right side for Grek's portrait.
The previous setting is horribly inconsistent with existing practice in
this project, as well as the clang-format tool configuration included.
[ci skip]
Instead of trying to concatenate translatable strings, just make a single full
string to be shown in the recruitment dialog. This came from trying to update
the i18n hints, and realising my suggest of making the swimmers "Merfolk" in
f6dc83375 was causing problems when they could also be nagas.
These strings are stored in a variable at the start of the campaign (in
ZOMBIE_INIT), so won't appear when loading an existing save game. This is why
the Lua script keeps some support for the old names (although they're not going
to be translated in that case).
This is a bit redundant but if you want a partial download then you are
most certainly updating something that already exists on your end, so
no, you don't get to bump the download count that way even you leave out
increase_downloads= somehow.
The previous implementation here didn't actually use the from/to version
bounds when building the delta pack sequence. So... let's fix that so
people aren't forced to receive a bogus delta that invariably contains
the changes from the earliest uploaded version to the latest.
This makes the code easier to follow, hopefully, and quite importantly
avoids an unnecessary copy while building the update pack sequence.
It does away with the size report for deltas in stderr because it's
inaccurate by design -- it's the sum of the individual packs' compressed
sizes rather than the size of the compressed result (which we cannot
determine in advance.)
While testing this I ran into an issue where apparently someone didn't
implement the from/to version logic for the update pack sequence, who
knew. Gotta fix that later I reckon.
Fixes#5256, which was that `{SAVE_ZOMBIE_LIST rastabahn_zombies}` overwrote
the ardonna_zombies variable.
Move the MERGE_ZOMBIE_LIST code to be next to the LOAD and SAVE code, as any
change to one of these functions should probably be done to all of them.
This doesn't change the behavior - the changed line is in a conditional block
which tells us exactly which of scenario_id()'s code paths will happen, and it
will still end up using carryover_["next_scenario"]. The change is just making
it consistent with the way that other lines in expand_scenario() find out which
scenario id to use; it's preparing to load the next scenario, so it should use
that scenario's id to load any metadata, not the current scenario's id.
Also, scenario_id() should be const. This helps with refactoring out the
existence of a de-facto singleton instance of saved_game.
