By default, the MAI removes movement points from units even when they cannot find a hex to move to. When this option is set to 'no' (default is 'yes'), this step is skipped, so that other candidate actions can take over.
This implements feature request #5580
In general, the units specified in the MAI setup should be on the AI side. However, that might change during a scenario, for example when there is an event that switches units to other sides.
- get_terrain and set_terrain replaced with direct indexing operations
- get_map_size mostly replaced with either the iterator or an on_board call.
Only a few cases really needed to know the size of the map for some other purpose.
- shroud and fog operations, village owner, time areas, and location filters
- get_terrain_info replaced with terrain_types table
- Map generation functions create_map and create_filter
There were two issues with the previous method:
- ai_helper.get_avoid_map() never returns nil, but at most an empty location set. Thus, the 'else' clause in that conditional was never reached.
- The presence of an [avoid] tag should not prevent the keys ignoring enemies from taking effect. Instead, [avoid] needs to be taken into account for all possible code paths.
The final determination of the hex to move to must take enemies into account, otherwise the MAI might try to move the unit to a hex it cannot actually reach.
Numerical values are sometimes transferred from WML to Lua using the string type. This applies, for example, to very small numbers, such as 0.0000000000001. This needs to be taken into account when checking whether avoid_enemies is a number.
This includes several improvements to the retreat hex evaluation:
- Enemy threats are not the dominant rating contribution any more
- Enemy threats are based mostly on HP balance, rather than simply enemy number
- Enemy threat assessment can be modified with the retreat_enemy_weight aspect
- By default, only healing locations are considered as retreat locations, but this can be overridden with the retreat_enemy_weight aspect
The main problem was that the previous calculation was based on the 'caution' aspect. While that is not technically wrong, caution is also used for other purposes and there are mainline (and presumably UMC) scenarios that use large values for caution. In those cases, units retreated that were barely injured. This, again, might even be desirable for some use cases, but it needs to be decoupled from the other uses of caution. Thus, the new 'retreat_factor' aspect is used now.
In addition, the calculation is now based on a unit's maximum hitpoints, rather than its level.
This wouldn't have been an issue, if there weren't also a local variable of the same name in the evaluation function. The way it was though, it caused an error when trying to execute an attack by the AI leader.
Several new animals were added in PR #5039's
cbad6f4249.
The micro-ai demo can be accessed by starting Wesnoth with the command-line
arguments `--test animals`. The scenario uses some stand-ins for animals that
weren't in mainline; the new bears and tuskers fit straight in. For the sheep,
the icemonax's graphics are a bit more sheep-shaped than the troll whelp's.
This demo doesn't need to be balanced, the changed unit stats are no problem.
UtBS's dustboks aren't in core, otherwise I'd use them as the deer stand-in.
This whole textdomain is dedicated to localized strings revolving around the
game's AI engine and the AI demos/test scenarios, with around 370 strings in
it.
Other than a few strings near the start of the catalogue template, none of these
have any value for regular players since they are sourced from AI demos and
test scenarios in data/ai/micro_ais/ and data/ai/scenarios/. None of them will
be displayed to people who aren't tinkering with WML or contributing to AI
development as part of the Wesnoth dev team, and some of the language used in
them is very technical in nature.
This commit leaves the "#textdomain wesnoth-ai" lines in the AI demos, but
drops the .po and .pot catalogues for wesnoth-ai. The few strings that are
seen by regular players move to the wesnoth-lib textdomain.
If a unit is passed as the last argument to this function, the returned hex is supposed to be passable for that unit. Hexes on the map border need to be excluded in this case.
This specifically also fixes a bug in the Messenger Escort Micro AI. Previously, waypoints right at the map border could sometimes lead to the AI showing an on-screen error message and becoming inactive.
This reverts 24af20cf83, which made it available in debug mode only, as there remain more differences to the new default AI than initially envisioned. This takes care of Issue #4997.
This fixes the case when the unit cannot reach the previously found next_hop location from the ideal next_hop location in the part of the code that tries to keep units from moving in single file.
Previously, a rabbit hole item on the map border could be selected for spawning a new rabbit, resulting in an error message on screen and abandoning the CA for the rest of the turn.
Before the recent change, the ability type (tag name) was checked. It then got changed to ability id. This commit changes it back to the old behavior.
For the record, there are situation when either the id or the type is needed. In addition, one sometimes wants to check wheter the ability is active (or will be active). Thus, no matter how this is done, neither will serve all purposes and sometimes other functions/functionality should be used. This commit does, however, restore the previous behavior and thus preserves backward compatibilty.
In addition to 'yes' and 'no', comma separated lists of leader ids are now also accepted as values for these aspects. This allows setting the behavior only for specific leaders.
I switched to using defense_on() and resistance_against() incorrectly in 55478e20. I had tested these, but apparently for cases when it does not make a difference ...
The change for movement_on() is for convenience and consistency with other code only.
