The old names still work but are deprecated.
In addition, all the moved functions now accept either a side number or a side userdata as the first parameter.
This reverts commit 51d6402453.
After discussion with @gfgtdf it was determined that this is not a useful feature after all, since it was in fact the default behaviour for the optimized path.
This means that they are now added to the interface module by default in C++, and only duplicated to the Wesnoth module in Lua.
Some additional functions were moved:
- wesnoth.scroll -> wesnoth.interface.scroll
- wesnoth.zoom -> wesnoth.interface.zoom
- wesnoth.get_mouseover_tile -> wesnoth.interface.get_hovered_hex
- wesnoth.color_adjust -> wesnoth.interface.color_adjust
- wesnoth.set_menu_item -> wesnoth.interface.set_menu_item
- wesnoth.clear_menu_item -> wesnoth.interface.clear_menu_item
Added wesnoth.units.get_hovered as an alias of wesnoth.interface.get_displayed_unit
Also backtracked the removal of wesnoth.get_recall_units, which is now available as wesnoth.units.find_on_recall - it's just more convenient than passing x=recall to wesnoth.units.find
This means that they are now added to the units module by default in C++, and only duplicated to the Wesnoth module in Lua.
Some additional functions were moved:
- wesnoth.create_unit -> wesnoth.units.create
- wesnoth.get_units -> wesnoth.units.find
- wesnoth.get_unit -> wesnoth.units.get
Deprecated wesnoth.get_recall_units in favour of wesnoth.get_units, which has gained the ability to match units on the recall list if x="recall" or y="recall" appears in the filter at toplevel.
The wesnoth.units module now acts like a metatable for unit userdata, meaning that any functions (or attributes) added to the module will be visible through any unit.
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.
