Changes:
* CHECK_STRIKES macro now takes a comma-delimited list of strike counts for when units have a different number of strikes for different weapons, and updates the existing usage in the attacks tests
* Fixed a typo in the attacks_zero test
* Adds tests for berserk as a weapon special ability.
Berserk's handling differs from attacks as a weapon special ability:
* A value less than 1 is treated as effectively infinite rounds of combat (undocumented)
* The cumulative attribute is handled differently - in some cases it sums the values instead of using the highest single value whereas for attacks it always uses the highest single value
Also now exclude data/tests/ from scons pot-update since it was hitting the argument limit for number of arguments to a script.
The units on the outsides of a backstab don't have to be allied
to each other, they just have to be enemies of the victim. That's
hardcoded into the AI via attack.cpp's backstab_check() function,
hence a unit test to check that WEAPON_SPECIAL_BACKSTAB activates
in that situation.
Add a new map with 4 sides all on separate castles. This is a
variation of the generic 2p unit test map, extended in the south
with a horizontal reflection of existing map.
Add a MAP_FILE argument to COMMON_KEEP_A_B_C_D_UNIT_TEST,
because it's the same setup except for the map file.
This is testing experience=yes and experience=no, with the expectation that
some new values for that attribute will be added afterwards.
Adds a new generic macro ASSERT_UNIT_HP_XP. Looking thorugh the ability tests,
ASSERT_UNIT_HP (without the XP) could be a heavily-used macro, but it wouldn't
be used by this particular commit, so I'm not adding it in this commit.
Originally by gfgtdf, this was cherry-picked from gfgtdf's PR #7589, with
modifications.
COMMON_KEEP_A_B_UNIT_TEST gains support for optional args
SIDE1_LEADER and SIDE2_LEADER.
This doesn't cover all of the unit tests, it's the result of running wmlindent
on all of them and then reviewing whether the changes were bugs in the test, or
whether they're bugs in wmlindent.
Note: there are two cve_2018_1999023 tests. The other one needs to be treated
as a binary file, but the one changed here is plain text that loads its attack
from a separate file.
The change in start_position_generic.cfg doesn't seem good, but it's not
particularly bad and it's what wmlindent currently does.
The existing backstab tests' common code is moved to a utility file
for reuse in other tests, because it can be used to check whether a
weapon special was active during the damage calculations.
Git's diff can show a lot of lines being deleted, but that's just
because it's showing a file being copied, and then half of each copy
being removed.
Slightly different to PR #6582, which was the 1.16 version of this. The five
lines that were labelled `preserving known bug` are changed to test that it's
been fixed.
Here `apply_to=opponent` means that the weapon special gives the opponent the
ability, the unit that should get poisoned or slowed is the unit that has the
weapon special.
There's a known bug in 1.16, that `apply_to=opponent` check the wrong unit to
see it it's `unpoisonable`, `undrainable` etc. It also checks the wrong unit to
see if it's already poisoned or slowed, so a battle between two units that both
have reverse-poison results in at most one being poisoned.
Most of the credit for this is Newfrenchy's, as he's already written a fix
and a WML based test. This commit uses a Lua test instead to test more
combinations of statuses.
This adds a `COMMON_KEEP_A_B_UNIT_TEST` macro, which is a counterpart to the
`GENERIC_UNIT_TEST` macro that starts the leaders next to each other, ready
to attack. The `A_B` is because I'm planning a multiple-side variant too.
There's no test for [petrify], as simulate_combat doesn't provide a stat for it.
This tests only 3 of the 6 abilities whose behavior changed in 650f70405f.
My thoughts on testing the others are:
* [firststrike]'s test is in 650f70405f.
* [drains], [poison] and [slow] are tested here.
* [petrify] ends combat, it's also not exposed in simulate_combat's stats.
* [plague] triggers after combat ends.
Turn the 4 side setup of the firststrike_and_laststrike test into a macro
called `COMMON_KEEP_A_B_C_D`for reuse in other tests.
The comment for `GENERIC_UNIT_TEST` gets a couple of extra paragraphs.
All the files get wmlindent run on them, which reindents `FAIL_IF_NOT`.
The main reason for having these is separate files is Git's fuzzy-patch
matching when merging and rebasing. Having large blocks of identical text
in `wml_unit_test_macros.cfg` can mean the wrong section gets patched.
- The t_string type is now a schema built-in type and no longer attempts a regex match.
- You can also specify that non-t_string types may be optionally-translatable; this case supports a regex match on the string (but note that the translation mark is not part of the match).
- Error messages involving keys with very large values ( > 128 characters) will now truncate the value.
- To account for occasional cases where the schema is intentionally violated, the --validate command-line option now automatically defines the SCHEMA_VALIDATION preprocessor define.
A key validates as type t_string if one of the following is true:
- The key is not present
- The key has at least one segment with a translation mark
- The key is blank (an empty string)
Any type other than t_string is not allowed to be translatable by default, unless you specify allow_translatable=yes in the [type] tag.
An optionally-translatable string could also be defined as a union of t_string and some other type.
This adds an additional `test_result` attribute to [endlevel], intended for use with the automated unit tests. This allows for the unit tests to differentiate a pass/fail result separately from scenario victory or defeat, which allows for more accurately determining the outcome of a test as well as addresses the potential, for example, for a scenario to be expect to pass because of the {SUCCEED} macro but instead passes because the scenario ended as a victory through some other method.
Additional unit tests which were the original motivation for this change are also added as part of this. They test, as much as possible, that events are executed at all, and are then also executed in the expected order.
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.
This explains (in the log) why a WML conditional has failed (or succeeded). Currently it is fairly basic, looping through and/or/not and printing out the specific conditional tag that failed as well as, for [variable], the current content of the variable.
It's used in the WML unit tests system, but could also be useful for debugging.
This commit also fixes an issue with passing multiple -a arguments to run_wml_tests.
There is some WML in data/test/scenarios/ that causes wmlindent to
misbehave (bug #22264 and possibly others awaiting a more thorough
diagnosis), so that subdir is not part of this commit.
I initially had linger mode off in the endlevel tags of these
macros, to make sure they didn't block the end of noninteractive
scenarios.
But it turns out its better to have it on. It doesn't block the
tests when they run noninteractively, and it means that if a test
fails, you can boot it up with --showgui, and then run :inspect
from linger mode to see what happened. If you don't have linger
mode, then even with --showgui the failed test closes out too
quickly.
