These now work:
[resistance_defaults]
id="special_res_for_test"
default="30"
[/resistance_defaults]
[resistance_defaults]
id="copy_of_arcane"
default="(arcane)"
[/resistance_defaults]
and so do these:
[terrain_defaults]
id="special_terrain_for_test"
[movement_costs]
default="(swamp_water + 1)"
orcishfoot="(vision_costs.swamp_water * 2)"
[/movement_costs]
[/terrain_defaults]
[terrain_defaults]
id="special_terrain_for_test"
[defense]
default="(20 + 7 * movement_costs.special_terrain_for_test)"
[/defense]
[/terrain_defaults]
For [terrain_defaults], I've approached it as a new feature rather than a
simple fix. The subtags now use the same names as the [movetype] subtags and
[effect]'s `apply_to` attribute, so [terrain_defaults][movement_costs] instead
of [terrain_defaults][movement].
The formula handling will now recognise "resistance", "movement_costs",
"vision_costs", "jamming_costs" and "defense". For [resistance_defaults], the
formula will recognise both "(arcane)" and "(resistance.arcane)" as equivalent,
similarly for [terrain_defaults] "(swamp_water)" is a shorthand for whichever
subtag is being patched.
A [terrain_defaults] tag may use data added in a previous [terrain_defaults],
as in the examples above where the second tag's [defense] is based on the first
tag's [movement_costs], this gives orcish grunts on the special terrain a 62%
chance to be hit. However, relying on data in the same [terrain_defaults] that
creates or changes it is unsupported - if the [movement_costs] and [defense]
were in a single [terrain_defaults] tag then the result would be implementation
defined, because no guarantee is made of the order in which the children of the
tag are processed.
The schema gets fixed for [resistance_defaults] and [terrain_defaults], as it
only allowed one instance of each tag. The subtags of [terrain_defaults]
already had the new names.
In the schema's MOVETYPE_PATCHING macro, the default= key is mandatory except
for the types that fallback to using movement costs as their default. The tag's
implementation doesn't need it, however omitting it seems more likely to be
an oversight than a deliberate use of an edge case.
This was taken from the value in game_launcher, which was set to true if commandline_options::editor was set.
This uses that value instead of passing in the flag manually, which is consistent with the other defines.
This also removes game_launcher::jump_to_editor since it's no longer needed.
It didn't really make much sense to keep it here. The manager singleton is now local to its implementation
and initialized in game_config_manager::init_game_config like the credits data.
Turns out the add-ons client currently sends from_version= with a
non-empty string value even if the add-on being downloaded isn't already
installed (the default version_info string, "0.0.0").
This reverts commit 7d02fc884bd360d125acad4f7922e58c245ea16a.
Fixes#5411.
No need to continue since we're already at the end of the loop. Regardless of the return value,
we want to loop again, in which case break handles that just fine.
So far this return value isn't actually really used for anything, but it's better to have it
return true on success than false in all cases (including error conditions).
I'm not sure in what case game_launcher::load_game would return false here (I don't know if any of the exceptions
it catches can even be thrown from that code, for instance), but if for some reason that happens we don't want to
continue loading.
