It should work even when the macro appears in the same event as the
attack; this tests that.
The new one uses the COMMON_KEEP macro, but I've left the existing
one unchanged, except for the renaming.
Fix a typo in the add_sub_separated test, because it was testing
exactly the same code as add_sub_cumulative.
Add two new tests and clarify documentation, because in these tests
the order of the abilities determines whether the add or sub value is
used, it isn't that sub always overrides add.
The tag_name check is deficient for two reasons:
1.when apply_to=both is used, in the case of [damage_type] [filter_opponent][filter_weapon]type= will check the modified type for application to the owner and the original type for application to the opponent, hence a risk of infinite recursion, especially if [filter_self][filter_weapon]type= is used in the same weapon.
2. in the case of apply_to=attacker/defender, the check for [filter_attacker/defender] must take into account both the value of the variable is_attacker but also the application AFFECT_SELF/OTHER, otherwise in the case apply_to=defender with [filter_defender][filter_weapon]type=, and[filter_attacker][filter_weapon]type= otherwise we end up in the same configuration as for apply_to=both
Finally tag_name is renamed check_if_recursion to mean that this variable is used to ensure that a recursion cannot be set up even if 743b146efc prevents it from causing a crash but with an error log
if filtering type of damage in [damage_type] for both self and opponent when apply_to=both, it will create a recursion issue.
Idem for apply_to=attacker/defender when applied to opponent of owner of special.
Using four abilities instead of two means the C++ checking_tag
mechanism needs to handle multiple values, or needs to be supported
by recursion counting.
The branching test lets one level of recursion finish, and then tries
to go deeper. This tests for bugs where a recursion detection tool in
the engine gets its count reset when exiting one level of recursion.
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
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.
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.
Adds support for using these in the weapons and ability filters:
* "-1", which was previously treated as an parse error (no number before the separator).
* "-3--1"
* "-infinity" as the lower number in the range, provided a different upper number is given.
This treats "-infinity" (with no other number), "-infinity--infinity",
"infinity" (with no other number) and "infinity-infinity" as errors. It seems
unlikely that someone would intend to use a filter that can't match any
reasonable number.
The range "-infinity-infinity" will be parsed successfully. I don't see a use
case for that, but nor do I see a reason to add extra C++ to reject it.
However, it's not added to the schema, as I think it's good for the schema to
give a warning when someone creates a filter which will accept every value
(including accepting the default, so "-infinity-infinity" accepts the unset
value too).
Includes new unit tests for the C++ and the Lua stringx.parse_range functions.
The next commit adds more WML tests, but is kept separate to credit the author.
This started as a change to move common filter functions from unit.cpp to
somewhere that they could be reused for other config-based filters. In the
process a missing feature was found and added, the move is still included in a
single Git commit because the move was required in order to make these
functions accessible to the Boost unit tests.
Two CodeBlocks project files additionally get src/utils/any.hpp added,
which was in one of them but missing from the other two. I noticed because
these are alphabetically at the start of the src/utils file list.
Thanks to @CelticMinstrel for the review comments and Xcode project updates.
