The bug introduced in fcd0ceda is fixed by ensuring that movetype::merge() is
called with the strings "movement_costs", "vision_costs" and "jamming_costs"
instead of "movement", "vision" and "jamming".
Both [terrain_defaults][movement] and [terrain_defaults][movement_costs] are
supported and equivalent, as added to the master branch in 3522eb2c.
These now work again:
[resistance_defaults]
id="special_res_for_test"
default="30"
[/resistance_defaults]
[resistance_defaults]
id="copy_of_arcane"
default="(arcane)"
[/resistance_defaults]
[terrain_defaults]
id="special_terrain_for_test"
[movement]
default="(swamp_water + 1)"
orcishfoot="(swamp_water * 2)"
[/movement]
[/terrain_defaults]
Formulas can now access other parts of the movetype too, as this allowed the
code to be the same as in 1.15:
[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]
The formula handling will 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 unit tests for [terrain_defaults] and [resistance_defaults] must stay
out-of-tree until we support some method of testing them without affecting the
core units' stats during other tests. The test added here is limited to
checking the ways that WML can read the stats, it's also a framework for the
out-of-tree parts to use.
This is a squashed cherry pick of these commits from 1.15:
* 72863e578b (the unit test)
* 0ba433203e
* 3522eb2c2a (adding the aliases)
* 0035b776d7 (fix for empty children)
This directory contains both the scenarios used by C++ unit tests and those which are
WML unit tests.
For the C++ unit tests, it is recommended to reuse the same scenario file as much as possible
and just inject WML into it.
Injection can be done by adding a config object containing event code and then registering that
manually for game_events.
WML unit tests are self-contained scenario files to test a specific area of WML. They can be
implemented with the GENERIC_UNIT_TEST macro.
2b8e887bcf