This AI is meant as a fall-back AI for scenarios where there are so
many units that attacks and moves done by the default AI are slow with
long delays before each move. It replaces the default combat and
move-to-targets candidate actions.
See http://wiki.wesnoth.org/Micro_AIs
In rare cases (when the unit has no hexes to move to, not even the one
it is on because it is in a zone to be avoided), this would cause an
error and crash the AI.
If several Goto MAIs are used on the same side and both have
unique_goals=yes set, they previously might have interfered with each
other, one preventing the other from working correctly. Now the “goal
taken” information is saved such that it only applies to the CA by
which it was set.
Don’t check whether rating equals (or doesn’t equal) -9e99 or the like,
verify that a valid move was found instead. Also, avoid setting
variables to empty tables if not needed.
There was a typo in the goal table indexing. It worked for the
multi-unit test scenario (the Elves Besieged) because the goal x
coordinates for both units were the same.
It’s theoretically possible that different Micro AIs’ evaluation
functions store information in the same variable within self.data.
This would only happen if the CAs have the same score and while this
should generally be avoided when setting up a scenario, it is better to
ensure that it cannot cause conflicts (not in the stored data at least,
the MAIs might still interfere with each other in other respects).
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.
It’s slow. The inverse logic using table.insert is much faster,
especially for large tables. Only kept table.remove in a couple places
where it doesn’t matter.
Consistently use wesnoth.require, avoid wesnoth.dofile. Move commands
as close to beginning of file as possible in order to facilitate custom
modifications of MAIs.
… setting up an MAI. Ideally, we would delete such previous occurrences
of [micro_ai] tags in the AI's self.data variable. However, the MAI can
be changed while it is not the AI's turn, when this is not possible. So
instead, we check for the existence of such tags and make sure we are
using a different ai_id.
These provide a simple and consistent method of storing variables
inside [micro_ai] tags in the AI's persistent self.data variable. This
is needed for fixing a bug with variables stored there from a previous
MAI causing problems with a subsequent MAI
This is unit specific information, and therefore should go into the
unit. By contrast, information whether all units of the side have been
released needs to remain in self.data.
