Always use the "slow path", because it stores and unstores the unit, triggering
the desired side effects of unstoring a unit.
Fixes issue #5133, and tests that with the new unit test.
Fixes bug #4978, that changing the facing wasn't updating the display.
This corresponds to 1.16's commit 13c5d8a96ead8d2a7f0435f60b8ec7f7e0af0972,
that commit merely disabled the fast path to be a minimal change.
- place_shroud and remove_shroud no longer accept a shroud data string or the special string "all"
- new functions are added to convert between lists of locations and shroud data strings
- place_fog, remove_fog, is_fogged, and is_shrouded aren't changed, only moved
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.
