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.
now wesnoth.require is able to detect when the same file is
required two times using different names (like a/../a/b.lua
a/b.lua) and will only execute it once.
for this a new function wesnoth.canonical_path was added
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.
now modify_unit no longer causes the full rebuild of the unit unless it
is really needed, this is not only faster, it also prepares a future
optimisation in reducing the units size in savegame files.
