Previously it calculated max movement, and then added the adjacent hexes. This
version should correctly handle:
* units with vp different to max mp
* units with vision costs different to movement costs
* jamming by enemy units
Draft changelog entry for this:
* `[store_reachable_locations]range=vision` now calculates vision, instead of using movement costs and max movement points (issue #4179)
- get_terrain and set_terrain replaced with direct indexing operations
- get_map_size mostly replaced with either the iterator or an on_board call.
Only a few cases really needed to know the size of the map for some other purpose.
- shroud and fog operations, village owner, time areas, and location filters
- get_terrain_info replaced with terrain_types table
- Map generation functions create_map and create_filter
returns all items on a locations, this allows is to
remove quite a bit of code in the dropping.lua file
of world conquest since that can now just use items.lua
instead
This adds an additional `test_result` attribute to [endlevel], intended for use with the automated unit tests. This allows for the unit tests to differentiate a pass/fail result separately from scenario victory or defeat, which allows for more accurately determining the outcome of a test as well as addresses the potential, for example, for a scenario to be expect to pass because of the {SUCCEED} macro but instead passes because the scenario ended as a victory through some other method.
Additional unit tests which were the original motivation for this change are also added as part of this. They test, as much as possible, that events are executed at all, and are then also executed in the expected order.
One of the cases fails due to something in find_vacant_tile - perhaps someone else can figure out how to fix this?
If nothing else, setting check_passability=no in the [move_unit] should do it, but I'd prefer not to have to do that...
Also extend the unit test to at least check the end result of comma-separated
values, as there was previously nothing testing the effect of providing more
than one value.
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.
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
