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.
Previously the CA would already move multiple leaders if all leaders were to be moved, but it would abandon moving any leader after finding one that should not move.
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.
This lets the AI find paths around areas defined by [avoid] tags, rather than being stopped dead by them. See comments in the code for details.
The relevant custom cost function, custom_cost_with_avoid(), can be accessed directly as well.
This adds the correct behavior for the castle_switch, move_to_any_enemy and place_healers CAs. It was already in place for the other former ExpAI CAs (except for recruiting and spread_poison, for which it does not apply).
This automatically also adds this behavior to the Healer Support Micro AI.
This allows restricting each CA individually to only a subset of the units. It also means that several instances of the same CA can be used in the same AI configuration, in order to, for example, force the order in which units are dealt with, or to apply different settings to different units.
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'.
