Covers the math for [attack]add=, [attack]divide=, [attack]multiply= and
[attack]sub=. The behavior is the same in 1.16.
* 5 + 2 = 7
* 5 - 3 = 2
* 5 + 2 - 3 = 2. Yes it does, that's half of why this unit test exists ...
* 5 + 2 + 3 = 8
* 5 + 3 + 2 = 8
* 5 + 2 - (-3) = 7
* 3 * 3.34 = 10
* 3 * 3.334 = 9. ... and that's the other half of why this unit test exists.
The movetype's special notes were becoming a new note for the individual unit.
Clean up the documentation on some of movetype's functions, as they had
documentation in both the .hpp and the .cpp.
Move `event_name_variable_substitution` to the top of the file, as it's testing
that the event triggers at all, before the tests that check which order the
events are triggered in.
The old `order_of_variable_events1` seemed to be a combination of two tests that
should exist, but the code didn't quite test either of them. This replaces it
with a new `order_of_variable_events1` and `order_of_variable_events3`.
Docs partially written by Pentarctagon, this started as a review comment
on the documentation PR.
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.
Basically this means each of the call modes of the old function is now a separate function.
- add_repeating and add_menu take an ID and a function
- add_wml takes variable substitution setting and a config
- add takes the full options table
in this test, two same leadership with value attribute and cumulative=yes add their value then what two leadership with same id and 'add' attribute using on 'add' only(the highest when 'add' value is different)
this test is added for verify what cumulative=yes work in same time what 'add' and 'sub' and what using of these attributes in[leadership] don't be
changed, only using of cumulative work anew like in 1.14
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.
This returns a label handle which allows you to remove, reposition, or replace the label later.
In addition to all the features of wesnoth.print, you can now specify where the label appears onscreen, as well as a fadeout time separate from the duration.
You can also anchor the text to an edge or corner instead of centering in on the screen,
specify the maximum width it can occupy as an absolute width or a percentage,
and specify a background colour and transparency.
It includes a demo scenario that demonstrates many of the capabilities of the API.
To play the demo scenario, run with -toverlay_text_demo or select it from the in-game test list.
As reported on the forum in https://forums.wesnoth.org/viewtopic.php?p=672374#p672374
If a unit with "last strike" ([firststrike] special with apply_to=opponent, on any of its attacks)
was targeted by other unit for attack, wesnoth crashed.
Fix similar problems for other weapon specials like poisons, when two users of specials with
apply_to=opponent fought, one fighter only could be poisoned or slowed.
* Add a unit test for poison
* Add a unit test for firststrike and laststrike
Based on Pentarctagon's documentation addition, and also improving
the encapsulation of the test to take a boolean value for whether
the ability should be active instead of the expected damage total.
Units on the recall list might have x,y coordinates that are on the map, which
therefore need to be replaced with "recall,recall" within [store_unit]. The
existing code created a temporary variable, changed the coordinates, and then
returned the unchanged original instead of the temporary.
Add a new test that `[put_to_recall_list]` followed by `[modify_unit]`
doesn't move the unit back to the map.
(cherry picked from commit 096d8aba14)
Always use the "slow path", because it stores and unstores the unit, triggering
the desired side effects of unstoring a unit.
Fixes issue #5133, and tests that with the new unit test.
Fixes bug #4978, that changing the facing wasn't updating the display.
This corresponds to 1.16's commit 13c5d8a96e,
that commit merely disabled the fast path to be a minimal change.
Fixes the currently suspected root cause of #5108, but requires further testing
to confirm that it fixes that issue.
Closes#6501 (the question of how to test the mapgen filter).
(cherry picked from commit 30f50bac68)
