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.
this adds borders to the 2p dark forecast survival map, it also removes
the big empty space in the upper third of the map.
This also renames the mask files to map files, becasue they are actually
just normal maps, and the [terrain_mask] just replaces the current map
with these.
In the previous version, the leader would sometimes leave the keep for
truly suicidal attacks. This commit adds an extra layer of analysis to
evaluate whether an attack position is safe enough.
This evaluation is too expensive to be done for all units for the
purpose of this AI, or even to be done for the leader more than once,
so this is separated out into its own candidate action that is only
evaluated once everything else is done.
Attackers and targets can now also be selected through the default
attacks aspect. [filter] and [filter_second] inside the [micro_ai] tag
have priority though, if either of them is given.
This can either be an [avoid] tag inside the [micro_ai] tag itself, or
the [avoid] tag of the default AI (e.g. as defined in the side
definition). If both are given, the former has priority.
This is a multiplicative factor determining how much more the AI values
leaders than non-leader units. The parameter was already included in
the fast_attack_utils code with a default value of 2. This commit only
makes it configurable from the [micro_ai] tag.
These can be used to limit the attackers and attack targets in the same
way as the ‘attacks’ facet does with [filter_own] and [filter_enemy]
for the default AI combat candidate action.
This does not affect the move-to-targets candidate action of the Fast
Micro AI.
This is done in this way to keep computational overhead as low as
possible.
Also add an optional key attack_hidden_enemies. This can be used to
attack also hidden enemies; or to speed up the AI a little when no
hidden enemies are present.
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.
wesnoth.get_locations includes border hexes, so they need to be
excluded specifically. Previously this could cause error messages and
the CA to be blacklisted.
The problem is due to a dog adjacent to a sheep being excluded from the
dog_move CA (so that it can act further later on in case the sheep
moves again). It is fixed by adding another CA at the end that simply
takes all moves away from all dogs once all other CAs are done.
Hexes occupied by allied units were previously not excluded properly by
the AI, which could lead to error messages and the candidate action to
be blacklisted.
If the move of the attacker toward the target is interrupted by an
ambush, the attack action previously caused an error, because the
attacker did not get to its target.
In this case, it can happen that there are no goals (e.g. if there are
also no villages or if the AI has no leader). Previously, this
situation caused an error message.
In normal MP and SP games, these macros are defined previously and
including them here produces unnecessary overhead. However, they are
not defined when an AI MP game is started from the commandline with the
-m and --ai-config options.
If the lurker move is interrupted by an ambush, the attack action
previously sometimes caused an error, because the lurker might not get
to its target.
