[wesnoth-commits] [wesnoth/wesnoth] 0ba433: Fix [resistance_defaults] and [terrain_defaults] (...

Steve Cotton noreply at github.com
Sat Jan 9 08:13:54 UTC 2021


  Branch: refs/heads/master
  Home:   https://github.com/wesnoth/wesnoth
  Commit: 0ba433203e508478fff7f79f7fcb64d186ba40e7
      https://github.com/wesnoth/wesnoth/commit/0ba433203e508478fff7f79f7fcb64d186ba40e7
  Author: Steve Cotton <steve at octalot.co.uk>
  Date:   2021-01-09 (Sat, 09 Jan 2021)

  Changed paths:
    M changelog.md
    M data/schema/units/movetypes.cfg
    M src/movetype.cpp
    M src/units/types.cpp

  Log Message:
  -----------
  Fix [resistance_defaults] and [terrain_defaults] (issue #5308)

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.





More information about the Commits mailing list