I'm working on a bugfix for the [resistance_defaults] tag, for which the
unit test is going to be out-of-tree until we support some method of testing
it without affecting other tests. The version here is the part of that which
can be in-tree, because it doesn't change the core unit's stats.
The existing tag has a confusing name - it returns the chance to be hit rather
than the defense, for example 30 would be returned for a unit on 70% terrain.
The new tag returns a higher-is-better value.
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.
All weapon specials can now be used in [abilities] to effect all weapons of the unit that pass the filter given in [filter_student][filter_weapon].
Explanation: filter_student filters on the unit that is under the effect of the ability (which is usually the unit itself, but not always if [affect_adjacent] is used). [filter_student][filter_weapon] filters on the active weapon of that unit (the student) in a specific combat.
[filter_weapon] is now supported in all filter_opponent, filter_student, filter_attacker, filter_defender
Note that constructs like [filter_student][or][filter_weapon] are not suported, [filter_weapon] must be a direct subtag of the four just mentioned tags.
[filter_second_weapon] is no longer used for abilities that come from weapon specials.
implements #4629 , #4475 , #4389
Co-authored-by: gfgtdf <daniel.gfgtdf@gmail.com>
This is part of working out whether a subset of the "fail" tests could be run
in one Wesnoth instance. To run a test that returns TEST_FAIL_BROKE_STRICT with
any other test would require a mechanism to reset lg::broke_strict()'s flag.
All tests that fail with an {ASSERT} will also set the lg::broke_strict() flag,
the tests with the new status are only those that would pass without the strict
flag.
In the SUF tests, change a test from fail-on-success to breaks-strict, rename
the formula tests and add some comments. The rename is because "fai" is
"Formula AI", an obsolete name for WFL.
The count is undocumented on the wiki, and it's causing the schema validation
to fail. The functionality makes sense and I hope it continues to be supported,
but for now let's have a minimal unbreak-the-build change.
Trying to move a unit to the hex occupied by itself causes it to move to a vacant
adjacent hex instead; splitting the move into two separate [move_unit] calls
passes as expected. That sounds reasonable implementation-defined behavior, but
will make a PR to discuss it.
One of the cases fails due to something in find_vacant_tile - perhaps someone else can figure out how to fix this?
If nothing else, setting check_passability=no in the [move_unit] should do it, but I'd prefer not to have to do that...
Also extend the unit test to at least check the end result of comma-separated
values, as there was previously nothing testing the effect of providing more
than one value.
Adding this is issue 2 of #4177, changing the behavior when [find_path]
is given a SLF which matches multiple hexes.
The map and tests here should be easy enough for manually editing them. It
duplicates some of the functionality of the existing characterize_pathfinding
tests, however those tests need their expected values to be calculated and
can't be changed by hand.
'''nearest_by''': {DevFeature1.15|2} possible values "movement_cost"
(default), "steps", "hexes". If the [destination] SLF matches multiple hexes,
the one that would need the least movement points to reach may not be the one
that's closest as measured by '''hexes''', or closest as measured by steps,
from the starting point.
Behavior in 1.14 depended on which hex was checked first.
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
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 adds running the WML schema validation in travis. It also updates the schema itself and fixes a few WML errors so that core and all campaigns under all difficulties pass the schema validation.
With this, the WML unit tests are as clean of schema errors as they can get
The two remaining errors are unit tests for dealing with invalid input,
so they are intentionally violating the schema.
Like @gfgtdf pointed out, loadstring() is still supported by Lua in the
name of backwards compatibility, even though it was deprecated in Lua 5.2
and is no longer mentioned in Lua manual. Thus, as of committing this it's
actually possible to load Lua bytecode.
Let's unit test this to ensure that we don't reintroduce this
vulnerability.
(cherry-picked from commit aa73b83600)
this test whether we succesfully prevent the exceution and parsing of
precompiled lua chunks, which can be used to break the lua sandbox.
This test does not cover all affected functions in particular not the ai
code that loads lua chunks.
(cherry-picked from commit 6b13a63bb0)
