Steve Cotton 0ba433203e 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.
2021-01-09 09:13:41 +01:00
2020-12-31 23:59:28 -06:00
2020-12-29 13:34:14 +01:00
2020-11-19 16:49:32 -03:00
2020-11-08 23:41:21 -05:00
2020-12-10 16:43:46 -06:00

License: GPL v2

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.

https://www.wesnoth.org/

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:

https://forums.wesnoth.org/

Description
韦诺之战
Readme 10 GiB
Languages
INI 51.6%
C++ 35.9%
Lua 5.7%
Python 4.3%
Emacs Lisp 1%
Other 1.1%