[engine] alternate meta-condition behavior

Brainstorm ideas of possible additions to the game. Read this before posting!

Moderators: Forum Moderators, Developers

Forum rules
Before posting a new idea, you must read the following:
ArcdeSeel
Posts: 9
Joined: October 25th, 2016, 1:32 am

[engine] alternate meta-condition behavior

Post by ArcdeSeel » September 27th, 2018, 6:50 pm

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
Spoiler:
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.

gfgtdf
Developer
Posts: 1104
Joined: February 10th, 2013, 2:25 pm

Re: [engine] alternate meta-condition behavior

Post by gfgtdf » September 27th, 2018, 6:57 pm

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.

User avatar
pauxlo
Posts: 1034
Joined: September 19th, 2006, 8:54 pm

Re: [engine] alternate meta-condition behavior

Post by pauxlo » September 28th, 2018, 9:30 pm

ArcdeSeel wrote:
September 27th, 2018, 6:50 pm
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.
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.

User avatar
Sapient
Inactive Developer
Posts: 4452
Joined: November 26th, 2005, 7:41 am
Contact:

Re: [engine] alternate meta-condition behavior

Post by Sapient » September 29th, 2018, 6:10 pm

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."

josteph
Developer
Posts: 126
Joined: August 19th, 2017, 6:58 pm

Re: [engine] alternate meta-condition behavior

Post by josteph » September 29th, 2018, 6:21 pm

How about adding just one tag, [any_of]?

User avatar
Celtic_Minstrel
Developer
Posts: 1246
Joined: August 3rd, 2012, 11:26 pm
Contact:

Re: [engine] alternate meta-condition behavior

Post by Celtic_Minstrel » September 29th, 2018, 11:01 pm

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
Author of The Black Cross of Aleron campaign and Default++ era.
Maintainer of Steelhive.

User avatar
Sapient
Inactive Developer
Posts: 4452
Joined: November 26th, 2005, 7:41 am
Contact:

Re: [engine] alternate meta-condition behavior

Post by Sapient » September 30th, 2018, 9:36 am

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.
http://www.wesnoth.org/wiki/User:Sapient... "Looks like your skills saved us again. Uh, well at least, they saved Soarin's apple pie."

Shiki
Developer
Posts: 231
Joined: July 13th, 2015, 9:53 pm
Location: Germany

Re: [engine] alternate meta-condition behavior

Post by Shiki » September 30th, 2018, 10:55 am

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.
Maintainer of Era of Myths.
Introduction to WML filtering and WML variables.

User avatar
pauxlo
Posts: 1034
Joined: September 19th, 2006, 8:54 pm

Re: [engine] alternate meta-condition behavior

Post by pauxlo » September 30th, 2018, 1:45 pm

Sapient wrote:
September 29th, 2018, 6:10 pm
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].
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.

josteph
Developer
Posts: 126
Joined: August 19th, 2017, 6:58 pm

Re: [engine] alternate meta-condition behavior

Post by josteph » September 30th, 2018, 5:50 pm

@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 [false][/false][or][true][/true][false][/false][/or] is false because AND of true and false is false, not because the false came second.

User avatar
Celtic_Minstrel
Developer
Posts: 1246
Joined: August 3rd, 2012, 11:26 pm
Contact:

Re: [engine] alternate meta-condition behavior

Post by Celtic_Minstrel » September 30th, 2018, 8:24 pm

Sapient wrote:
September 30th, 2018, 9:36 am
As I noted in my post, [all_of] appears to be the exact same behavior as [and].
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.
  1. Example:
  2. Example:
  3. Example:
  4. Example:
If you look at those examples, but especially the last one, you can see that, if you have [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".
Author of The Black Cross of Aleron campaign and Default++ era.
Maintainer of Steelhive.

josteph
Developer
Posts: 126
Joined: August 19th, 2017, 6:58 pm

Re: [engine] alternate meta-condition behavior

Post by josteph » September 30th, 2018, 9:33 pm

Great post Celmin :D
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".
To elaborate on that, [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.

gfgtdf
Developer
Posts: 1104
Joined: February 10th, 2013, 2:25 pm

Re: [engine] alternate meta-condition behavior

Post by gfgtdf » September 30th, 2018, 10:54 pm

Celtic_Minstrel wrote:
September 30th, 2018, 8:24 pm
Consider the pseudo-Lua condition have_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]
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

Code: Select all

[have_unit]
	id=hero_unit
[/have_unit]
[or]
	[have_unit]
		id=allied_leader
	[have_unit]
[/or]
(which is actually the main reason why i don't like the current sytax (which doesnt mean i support the new tags))


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.

User avatar
Celtic_Minstrel
Developer
Posts: 1246
Joined: August 3rd, 2012, 11:26 pm
Contact:

Re: [engine] alternate meta-condition behavior

Post by Celtic_Minstrel » October 1st, 2018, 1:54 am

josteph wrote:
September 30th, 2018, 9:33 pm
To elaborate on that, [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)".
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".)
gfgtdf 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
Yes, thank you, I believe you're correct on that. Like you, I know this is the case in filters (especially WML filters, ie [filter_wml]). I'm not 100% sure that this is also true in ConditionalWML, but it wouldn't surprise me at all.
gfgtdf wrote:
September 30th, 2018, 10:54 pm
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.
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]
is equivalent to

Code: Select all

id=thing
[or]
	side=2
[/or]
[or]
	canrecruit=yes
[/or]
But I have a feeling that would get confusing in some of the more complex cases. In particular, the radius filter might be a terrible complication to it.
Author of The Black Cross of Aleron campaign and Default++ era.
Maintainer of Steelhive.

josteph
Developer
Posts: 126
Joined: August 19th, 2017, 6:58 pm

Re: [engine] alternate meta-condition behavior

Post by josteph » October 1st, 2018, 6:55 pm

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]

Post Reply