Previously, a rabbit hole item on the map border could be selected for spawning a new rabbit, resulting in an error message on screen and abandoning the CA for the rest of the turn.
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.
It is too different from previous default recruiting and would significantly affect scenario balance. It also currently does not work with multiple leaders and many of the aspects. It will be made available as an option (and is already in the Experimental AI) after these shortcomings have been fixed.
The algorithm used in this CA is too simple to work reliably in a general setting, it tends to send whole groups of units toward small numbers of villages, or even individual ones. In its current version, it should not be used at all, not even in the Experimental AI. The recommended way to emphasize village hunting is to set the village_value aspect to a larger-than-default value and let the move-to-targets CA take care of it.
We are, however, leaving the CA code and the macros in place for potential future work.
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.
The old villages CA is quite a bit better at distributing multiple units across multiple villages. The advantage of the new grab_villages CA is that it has a variable score, sometimes grabbing villages before, and sometimes after attacks. This does not outweigh its shortcomings though.
So for now, the default AI will continue to use the previous CA, and the Experimental AI will use the new one. Thus, the two AIs are not quite identical any more (but still very similar).
I also added a todo comment that the grab_villages CA might be reinstated if it is improved.
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.
It is now identical to the default AI, so we only show it in debug mode in the MP computer player selection menu. It will be moved back to be always available when there is new development happening.