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.
this fixes remove_modification for these effects, and also a bug where these effect would be applied twice after a unit advances.
fixes#3264fixes#3220
This also changes the implementation of [unit_overlay] to use [effect]s now so tht changesdone via [unit_overlay] ae persistent as they were before.
* WML: Support [filter_side] in [item].
If [filter_side] is present then "team_name" is ignored.
Fixes#1477.
* WML: Compare [item]team_name to [side]team_name using intersection.
Fixes problems with substrings and when one or the other is a
comma-separated list. See #3533
* WML: Rename [item][filter_side] to [item][filter_team]
* Add changelog entry
(cherry-picked from commit 3a3b752881)
This prevents the animator from holding a strong reference to the target unit, which was keeping the unit object alive and thus preventing the unit halo, if any, from disappearing.
(cherry-picked from commit 7d6e2b2a10)
This avoids a reference to the unit from being leaked, which prevented the
unit's halo (if any) from disappearing when the unit died.
Fixes#3509. Closes#3520.
(cherry-picked from commit e63bd35f9d)
