When a unit gives adjacent units abilities used like weapon specials, and is not already showing an animation from giving a resistance or leadership effect, a [teaching_anim] can be played instead.
https://github.com/wesnoth/wesnoth/pull/5481 removed the check that made
wmllint: display on and wmllint: display off necessary.
This PR removes now redundant wmllint comments.
find ./data/ -name '*.cfg' -exec sed -ri '/^ *# *wmllint *:? *display *(on|off) *$/d; s/ *# *wmllint *:? *display *(on|off) *$//' '{}' ';'
* units - set image_icon for sidebar display of Cataphract
* units - remove inactive ability description for Diversion
* add recruit/recall to event list triggering check for diversion animation (Dunefolk Falconer)
wmllint complained:
"../../data/core/macros/movetypes.cfg", line 1: no textdomain string
"../../data/core/macros/optional_unit_advancements.cfg", line 1: no textdomain string
This shifts many bobbing animations to only run if the unit HP falls below a certain point. Bobbing animations are a subset of standing animation, it is a case-by-case decision whether an animation should fall into this category or even be affected by this change.
Also in this:
* add wounded filter to STANDARD_IDLE_FILTER
* unit sprites - update orcish grunt and heaving anim
* units - north-facing sprites for orcish grunt
The reported issue being that the FORCE_CHANCE_TO_HIT macro was able to force an increase in an attack's chance to hit, but no longer able to force a decrease.
This time they're added in the wrong place so as not to break the schema validation; they can be moved to the correct place later once that actually works.
- Adds a bunch of documentation
- Fixes some incorrect or inaccurate documentation
- Moves some documentation so that wmlscope actually picks it up
- Excludes some internal macros from being documented
[heal_unit] set's as side-effect an variable, which contains the heal amount
of one of the healed units.
It's more likely that this will just add a variable with authors not being aware
to clean it afterwards, than the case being that someone want's this behaviour.
I assume that this happens is an unintended side-effect from former code refactoring,
the original implementation of this macro was not doing this.
[ci skip]
* Units - Dunefolk - first draft at Falconer branch of skirmisher
* Dunefolk - revision to Falconer line
* Units - dunefolk - some progress on falconer standing animation
* Units - dunefolk - attack animations for falconer
* Units - dunefolk - defense and melee (partial) attack anims
* units - dunefolk - WIP lvl3 falconer
* units - dunefolk - revise falconer
* units - dunefolk - animation work on Falconer line
* units - dunefolk - falconer ability diversion revised to affect enemy chance-to-hit. Animation filter/trigger not yet resolved
* units/abilities - dunefolk falconer diversion ability-related animations mechanism
* units - dunefolk - sky_hunter animation frames
* dunefolk/abilities - fix diversion animations to work on die event
* abilities - schema validation induced correction
* abilities - diversion animations - attempt to fix case of undo movement
* units - dunefolk - finish some cosmetic issues for Falconer line
* units - dunefolk - wmlindent
* use on_undo over select in diversionability
undoing can only change the 'diversion' state if the original action also did,
so there is no reason to check it in all 'select' events.
* fixup
* minor clean-up
Co-authored-by: gfgtdf <daniel.gfgtdf@gmail.com>
this converts the optional grand marsal advancement to the
[modify_unit_type] syntax.
Also with this the core cfg files no longer depend on other
macros except EDITOR and the difficulty macros so we could
(if we wanted) optmize it to not load this part of the cfg
again for each campaign.
See issue #3955
the intention is to deprecate [advancefrom] in
favour of [modify_unit_type], because it was a
common source of OOS errors, and it is less flexible.
As a secondary effect this also fixes issue #4402 :
"changing units via extra_defines sometimes not working
because extra_defines had bugs".
Now we no longer use extra_defines for that.
Addon authors should now no longer use these extra_defines,
instead put the new core marcos with the same name directly
into [campaign].
It causes more harm than good in many singleplayer scenarios, for example when there is an allied AI keep close to the player's AI.
The candidate action is still part of the Experimental AI, and its marco remains available, so it can easily be included in a scenario if desired.
The past change in 1.15 changed not only internal things,
but also the overlay given by the NO_UPKEEP macro.
Now it gives the same overlay as the loyal trait does.
Which is also the same which this macro gave in 1.14.
This has no impact on functionality or use, it is simply done for consistency with other CAs and to indicate that these CAs are now part of the default AI.
The algorithm used in this CA is too simple to work reliably in a general setting, it tends to send whole groups of units toward small numbers of villages, or even individual ones. In its current version, it should not be used at all, not even in the Experimental AI. The recommended way to emphasize village hunting is to set the village_value aspect to a larger-than-default value and let the move-to-targets CA take care of it.
We are, however, leaving the CA code and the macros in place for potential future work.
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.
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.
