- 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.
[ci skip]
These are incorporated into the objectives dialog automatically. They lack a deprecation
notice, but they should be given level 3 status on the 1.14 branch.
I originally added it in #719. At that point ms_after= affected the *previous*
track due to a bug; however, I had assumed the behavior to be intentional and
compensated for it by adding ms_after= to the first track of a scenario instead
of the story screen music.
In April, I saw the documentation for ms_after= which said that it's supposed
to affect the track itself, not the previous one. Hence, I fixed the bug in
commit b023b818c742cee0bc75460235c9d1088c0b495d. However, I had forgotten that the changes I had made
in #719 depended on the old broken behavior of ms_after=.
This commit moves ms_after= to the right place, restoring the fade-out on
scenario start and removing the pointless pause after the first track.
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.
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 1a7724e5472,
e71033374c35 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.
Changelog provided by @ghype below. Additional credits at the end.
=================================================================================================
*Art*
Most of units were reworked - some more some less - but our goal was to make them fit for mainline all together.
If any changes are needed to any unit, then we gladly execute those. There have been months worth of progress
documented in the according art thread for this project.
Base Units: https://forums.wesnoth.org/viewtopic.php?f=9&t=49075
Extra Units: https://forums.wesnoth.org/viewtopic.php?f=9&t=49625
*Balance*
The main reason why this project started in the first place. Here as well we have all the progress for balancing
Dunefolk documented and all developers and users interested in this project and seemed to agree on the current
state of balance. Thats the reason why we will not enlist all the changes here. If there are any problems with
the balance, then we too are willing to provide alternatives that can be discussed either here or on forum.
Balance Thread: https://forums.wesnoth.org/viewtopic.php?f=15&t=49627
*Alignment*
The balance of this faction was based on the newly proposed liminal alignment which works as +0/+0/+25/+0/+0/+25
instead of the old -25/-25/+0/-25/-25/+0
*Weapon Portraits*
As Dunefolk features entirely new units, we found some weapon portraits that fits the attacks of certain units.
The portrait - called „blade-curved“ is a franken but a convincing one. As the current blow pipe for UtbS is a
franken as well, this new weapon portrait should good enough to be mainlined as well. If this request get’s denied,
then we are free to provide alternatives as well. It just fits very well the theme of exotic Naga weapon
craftsmanship without relying on the orcish theme. It used for the following two units:
Lv2 Naga Bladewhirler
Lv3 Naga Dervish
*Descriptions*
New unit concepts require changes and new units require entirely new descriptions. We enlisted all problems and
inconsistencies that resulted with the rework and provided either solutions for them or new descriptions. Yumi
already started doing them but for those who want to see the initial conflicts, here you can find all the problems
displayed:
Unit Descriptions: https://forums.wesnoth.org/viewtopic.php?f=32&t=49867#p642698
*Female Dunefolk Names*
With the introduction of female units to this faction, we would require female names as well. Apparently this was
already coded in mainline, but simple not used.
*Future Plans - Animations*
There are some recourses from past works that allow us to - more or less - easily animate most of Dunefolk units.
The animations range from idle to attack-only, while other units will be fully animated. Some of the units that
are harder to animate will first receive single attack/defend frames until animation concepts were agreed upon.
Our goal is to make Dunefolk as alive as possible.
*Future Plans - Theme, Sound FX*
Rather unimportant to most people but I am interested to add some new sound fx that can start with different hit/death
sounds or new weapon sounds for scimitars. Those are just example and I do not know what I will end up with. But I know
that I will compose a Dunefolk Theme at some point. Using your feedback, I am sure I can manage to create something that
fits the faction the best.
*Future Plans - Wyvern Rider*
This is the only unit is the only one that did not get touched or reworked. The wyvern on it self looks amazing an does
not need any rework but the rider does not really fit thematically anymore, not to mention the weapon is too oversized
and not the usual Wesnoth style. But I won’t touch this sprite until it actually will be needed, most likely - IF -
there is ever going to be a mainline Dunefolk campaign.
*Credits*
I don’t know how detailed you need this to be but here all contributors.
ghype, Hejnewar, Krogen, The_Gnat, Lordlewis, EarthCake, Tom_Of_Wesnoth
It is however important to mention that the amount of contributions of each varies a lot in different categories. I will
organise it a bit and you make use of this info how ever you want. The names are in order of the amount of work put in.
Art: ghype, The_Gnat, Lordlewis
Balance: Hejnewar, Krogen, ghype, The_Gnat
Descriptions: Tom_Of_Wesnoth, Hejnewar
Earthcake joined us in the end and helped us finishing this project by cleaning/finishing the codes and doing all the git
stuff together with The_Gnat. Although none of his work can be categorised in one of the three categories, he still deserves
to be credit in one way or another.
Thanks for your time and efforts.
