- 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
This includes several improvements to the retreat hex evaluation:
- Enemy threats are not the dominant rating contribution any more
- Enemy threats are based mostly on HP balance, rather than simply enemy number
- Enemy threat assessment can be modified with the retreat_enemy_weight aspect
- By default, only healing locations are considered as retreat locations, but this can be overridden with the retreat_enemy_weight aspect
The main problem was that the previous calculation was based on the 'caution' aspect. While that is not technically wrong, caution is also used for other purposes and there are mainline (and presumably UMC) scenarios that use large values for caution. In those cases, units retreated that were barely injured. This, again, might even be desirable for some use cases, but it needs to be decoupled from the other uses of caution. Thus, the new 'retreat_factor' aspect is used now.
In addition, the calculation is now based on a unit's maximum hitpoints, rather than its level.
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.
