- 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
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.
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
Without this, the AI always starts with whatever it considers the best unit without taking the level bonus into account. This mostly only matters when one sets high_level_fraction to a very large value (1 or larger) in order to force only high-level recruits. In other cases it makes no, or no significant, difference.
This also sets its default value to zero, in order to have consistent default behavior with versions from before this parameter was introduced.
It also provides a macro so that the ExpAI can be used with custom parameters in a scenario config, and adds high_level_fraction as an optional parameter to the Recruit Rushers Micro AI.
Because unit cost is penalized in the ExpAI, it recruits almost no higher level units. This adds a bonus for such units to be recruited at approximately the ratio defined in 'high_level_fraction'.
Ths is the enemy type list to be considered if the AI has no information about the enemies to expect, that is, if no enemy units are on the map and no enemy recruit lists can be found. It can be used to prepare AI recruiting for enemy sides that get added later during a scenario.
This is done for consistency with similar functions in mainline, and so that the function actual returns what it name says. This breaks backward compatibility, but note that the only practical difference for that is the order in which the arguments are returned, as both 'closest_enemy' and 'location' contain the enemy location in .x/.y format.
The relative ranking of the CA scores is not changed, except for one case when two CAs had the same score.
Reasons:
- All scores should be lower than the scores of the default Goto CA (200,000) and the default scores of most Micro AIs (300,000).
- Break tie, resulting in uncertain order of execution, of place_healers and retreat_injured CA. Healers should be placed first, to allow retreating injured units to adjacent hexes.
- Set default for generic_recruit_engine to slightly above default AI recruiting score. That way it takes effect even if the default CA is not removed.
- Increase move_to_any_enemy CA score from 1 to 1,000. It is still the lowest score that way, but allows for setting up custom CAs with even lower scores (even if it is just for end-of-turn statistics or the like).
(cherry-picked from commit 35ba82050954c2cee86321e05d6706993c08e143)
This involves making the output independent of the stats CA (which is not used any more) and adding missing output to some CAs.
(cherry-picked from commit c2635abde1c6eea8bb74019ab78c61bddb219fff)
... unless there is a difference between nil and false. Done mostly for consistency with all the other uses.
(cherry-picked from commit 35d257f8fd35fad70539dfdc57da69e38bc10536)
The engine will refuse to recruit on shrouded hexes, which will result
in part or all of the rest of the AI actions to be disabled. Fogged
hexes may cause problems also if there is an enemy unit on them.
This fixes at least part of bug #25112.
This caused an error message and recruiting to be abandoned when the
recruit rushers Micro AI was used for two different sides in the same
scenario. It was only presents since the AI refactoring done during
1.13.4+dev and did not affect any release.
