These functions are not used anywhere, and they have other issues besides the one fixed in this commit – they're implied to return all moves, but they only return one move for each possibly destination hex. However, this will make them at least be minimally usable.
I used level 3 deprecation because this is something that was intended for internal use in the ai_helper module, and the ai_helper module itself is not an officially stable API
The passed filter needs to be enclosed in an [and] tag, otherwise the check for visibility might not work correctly, for example if the filter contains a top level [or] tag.
- 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
If a unit is passed as the last argument to this function, the returned hex is supposed to be passable for that unit. Hexes on the map border need to be excluded in this case.
This specifically also fixes a bug in the Messenger Escort Micro AI. Previously, waypoints right at the map border could sometimes lead to the AI showing an on-screen error message and becoming inactive.
This fixes the case when the unit cannot reach the previously found next_hop location from the ideal next_hop location in the part of the code that tries to keep units from moving in single file.
Before the recent change, the ability type (tag name) was checked. It then got changed to ability id. This commit changes it back to the old behavior.
For the record, there are situation when either the id or the type is needed. In addition, one sometimes wants to check wheter the ability is active (or will be active). Thus, no matter how this is done, neither will serve all purposes and sometimes other functions/functionality should be used. This commit does, however, restore the previous behavior and thus preserves backward compatibilty.
In addition to 'yes' and 'no', comma separated lists of leader ids are now also accepted as values for these aspects. This allows setting the behavior only for specific leaders.
I switched to using defense_on() and resistance_against() incorrectly in 55478e20. I had tested these, but apparently for cases when it does not make a difference ...
The change for movement_on() is for convenience and consistency with other code only.
Note that we do not add an 'ignore_units' option, as allies and enemies are taken into account in different ways and we want to have a way of ignoring each type individually.
... as opposed to lining up if there are allied units in the way.
This changes (fixes) the default behavior. An optional 'no_fan_out' parameter is provided in order to restore the old behavior.
