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.
It’s slow for finding units with moves or attacks left. The alternative
method of getting all units and then looping over the table with a
condition is much faster.
These function libraries are still work in progress and change
frequently, so the code cleanup is mostly just to make sure the syntax
is consistent with that used in the Micro AIs. Changes or improvements
to the algorithms might be made at a later time.
It’s slow for finding units with moves or attacks left. The
alternative method of getting all units and then looping over the table
with a condition is much faster.
This now checks whether the stopunit execution intended to be done with
ai.stopunit_all, ai.stopunit_attacks or ai.stopunit_moves is possible
and displays an error message if it is not.
These consist of a number of supplementary functions, plus three
function get_cardinal_directions, get_intercardinal_directions and
get_hex_facing which return strings for the directions (in cartesian or
hex coordinates) between two hexes.
