Previously, the Micro AI behavior was inconsistent at best when it came
to dealing with these units and could even result in AI errors when an
AI unit was ambushed or a petrified unit was in the way of a move. Now,
both types of units are properly "ignored" and the AI moves have been
made robust against unexpected events such as ambushes. Incidentally,
the latter also makes the AI more robust against WML events doing
things the AI cannot know about (such as removing units).
This is done because the code will not complain but silently produce
non-sensical results if, for example, the filter is passed as the first
argument to get_visible_units().
There is essentially no time saving involved with doing it all in one
execution as all tables need to be reevaluated for each unit anyway in
order to adapt to potential changes due to ambushes or WML events. (The
latter is not all done yet, will be added in a follow-up commit.)
There is essentially no time saving involved with doing it all in one
execution as all tables need to be reevaluated for each unit anyway in
order to adapt to potential changes due to ambushes or WML events. (The
latter is not all done yet, will be added in a follow-up commit.)
Previously, some functions saw invisible units, while others did not.
Moreover, this behavior could be triggered on and off for some
functions, but not for others, and the parameter to do so was not the
same in all cases.
Now, the default setting for all ai_helper functions is to ignore
invisible units and this can be turned on and off with the same
parameter, viewing_side, with the same syntax and meaning as for the
built-in functions wesnoth.find_path() and wesnoth.find_reach(). This
means hat it can be passed directly between those functions and all the
ai_helper functions.
Attackable enemies are defined as visible (can’t attack it if I can’t
see it) and not petrified.
This is in preparation for making the Micro AIs deal correctly with
hidden and petrified enemies.
If this is not done, there are some rare cases in which a Lua AI might
get caught in an infinite loop by trying the same failed action over
and over again.
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.
Because the attack simulation during CA evaluation is done with enemy
XP set to zero, the AI previously sometimes chose a different weapon
during execution than what was used for evaluation. This resulted, for
example, in archers sometimes attacking an enemy without ranged attacks
with their melee attack when aggression=1.
This means:
1. Adding the new CA to AI configs
2. Removing it whenever the combat CA is removed
3. Preventing conflicts for AIs that previously used overlapping scores
This CA performs attacks on enemy units so close to leveling that the
default AI's combat CA would not attack them (with some exceptions).
This is meant to keep players from being able to exploit this known
weakness of the default AI.
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.
- For MAIs using aspects, make the facet ID more unique
- Only shallow-preparse the [micro_ai], rather than fully preparsing it
(This is so that filters in Micro AIs can use $this_unit if needed)
