There's also a "translate" attribute which is missing in the schema,
this commit deliberately omits it as it was for WesCamp.
The commit comment in e6d1595f8 is wrong - the validator does complain
about the error fixed in that commit, I'd missed the --use-schema option.
Explicitly use t_str() to avoid an ambiguous construction from
7bee8ee157, which made GCC9 error out because it
could alternatively use t_string::t_string(const string &).
Resolve the merge conflict from 26d1ca7a7d
Adding this is issue 2 of #4177, changing the behavior when [find_path]
is given a SLF which matches multiple hexes.
The map and tests here should be easy enough for manually editing them. It
duplicates some of the functionality of the existing characterize_pathfinding
tests, however those tests need their expected values to be calculated and
can't be changed by hand.
'''nearest_by''': {DevFeature1.15|2} possible values "movement_cost"
(default), "steps", "hexes". If the [destination] SLF matches multiple hexes,
the one that would need the least movement points to reach may not be the one
that's closest as measured by '''hexes''', or closest as measured by steps,
from the starting point.
Behavior in 1.14 depended on which hex was checked first.
The feature was never added, a deprecation message saying that it's been
removed is the closest option to the situation. While terrain.cpp itself
supports vision_alias, it was never added to the calculations in movetype.cpp,
therefore it never affected units' vision. It's also not shown in the help
about the terrain.
This doesn't affect the features of units having vision costs different to
movement costs, or of units having a different number of vision points to
movement points, both of which are still supported.
While I'd encourage anyone who wants to implement vision_alias to do so, at the
moment I feel that the still-supported features in the same area haven't been
explored yet, and that vision_alias isn't going to developed before 1.16.0 is
released.
Fixes#4253.
The schema's validation of ranges now rejects negative numbers, because the C++
code doesn't support them (both before and after this commit):
* utils::parse_range("-7") will return {0,0}, because std::stoi("") throws invalid_argument.
* src/map/location.cpp will parse it as -7, but that will never match an on-map coordinate
Possible fix for #4058, with the following logic:
* If non-empty, [unit]overlay= is handled by adding modifications
* unit::write will always output an empty overlay=
* The Lua API's get_units() will still provide the list of overlays
* [effect]apply_to=overlay can now remove as well as add overlays
* [remove_unit_overlay] is implemented with [effect]apply_to=overlay
Using [object]s with durations hasn't been tested, but expected effects:
* An expired add= followed by a non-expired remove= will simply cause the remove=
to have no effect when std::remove(overlays_ ...) is called.
* A remove= followed by [remove_unit_overlay] cause the [remove_unit_overlay] to be a no-op,
and the overlay will reappear when the first remove= expires. This edge case is already
documented as unsupported on the wiki.
This makes [movetype] consistent with [unit]. The code in movetype.cpp is used
for handling both of those tags and so already had support for "flying" in the
merge() and write() functions.
This shouldn't be backported to 1.14. For this reason, it also includes
handling the C++ todos to use C++14's std::make_unique.
1. Allow carryover_percentage & carryover_add with
victory_when_enemies_defeated=no. Code from newfrenchy83
2. Allow use of current_time in [time_area].
When multiple negative heal abilities are present, the game now
chooses the ability with the lowest value. The leadership ability
now also uses the same get_composite_value function that is also
used by most other abilities
This adds running the WML schema validation in travis. It also updates the schema itself and fixes a few WML errors so that core and all campaigns under all difficulties pass the schema validation.
