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().
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 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.
This changes the following:
- Fixes the experimental AI, without changing any of its code except for that in the [engine] tag
- Returns a dummy self from the dummy Lua engine, so that external CAs are more easily switched to using [params]
- Changes the order in which parameters are passed to AI component code. The order is now:
state/self, params, data
This commit potentially breaks any Lua AI customization, except for external Lua candidate actions.
In practice, though, Lua aspects and goals will probably continue to work for the most part.
- The ai table now has a read_only attribute.
If true, functions that change the game state will be missing from the table.
The read_only attribute is false in CA execution and in stages.
It is true everywhere else.
- Every Lua AI component now supports a [args] subtag.
The contents of this tag are passed as parameters to the component code.
This data is immutable; components cannot alter its contents.
(External Lua candidate actions do not receive this data.)
- Accessing the persistent engine data is now supported in all Lua components.
When calling a Lua component, the Lua engine now passes two parameters:
1. The contents of the [args] tag in the specific component.
2. The contents of the [data] tag in the Lua [engine].
The return value of the [engine] code, if any, is stored for later used.
It will be passed as the third parameter to any other Lua component.
This data can be changed, but will not be saved.
The default engine does not return any such data.
Apparently, when this is the case, the number key is not included at
all, rather than set to zero, when the Lua table containing the attack
information is retrieved.
This is done for cases when the value cannot be read from the unit_info
table, which might happen in some UMC. This fixes a rare bug affecting
the Fast Micro AI attack evaluation
Check whether the unit in the way has an unoccupied hex to move to.
Previously, it was only checked whether its reach was >1, which
sometimes can include only hexes occupied by units on its own side,
making the actual move impossible.
This was an idea we tried so that we’d start with the most uncertain
attack first, but it did not work very well.
Keep the code for now, just comment it out.
That’s what wesnoth.simulate_combat() does, but is different from the
other functions in battle_calcs. Only hp_chance[0] needs to be set,
even if it is zero.
