The old method is very slightly faster in some circumstances (e.g. for
simple filters and when all units have moves/attacks/etc. left), but we
are talking fractions of micro seconds. By contrast, depending on the
filter used, the new method can save large amounts of evaluation time
once some units have move or attacked.
This removes the Lua deprecation_message function in favour of exposing the C++ variant to Lua instead.
It also moves all deprecation messages to a separate logdomain, making them easily enabled en masse.
When the AI moves a unit out of the way for another unit’s move, it is
occasionally possible for the former unit to use up all its movement
points (e.g. if it has few MP or on narrow crowded maps). If that unit
is on the list to be moved later during the same sequence, this caused
ai_helper.robust_move_and_attack() to return nil, which then made the
Fast Micro AI produce an error message.
(as proposed by @DeFender1031)
All existing deprecation messages in the Lua code have been changed to
use the new deprecation system.
The goal is to eventually use an equivalent system for ALL areas of the API.
This covers all the main higher-order functions included in WFL, except zip.
The two already implemented in ai_helper have been replaced with redirection stubs.
Otherwise it is too easy to exploit this by baiting the AI leader to
run into a trap, and it is too difficult for what it's worth to make
sure the attack location is safe. If only the side leader is left to do
such an attack, it's more often than not not a good idea to do so
anyway.
This function is supposed to be able to deal with all kinds of rare and
weird events without throwing errors, but it should still return a
status table describing what happened. The vast majority of situations
will simply return the move_result tables. For all the strange stuff
that could also happen due to WML events etc., we set up dummy tables
with the same structure and (somewhat) descriptive error messages
instead.
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.
