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.
… for determining whether AI/CA ids are unique. Also pass AI id to
eval/exec functions, instead of CA id. This is also a step toward
fixing the bug with MAI variables remaining stored in units after an
MAI is removed.
In principle, the ca_id= key in the [micro_ai] tag should now be
renamed to ai_id, but that would break backward compatibility without
any benefit to the user, so we deal with it internally behind the
scenes instead.
These provide a simple and consistent way of storing variables inside
[micro_ai] tags in unit variables. This is needed for fixing a bug
with variables stored in units from a previous MAI causing problems
with a subsequent MAI.
WML values may not be used as keys, this can make savegames invalid.
Store information in the units now rather than in self.data. (Note:
storing in self.data would also be possible if the syntax were changed.)
In the default configuration, the AI moves the messenger which has
advanced the furthest through the waypoints first. If this key is set,
the rearmost messenger is moved first.
For two of the CAs this mostly just means reading the [filter] tag and
picking one of the messengers. However, for the CA moving the escort
units, it means a complete rewrite, as the AI now needs to figure out
which escort unit should be moved toward which messenger.
When there were lots of escort units, they previously quite frequently
blocked the messenger’s way, preventing him from making progress even
when it was possible. Escort units now specifically move out of the
way if they do not need to attack enemy units in the messenger’s way.
This was an oversight dating back to the introduction of the [filter]
tag as a possible parameter to this Micro AI. A part of the attack
code still relied on the id= key being given, although that key is not
required any more now.
If a WML event takes a unit off the map, many of the AIs would
previously have run into problems by trying to access a unit that is
then not there any more. Thus, the existence of the unit needs to be
verified before continuing in cases when this would cause errors.
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.
The scenario author now has the option to use either the default AI
[avoid] tag or a specialized [avoid] tag inside the [micro_ai] tag. If
neither is given, the default remains all castle terrain.
This was discussed both on the wesnoth-dev mailing list and on the
forums and the overall consensus was that it should be off, although
some scenarios will benefit from it. It should be enabled specifically
in such scenarios as they are identified.
Reference:
https://mail.gna.org/public/wesnoth-dev/2014-01/msg00001.html
and links therein
