
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.
About
The Battle for Wesnoth is an Open Source, turn-based tactical strategy game with a high fantasy theme, featuring both singleplayer and online/hotseat multiplayer combat. Fight a desperate battle to reclaim the throne of Wesnoth, or take hand in any number of other adventures.
License
Please see the wiki for information regarding The Battle for Wesnoth's licensing:
https://wiki.wesnoth.org/Wesnoth:Copyrights
Installing
See INSTALL for instructions on how to build the game from source code.
More Information
For extensive documentation about all aspects of the game, see the official Battle for Wesnoth web site.
A (translated) description of how to play the game can be found in doc/manual/manual.*.html, or online at:
https://wiki.wesnoth.org/WesnothManual
The official Battle for Wesnoth Forums (with over 400,000 posts from more than 20,000 registered members) can be found at: