[engine] alternate meta-condition behavior
Moderator: Forum Moderators
Forum rules
Before posting a new idea, you must read the following:
Before posting a new idea, you must read the following:
[engine] alternate meta-condition behavior
Hello, Wesnoth.
The [and], [or], and [not] tags currently work very weirdly. A more intuitive version would have these tags compare any number of condition tags inside them. For example
Of course, it's impossible to change the behavior of the current tags, as it would destroy everything.
Still, it would be really useful to add an alternate set of tags, a [alt_and], [alt_or], [alt_nand], and [alt_nor] or something that would operate on the conditions within them.
The [and], [or], and [not] tags currently work very weirdly. A more intuitive version would have these tags compare any number of condition tags inside them. For example
Spoiler:
Still, it would be really useful to add an alternate set of tags, a [alt_and], [alt_or], [alt_nand], and [alt_nor] or something that would operate on the conditions within them.
Re: [engine] alternate meta-condition behavior
while i agree with you that the current syntax is rather strange, i don't think it worth keepiong two differnt syntaxes around for zthis that woudl need to be maintained etc.
Scenario with Robots SP scenario (1.11/1.12), allows you to build your units with components, PYR No preperation turn 1.12 mp-mod that allows you to select your units immideately after the game begins.
Re: [engine] alternate meta-condition behavior
Reasonable names for those would be
[all]
, [any]
, [not_all]
(not sure if it's needed, as it is a simple combination of [not]
and [all]
) and [none]
.Having those in parallel to the current and/or/not seems not too bad/confusing.
Re: [engine] alternate meta-condition behavior
For what it's worth, I find your proposal less intuitive. Furthermore, I don't see any difference between the current behavior of [and] vs your proposed tag [all], or [not] vs [not_all].
http://www.wesnoth.org/wiki/User:Sapient... "Looks like your skills saved us again. Uh, well at least, they saved Soarin's apple pie."
Re: [engine] alternate meta-condition behavior
How about adding just one tag,
[any_of]
?- Celtic_Minstrel
- Developer
- Posts: 2207
- Joined: August 3rd, 2012, 11:26 pm
- Location: Canada
- Contact:
Re: [engine] alternate meta-condition behavior
I'm not sure, but it might have been done this way to match with how filters work, where you can't get around the need for more than one
[and]
tag in some situations. That said, I wouldn't be opposed to adding tags like [any_of]
, [all_of]
, or [none_of]
. These could probably even be implemented in Lua right now, something like this (untested):Code: Select all
function wesnoth.wml_conditionals.all_of(cfg)
local passes = true
for i = 1, #cfg do
local name, tag = cfg[i][1], cfg[i][2]
passes = passes and wesnoth.eval_conditional{wml.tag[name](tag)}
end
return passes
end
Re: [engine] alternate meta-condition behavior
As I noted in my post, [all_of] appears to be the exact same behavior as [and].
However, I don't see anything wrong with adding [any_of] and [none_of] meta-condition tags.
However, I don't see anything wrong with adding [any_of] and [none_of] meta-condition tags.
http://www.wesnoth.org/wiki/User:Sapient... "Looks like your skills saved us again. Uh, well at least, they saved Soarin's apple pie."
Re: [engine] alternate meta-condition behavior
What is wrong about these tags? In my experience [and], [or], and [not] work as expected.
Everything connected by [and] – that includes everything which doesn't have a special tag, as [and] is the default – must be true, otherwise the whole filter evaluates to false.Similarly for [or].
In the example above, may it be that it's rather the [true] and [false] tags which contribute to the confusing result?
It seems they overwrite the previous [true]/[false] statement instead of being and connected like the default is.
In that case a warning in the wiki page is probably the best way to go.
I think adding tags like [any_of], [all_of], … would rather increase confusion. Probably mostly due to their uncommon names, which sound like [or], [and], but a newcomer would not see the point.
Also with the dev discussions of the last weeks in mind, I think it's not the best to extend WML with such fundamental things.
Everything connected by [and] – that includes everything which doesn't have a special tag, as [and] is the default – must be true, otherwise the whole filter evaluates to false.Similarly for [or].
In the example above, may it be that it's rather the [true] and [false] tags which contribute to the confusing result?
It seems they overwrite the previous [true]/[false] statement instead of being and connected like the default is.
In that case a warning in the wiki page is probably the best way to go.
I think adding tags like [any_of], [all_of], … would rather increase confusion. Probably mostly due to their uncommon names, which sound like [or], [and], but a newcomer would not see the point.
Also with the dev discussions of the last weeks in mind, I think it's not the best to extend WML with such fundamental things.
Try out the dark board theme.
Re: [engine] alternate meta-condition behavior
One could argues this is because there is an implicit "all of" for lists of conditions (unless there is an
[or]
in it).So basically
[and]
currently does nothing (except grouping) ([if] x [and] y [/and][then]...[/then][/if]
is the same as just [if] x y [then]...[/then][/if]
).And current
[or]
has a strange effect on conditions which are not inside it (but only the ones before it, it seems?).With the new tags, one could decide that things like
[if]
, [while]
, [not]
can only have one top-level condition in it, and if you want more than one, you need to wrap them either in [all_of]
or [any_of]
, making the nesting of tags clearly correspond to the precedence structure of the boolean expression.Re: [engine] alternate meta-condition behavior
@Shiki The weird thing about [or] is that it's defined in terms of both its siblings and its contents. [or] means "either all my siblings conditions are true, or all my children conditions are true". [any_of] would mean "true if at least one of my children conditions is true". I honestly think that's far more natural.
The [true] and [false] do not "overwrite". The contents of [or] is zero or more tags which are ANDed. The result of
The [true] and [false] do not "overwrite". The contents of [or] is zero or more tags which are ANDed. The result of
[false][/false][or][true][/true][false][/false][/or]
is false because AND of true and false is false, not because the false came second.- Celtic_Minstrel
- Developer
- Posts: 2207
- Joined: August 3rd, 2012, 11:26 pm
- Location: Canada
- Contact:
Re: [engine] alternate meta-condition behavior
I just picked one of the three at random as an example. In fact I meant to write code for any_of, but after looking at the code I actually wrote, I realized it was all_of, so I changed the tag name.
I'm not sure how it's the same behaviour as
[and]
though, but I could be missing something. From what I understand, the way these condition tags currently work (both in ConditionalWML and FilterWML) is basically what Josteph has described. I'll explain by giving several examples.- Example:
- Example:
- Example:
- Example:
[any_of]
, then you need [all_of]
in order to express arbitrarily nested conditions. Now... you might argue that you can just keep the old [and]
tag for that purpose, but that's an inconsistency. I think it would be better to keep things consistent.By the way, another weird thing about the meta-conditions is that
[not]
is not logical negation. It's "and not".Re: [engine] alternate meta-condition behavior
Great post Celmin
I missed that before, but I would support adding
To elaborate on that,Celtic_Minstrel wrote: ↑September 30th, 2018, 8:24 pm By the way, another weird thing about the meta-conditions is that[not]
is not logical negation. It's "and not".
[not] [x] [y] [z] [/not]
means "not (x and y and z)", while [none_of] [x] [y] [z] [/none_of]
would mean "not(x) and not(y) and not(z)".I missed that before, but I would support adding
[none_of]
as well.Re: [engine] alternate meta-condition behavior
i'm quite sure this is wrong, (im sure for unit filters, didn't look at conditional filter implemetation). This code will always evaulate to true because the first (toplevel) filters has not tags (except and, or etc.) and will thus return true. In the current syntax you have to write it asCeltic_Minstrel wrote: ↑September 30th, 2018, 8:24 pm Consider the pseudo-Lua conditionhave_unit("hero_unit") or have_unit("allied_leader")
. With the current condition tags, the intended way to convey this is:
Code: Select all
[or] [have_unit] id=hero_unit [/have_unit] [/or] [or] [have_unit] id=allied_leader [have_unit] [/or]
Code: Select all
[have_unit]
id=hero_unit
[/have_unit]
[or]
[have_unit]
id=allied_leader
[have_unit]
[/or]
Also your lua implementation would only work for conditional filters, not for standard unit filters, location filters etc. implementing those is harder for multiple reasons.
Scenario with Robots SP scenario (1.11/1.12), allows you to build your units with components, PYR No preperation turn 1.12 mp-mod that allows you to select your units immideately after the game begins.
- Celtic_Minstrel
- Developer
- Posts: 2207
- Joined: August 3rd, 2012, 11:26 pm
- Location: Canada
- Contact:
Re: [engine] alternate meta-condition behavior
Which, for those who've forgotten DeMorgan's law, means
[not] [x] [y] [z] [/not]
in fact gives "not(x) or not(y) or not(z)" - in other words, it's "not all of", rather than "none of". (Which is why you need multiple [not]
tags to get the effect of "none of".)Yes, thank you, I believe you're correct on that. Like you, I know this is the case in filters (especially WML filters, iegfgtdf wrote: ↑September 30th, 2018, 10:54 pm i'm quite sure this is wrong, (im sure for unit filters, didn't look at conditional filter implemetation). This code will always evaulate to true because the first (toplevel) filters has not tags (except and, or etc.) and will thus return true. In the current syntax you have to write it as
[filter_wml]
). I'm not 100% sure that this is also true in ConditionalWML, but it wouldn't surprise me at all.You're correct. However, this entire proposal wouldn't work very well for filters anyway (because most filter conditions are keys, rather than tags), so I don't see that as a blocker.
I mean, I suppose you could implement it for filters like...
Code: Select all
[any_of]
id=thing
side=2
canrecruit=yes
[/any_of]
Code: Select all
id=thing
[or]
side=2
[/or]
[or]
canrecruit=yes
[/or]
Re: [engine] alternate meta-condition behavior
For filters, how about if
[any_of]
etc could have only other tags, not attributes, as children? Like this:Code: Select all
[event]
name=moveto
[any_of]
[filter]
side=1
canrecruit=yes
[/filter]
[filter]
side=2
[/filter]
[/any_of]
[/event]