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.
give abilities support of halo or overlay so that the unit benefits from a second halo or overlay when conditions are matched
One of the things that bothers me is the permanent character of the halos of the Mage of Light and other units with the "illuminates" ability, which forces them to program only a permanent illumination applied only to the possessor of the ability.
Adding the halo attribute to ability does not change anything about the behavior of the unit, but can be used in several cases:
1 allowing the use of ""illuminates" whose activity would be variable, in this case encoding the halo in [illuminates] ability and not in the unit_type allows to modulate the appearance of the halo under the same conditions
2. Applying illumination to adjacent units, I know it's pretty cheesy but a set developer might consider it easier if the hlo display follows the same logic.
3 The halo used to illustrate the possession in the unit of a special weapon used as leadership, the halo would be used to raise the possessor of the ability.
for overlay, same logic for illustrate possession of a special weapon used as leadership, or influence on student
with the "halo_image" attribute, it is now possible to give Sun Sylph units an illumination ability with an activity depending on the incarnate sun attack instead of giving the ability and the halo via obect and therefore allowing the player to have access to the description of the ability even when it is inactive.
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.
For any given event name, events execute in order of decreasing priority.
Priority is a real number, and may be assigned via the `priority` attribute for
the WML [event] tag, or through the Lua APIs:
- wesnoth.game_events.add({priority = number})
- wesnoth.game_events.add_repeating(name, action, [priority])
Note that delayed variable substitution is not currently supported in the WML attribute.
Originally by gfgtdf, this was cherry-picked from gfgtdf's PR #7589, with
modifications.
COMMON_KEEP_A_B_UNIT_TEST gains support for optional args
SIDE1_LEADER and SIDE2_LEADER.
The new tag takes ids instead of needing coordinates. So instead of storing
units or hardcoding values, an attack can be done like this:
```
[test_do_attack_by_id]
attacker=alice
defender=bob
weapon=0
[/test_do_attack_by_id]
```
Add a simpler unit for unit tests than the Elvish Archer / Orcish Grunt
combo, cherry-picked from gfgtdf's PR #7589. This is a unit with a 10x1
melee attack, and 0% defense on all terrains.
Remove the test race's undead_variation=
For testing custom plague abilities, this triggered a warning when
converting to any unit type that doesn't have variation_id=wolf,
restricting tests to using only Walking Corpse and Soulless.
Move the line that includes data/test/scenarios/manual_tests/ below the
line that includes data/test/macros/. This allows a manual test to use
the setup in COMMON_KEEP_A_B_C_D_UNIT_TEST, putting units in the right position
to test combat and leadership abilities.
Also improve comments in data/test/_main.cfg.
Add a new guideline that reserves test names containing `_fail_`
or ending `_fail` for tests that don't `PASS`. The rest is just
collecting knowledge already written elsewhere.
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!
I think I'm using two wmlindent bugs against each other here, putting two
opening statements on the same line to balance two closing statements on the
same line. However, the unit tests ought to be code that can be cut & pasted
elsewhere without causing indentation problems, and this is simpler than fixing
wmlindent's Lua parsing.
This doesn't cover all of the unit tests, it's the result of running wmlindent
on all of them and then reviewing whether the changes were bugs in the test, or
whether they're bugs in wmlindent.
Note: there are two cve_2018_1999023 tests. The other one needs to be treated
as a binary file, but the one changed here is plain text that loads its attack
from a separate file.
The change in start_position_generic.cfg doesn't seem good, but it's not
particularly bad and it's what wmlindent currently does.
