Add `first_time_only=no` to some existing tests, and verify that events that
should only trigger once do trigger exactly once.
A new test of `[filter_attack]` when an event lacks attack data. In testing,
I found that it used to trigger a warning that I thought was useless code, and
had removed during 88439d6427a81a6b131acd8b0f7bf04b2d981d71's review. I think
removing it is still good, at the time that the filter was checked it would have
warned "attempt to filter attack for an event with no attack data."
A new test of what happens when a unit with only a ranged weapon fights a
unit with only a melee weapon. This commit is just the test, it depends on
the engine fix in a previous commit.
This only tests the filtering so far. There should probably be another
additional test to check what the combat results are, however that would need
an ability such as the Deep Elves' Stardust that passively affects the amount
of damage taken. It can't be tested with Slows, as that needs the defender to
hit with a weapon first.
When we try to trigger an event conditioned by the use of a special whose activity is subject to a condition, we cannot use special_active because the specials are always considered inactive. Additionally, abilities used as weapons possessed or taught by a leadership are also not detectable in [event][filter_attack]. This PR is there to remedy this double problem.
Also remove matches_special_filter and directly use matches_filter.
Since a0ee38a49, the inner this_item was still in scope when the inner loop
writes changed data back to the outer loop's variable, which meant that
changes were silently ignored.
A lot of the changes in wml-flow.lua are just indentation because of the
extra block.
* Add basic achievements functionality.
This reads the mainline achievements.cfg and then all the achievements of each installed add-on.
This is intentionally handled separately from other WML loading so that:
a) All achievements and their status are able to be displayed on the main menu right after Wesnoth starts and regardless of which add-ons are active.
b) Add-ons can add additional achievements to other content, whether UMC or mainline. For example, a modification that adds more achievements for mainline campaigns.
Marking something as achieved is handled by the new [set_achieved] tag and whether an achievement has been completed can be checked via [has_achievement].
There is no attempt to prevent people from manually editing which achievements they've accomplished.
NOTE: These are *not* in any way related to Steam achievements!
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.
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 650f70405ff.
My thoughts on testing the others are:
* [firststrike]'s test is in 650f70405ff.
* [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.
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 096d8aba1474e9c6583d240e7eedbcd66957f327)
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 13c5d8a96ead8d2a7f0435f60b8ec7f7e0af0972,
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 30f50bac681fda1566f5cee5aad7be6b65cb0fdb)
The edge-case of calling evaluate_single within an unsynced event was
surprising, and I'm not sure it's correct. However, as we're about to
release the 1.16 branch I think it's better to include that as a test
that the API doesn't change during the stable branch.
Check that the scenario's next_scenario= exists, and display a warning
if it would lead to an "Unknown Scenario" error. This also checks any
[endlevel] tags in events.
The error message includes the id of the missing scenario, but is mainly
a recommendation to check the forums and report a bug in the campaign.
This version has a short, one-size-fits-all, text for the error message.
When processing [effect]apply_to=movement, if apply_to_vision is 'yes'
(which is the default) then the vision points will change by the same amount.
Previously, it sometimes affected vision and sometimes didn't; for most cases
where it makes a difference, I expect it to be a change from unanticipated
behavior to expected behavior.
Please refer to the new unit test added in this commit for more detailed docs;
that test is also a rough draft for the Wiki update needed when this merges.
The reason it sometimes affected vision was that the special value of -1 vision
points was interpreted as "use the value of the max movement points instead".
The special value of -1 is still supported and frequently used, and refactor that
is out of scope for this commit - it's easy to check when the code path changed
in this commit is used, however it's considerably more complex to find all
routes that create a unit with vision set to -1.
I'm expecting one add-on, Rebirth In Nature, to need a large update for this;
as well as a trivial change needed to the Add Creature Pack.
There are several mods that have their own handling for vision, recalculate the
values frequently, and are expected to continue working as before, as they'll
just overwrite any changes that the engine makes.
* Proper Flying Mod / Proper Vision Mod
* LotI
* Blessed Altar Mod
* Shards Era's `CALCULATE_WEAPONS_ONLY` macro
* Castle of Evil Spirit
Rebirth In Nature is an RPG-style campaign that expects the player's unit to
have vision separated from movement along with right-click menus that change
the character's movement, this will probably need `apply_to_vision=no` in
many places. OTOH, its `item_id=mobility` uses `apply_to=movement` followed by
`apply_to=vision` to implement in 1.14 what this change will make default
behavior in 1.16.
There are a few sharpshooter units which have vision better than their
movement. If given a buff which boosts their movement, this will give
them a buff to vision too; likely a change towards expected behavior.
* Archaic Era's Royal Ranger
* Ageless Era's Royal Ranger and Dwarvish Forest Sniper
* Eastern Europe at War's Yacht and Great Yacht
* Era of More Units's Lone Wolf
* Southernerns has several sharpshooters
* WWII Era has several sharpshooters
* War of Dominions has some guard towers with very low movement
Silver Age has abilities that modify vision based on time-of-day, but unlike
the Proper Flying Mod and LotI these are done by adding and removing objects
that add or subtract one vision point, these should be unaffected by this
change. Unrelated to that, it declares values for `[unit_type]vision=` even
when the value is the same as max moves - like the sharpshooters this means
that buffs to their movement wouldn't have buffed their vision but now do.
There are few units with vision less than movement. Generally these seem to be
missile weapons that are represented as units, and they probably won't meet any
apply_to=movement statements - even if a movement power-up is available, the
player would probably choose a different unit.
The Add Creature Pack has two creatures (the Cactose Elder and Carnivore Fatal
Plant) that have reduced vision, along with AMLAs that increase those units'
movement; these AMLAs will need to use `apply_to_vision=no`. These two
creatures are used in Castle of Evil Spirit, but they won't get enough
experience to get an AMLA there.
Fixes#3356.
