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.
While making it work would be better, this is a minimial change to at least
get the developer back on track instead of wasting time trying to work out
why putting this in a campaign's _main.cfg file doesn't work:
#ifdef ENABLE_CAMPAIGN_TESTS
{./test/}
#endif
I'm sure that these asserts are already unreachable, as the caller will be
passing in a valid member of the scoped enum; the asserts are just helpers
if adding another value to the enum. However, omitting the return statements
can trigger a compiler warning, so add them.
There's no need to check anything if we are in read-only mode.
Additionally, we want to get the auth and blocklist checks out of the
way early so we don't waste time on potentially complex archive scans.
This changes startup behaviour slightly so that campaignd ensures that
the directory containing the config file exists before doing anything
else. Normally this wouldn't be noticeable since the default behaviour
continues to be to use ./server.cfg (pwd should exist, right?), but it's
important in the event that the user passes -c with a nonexistent path.
We do still create the server.cfg file later anyway, and it's still
possible that the directory containing it disappears in between only to
be forcefully created by ostream_file() -- but who cares, this is all
just meant to be an early reality check to avoid user mistakes.
