Previously the CA would already move multiple leaders if all leaders were to be moved, but it would abandon moving any leader after finding one that should not move.
The old villages CA is quite a bit better at distributing multiple units across multiple villages. The advantage of the new grab_villages CA is that it has a variable score, sometimes grabbing villages before, and sometimes after attacks. This does not outweigh its shortcomings though.
So for now, the default AI will continue to use the previous CA, and the Experimental AI will use the new one. Thus, the two AIs are not quite identical any more (but still very similar).
I also added a todo comment that the grab_villages CA might be reinstated if it is improved.
Note that we do not add an 'ignore_units' option, as allies and enemies are taken into account in different ways and we want to have a way of ignoring each type individually.
... as opposed to lining up if there are allied units in the way.
This changes (fixes) the default behavior. An optional 'no_fan_out' parameter is provided in order to restore the old behavior.
This lets the AI find paths around areas defined by [avoid] tags, rather than being stopped dead by them. See comments in the code for details.
The relevant custom cost function, custom_cost_with_avoid(), can be accessed directly as well.
This adds the correct behavior for the castle_switch, move_to_any_enemy and place_healers CAs. It was already in place for the other former ExpAI CAs (except for recruiting and spread_poison, for which it does not apply).
This automatically also adds this behavior to the Healer Support Micro AI.
It is now identical to the default AI, so we only show it in debug mode in the MP computer player selection menu. It will be moved back to be always available when there is new development happening.
The return scores were changed in commit 4999b20bd1, but the max_score values in the configurations have not been updated yet. As the relative ranking was not changed, this should not have any effect on gameplay.
This allows restricting each CA individually to only a subset of the units. It also means that several instances of the same CA can be used in the same AI configuration, in order to, for example, force the order in which units are dealt with, or to apply different settings to different units.
Also backtracked the removal of wesnoth.get_recall_units, which is now available as wesnoth.units.find_on_recall - it's just more convenient than passing x=recall to wesnoth.units.find
Without this, the AI always starts with whatever it considers the best unit without taking the level bonus into account. This mostly only matters when one sets high_level_fraction to a very large value (1 or larger) in order to force only high-level recruits. In other cases it makes no, or no significant, difference.
This also sets its default value to zero, in order to have consistent default behavior with versions from before this parameter was introduced.
It also provides a macro so that the ExpAI can be used with custom parameters in a scenario config, and adds high_level_fraction as an optional parameter to the Recruit Rushers Micro AI.
Because unit cost is penalized in the ExpAI, it recruits almost no higher level units. This adds a bonus for such units to be recruited at approximately the ratio defined in 'high_level_fraction'.
The default 1.14 already considers high-XP attacks. Other than the dialogue,
the only change is to reduce the AI's default aggression, so there's more
contrast between what the Micro AI does compared to what the default AI does.
Switched to typographic quotation marks in the dialogue, and removed double
spaces between sentences.
Fixes#4253.
The schema's validation of ranges now rejects negative numbers, because the C++
code doesn't support them (both before and after this commit):
* utils::parse_range("-7") will return {0,0}, because std::stoi("") throws invalid_argument.
* src/map/location.cpp will parse it as -7, but that will never match an on-map coordinate
since the recent changes to overlays= in particular 1a7724e547,
e71033374c and b2cd1cf6c [unit]overlays= is no longer the
recommended way to add an overlay and the use of the
apply_to=overlay effect is reccomended instead, so adding it
to the [trait] is the most natural option here.
this in particular fixes#4058 . Also people simply forgetting the
IS_LOYAL macro was a not-so-uncommon cause of bugs.
In some cases people want to give the LOYAL trait without giving the
loyal overlays for those cases i added a optional OVERLAY parameter to
the {TRAIT_LOYAL} macro, also heroes should now use {TRAIT_LOYAL_HERO}
instead which uses the hero overlay. The IS_LOYAL and IS_HERO macros are
no longer needed in combination with those traits.
