resolve [filter_attack/weapon]type= can check both type when it wait only effective type.
* add 'base_type' filter for detect original type of attack reagrdless of [damage_type] modifications
if for some reason the original type must be filtered instead of effective type, this attribute is here for that.
* add effective_type in formulas
Resolves https://github.com/wesnoth/wesnoth/issues/7926
[filter_ability] and [filter_ability_active] have been merged into a single filter equipped with the 'active' attribute which when the value is 'true' checks the units affected by the sought ability and when the value is 'false' or unset will check the units carrying the ability even if they are not affected by it.
Because of the attribute strategy, I'm afraid that the developer will be mistaken about its function and that's why I'm not at all keen on it but I want to get out of this impasse.
This attribute, when set to a valid value of lawful|neutral|chaotic|liminal, will assign to the weapon a different alignment than the unit alignment used by default. This alignment is then used when attacking with this weapon.
The attribute is not accessible from lua so far since the fallback to unit alignment does not work.
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.
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.
Add 'ability_id_active' attribute to filter
Until now, only the type of ability could be filtered with activity, and id only for unit who have ability, same if she's inactive.
This adds running the WML schema validation in travis. It also updates the schema itself and fixes a few WML errors so that core and all campaigns under all difficulties pass the schema validation.
- Allow for variable substitution in filter tags (mostly)
- Fix real not matching numbers like .5
- Support x,y=recall,recall
After this commit, there are no schema errors in the tutorial.
Currently this is disabled by default
Use --validate command-line argument to enable
The following new features were added in the schema format:
* Union, intersection, and list types
* Keys can specify a union of known types on-the-fly
* Key and tag names can include wildcards (* and ?, glob-style)
* Tags support any_key=yes, which means unrecognized subtags will be ignored
* Tags and keys support deprecated=yes (unimplemented)
* Specify max=infinite instead of max=-1
