[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 b023b818c7. 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 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.
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.
If in attack end in FORCE_CHANCE_TO_HIT macro, unit or second unit doesn't exist anymore because rare case where unit disapear before attack end event was calledthen we have an error message like "Invalid WML found: [unstore_unit]: variable 'second_unit' doesn't exist" because presence of unit not condition of execution of event.
It does support id though, which is used as a sort of caching mechanism
in case the same effect is applied many times, so use that instead of name.
For good measure, also use an id on the sceptre of fire animation
The playlist macros set the music list twice, once before the
story screen and again in prestart, but the order of tracks is different.
This means that the track order at the titlescreen and in the lobby is now the same
as the track order in a scenario using the default playlist, which previously was not the case.
Similarly, the track order in the editor is now the same as the track order
in a scenario using the full playlist.
Whether that actually matters? I have no idea. I doubt it.
In any case, as of this commit, there are no schema validation errors
at the title screen, when entering the MP Create screen, or in the map editor.
Instead of having another ToD, the image of the current ToD is used,
but illuminated. This is a visual change, no gameplay changes included.
The ToD shifting for 'dawn' looked better than for 'dusk', and was
conidered better looking than having no ToD shift compared to the
surrounding.
part of #3056
[ci skip]
(cherry-picked from commit c7d8d23256)
Also update Dead Water's copy of it to use race= instead of a
list of unit types (as done for the core object in 613dd431).
(cherry-picked from commit ad7bc19dd9)
