Even tests that don't have "_bug" in the name shouldn't prevent
intentional changes to behavior, I've added a paragraph about that.
Rewrite the non-reservation of "break" and "error" for clarity.
In the case of [leadership], the fact that the values of each ability can be added when cumulative=yes can justify the addition of limit values not to be exceeded, but this can also apply to heals and [regenerates] with the use of 'add' or 'multiply'.
As for [resistance], it already uses max_value, but if cumulative=yes, then all max_values can add up which could be problematic.
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.
A weapon with poison, which does extra damage to poisoned opponents.
This tests that the weapon-special's filter is checked on each strike,
instead of being tested once and then cached during the battle.
(cherry picked from commit 55aa8b44cf)
Instead of needing to contain the exact string from the ability, 'apply_to' in the filter is now taken as a comma-separated list, where all elements need to be present in the ability.
For example if we filter for apply_to=fire,arcane given an ability [resistance]apply_to=arcane, fire, cold, it will match.
For an ability [resistance]apply_to=arcane, impact, cold, this will not match because 'fire' is missing.
In 1.19 since 82499d0785, this will apply a
max_value of 15, which will also be the combined value.
The same test has surprising result on 1.18, the max_value attributes get added
together for a total max_value of 47, but the values don't, so the single
highest value of 30 is used.
(the corresponding 1.18 commit is 9632febdb5)
These tests clarify what "cumulative" means for non-leadership abilites,
which since Wesnoth 1.1.3 doesn't seem to fit the English word.
For cumulative abilities, if the base value from the unit is higher that
the ability's value, then the base value is used instead. In the case of
a Skeleton with 40% base resistance, "cumulative=yes" is equivalent to
"value,cumulative=40,no".
In all of these cases, a single ability's value is used; "cumulative"
doesn't mean that the values from multiple abilities interact.
This is all when using value=, not when using add= or sub=.
(cherry picked from commit 9b2016a4af)
If two [damage_type]alternative_type= are used with two different types, the chosen type displayed in the pre-combat window will be the one to which the opponent is most vulnerable. That type will then also be used in the attack if it is stronger than the original/replacement_type.
In the sidebar (report) all alternative_types are displayed.
---------
Co-authored-by: Gunter Labes <soliton@wesnoth.org>
max_value is used to limit the increase in resistance with the "resistance" capability, but there was no equivalent for its reduction.
To be able to add min_value without redoing the "resistance" checking for the umpteenth time, I prefer to modify effect:: so that the checking of these two attributes is done at the same time as the other numerical attributes and keep the door open to a possible generalization of the proceed
When [damage_type] is used but the opponent uses the resistance ability
against the added type, the ability filter only detected the original type and
the new type was not affected.
* Fix#8460 [effect] apply_to=variation
Previously the code could apply the variation effects
last, so that codes like
```
[effect]
apply_to=variation
..
[/effect]
[effect]
apply_to=hitpoints
heal_full=yes
[/effect]
```
Would not set the unit hitpoints to the new variations
hitpoints because the variation effect was applied after
the healing effect.
In 1.16 this worked because healing was applied a little
too often but that lead also to bugs like #8342
* f prev
* f prev
* f prev
* f prev
* f prev
* Create modification_effect_type_variation.cfg
* Update wml_test_schedule
Change the Lua implementation to directly call the
non-deprecated function, this is related to 9daa10a9f2.
Clean up the C++ header files by removing the declarations of
functions that were removed in 3c8de46771.
Use [endlevel]end_credits=no in the test scenario (trigger it
by moving to hex 9,3). If you debug with :next_level without
triggering the moveto, "The End" will show; trigger the moveto
first, and it won't show the credits.
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.
previously it needed multiple calls to remove multiple types of modifications (which could be slow since each call involves a full rebuild of the unit).
The ability's code in UtBS hasn't changed since 1.16, but there's now a bug about
healing sometimes not working in UtBS S02. The new test was written to check
for an engine bug when a healer has two units next to it, only one of which
passes the filter; although it's passing, it seems reasonable to keep the test.
Also, use `{ASSERT ...}` for better logging in the old healing test.
At the suggestion of @stevecotton, I propose a special 'replacement_type' and 'alternative_type' attribute capable of modifying the type of attack used when the conditions are met.
Also make Holy water combine arcane damage with native type of weapon
Like holy water imbued ordinary weapon, it's seem logic what arcane damage dominant what if more efficient what original type(water can't altered pierce or blading of spear or sword)
Fix https://github.com/wesnoth/wesnoth/issues/7923 .when we want to detect an ability with value=0-20 and an ability with add=15 is present, this is detected because the system assigns a value of 0 when 'value' is not present, and so the system matches abilities that do not use 'value' or even no numerical value at all. it is therefore necessary to decide that the absence of an attribute is a non-correspondence to the criteria.
There are questions about how this filter should treat empty values, and the
use cases that we can think of can be implemented in other ways, for example,
if we want to look for big damage boosts, then we could filter for
`add=5-infinity` `[or]` `multiply=2-infinity`.
The simple answer seems to be to remove it from the API before we freeze for 1.18.
There's more discussion in issue 7944.
using overwrite_specials alone means that we have only two possibilities, either one_side is chosen and in this case if the ability used as a weapon carrying the attribute is applied to the unit (apply_to=self), the other abilities are the same type applied also to 'self' not carrying the attribute will be overwritten, but those of the opponent with apply_to=opponent will be kept in the list; or else both_sides is chosen and all abilities of the same type that do not carry the attribute will be overwritten. To be able to use the attribute in abilities like [damage] for example, it is necessary to be able to be even more selective as for a 'charge' type leadership with multiply=2.5 but which must not be combined with the classic charge and without overwriting the aute [damage] as backstab, [overwrite_filter] to only match damage with apply_to=both and active_on=offense is then interesting.
adding priority allows you to select that it ability can use its overwrite_specials attribute while the others can be overwritten in the same way as an ability without the attribute. Finally, this system makes it unnecessary to limit the use of the attribute to abilities used as weapons but also to special weapons.
