filter_adjacent in resistance tag not working

[newfrenchy83]

I'm not asking for the number of units counted but if it's normal for you that all [filter_adjacent] in the same ability must meet the conditions, because if no conditions overlap like [filter_adjacent]race=elf and [filter_adjacent]race=human then the ability has no chance of working

[lhybrideur]

you should use

Code: Select all

[filter_adjacent]
   race=human,elf
[/filter_adjacent]

or

Code: Select all

[filter_adjacent]
   race=human
   [or]
      race=elf
   [/or]
[/filter_adjacent]

then, shouldn't you?
Because filters are "added" (&) iirc.

[newfrenchy83]

you should use

Code: Select all

[filter_adjacent]
   race=human,elf
[/filter_adjacent]

or

Code: Select all

[filter_adjacent]
   race=human
   [or]
      race=elf
   [/or]
[/filter_adjacent]

then, shouldn't you?
Because filters are "added" (&) iirc.

If filter_adjacent are 'added', then what is the point of being able to put several in the same ability?

[gnombat]

If filter_adjacent are 'added', then what is the point of being able to put several in the same ability?

Isn't it just a general rule that listing multiple filters (of any type) is equivalent to combining them with [and]?

See the example in Writing complex filters: "...a simple rule: [and] tags are not needed when they contain one single criterion or a single block..."

Of course, not every combination of filters will actually make sense. Some combinations of filters will simply match nothing.

[newfrenchy83]

Do you think this makes sense in this specific case?

[gnombat]

Do you think this makes sense in this specific case?

Wouldn't it be confusing to make a different rule just for one specific case that works differently from the way filters work everywhere else?

[Soliton]

The wiki edits are confusing...

[filter_adjacent] in an ability is definitely not from 1.19.10. It's much, much older. This was added in two places and only one was converted to a note that might be explaining a bugfix?

I don't really understand what

if a unit does not match [filter_adjacent] it is not invalidated if the other units match the standard filters as well as the direction and number conditions

might mean. It repeats [filter_adjacent] in the paragraph about [filter_adjacent] which is confusing. What other units is it talking about? Invalidated means the filter does not match? "the direction and number conditions" are the additional attributes [filter_adjacent] accepts over a SUF?

What is the point of putting multiple [filter_adjacent] in an ability? Presumably no point other than it can be done so the engine has to do something.

[newfrenchy83]

This relates to my question, what is the point of having several [filter_adjacent] if they all have to match for the ability to be active, if the correspondence is necessary for only one of them, I would understand but there it is useless

[Ravana]

Why you are talking about multiple? The example that fails only uses one.

[newfrenchy83]

Why you are talking about multiple? The example that fails only uses one.

as i told you before, if you are not using wesnoth 1.19.10 or later, then you need to put [filter_adjacent] in [filter]

[Ravana]

Soliton confirmed that [filter_adjacent] was supported before 1.19.10 too.

[newfrenchy83]

Soliton confirmed that [filter_adjacent] was supported before 1.19.10 too.

supported but bugged

[Ravana]

That contradicts what you said before. If it is so completely bugged then it was never supported at all.

[newfrenchy83]

That contradicts what you said before. If it is so completely bugged then it was never supported at all.

It's soliton who claims it was supported before 1.19.10 despite its inability to work outside of [filter], not me

[Ravana]

Last page you gave me impression [filter_adjacent] is completely broken before {{DevFeature1.19|10}}. But in https://wiki.wesnoth.org/index.php?titl ... ldid=74392 you said it still worked before as well by removing the dev feature marker.