[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:
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 3rd, 2018, 1:57 am

As it currently stands that syntax would result in the [any_of] tag being taken as ActionWMl rather than a filter; but if wrapped in a [filter] tag I suppose it could work. Not fond of the extra indentation level though. Maybe take any direct keys in [any_of] as belonging to an implicit [filter] child? I dunno.
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 3rd, 2018, 5:40 pm

I don't see how allowing [any_of] inside [event] is ambiguous. [event] takes ActionWML children but [any_of] as discussed above would be ConditionWML, so we're free to invent a new meaning in that context.

I don't understand the suggestion about an implicit [filter]. I assume in practice a [any_of] would always have at least two [filter_*] children, otherwise the [any_of] would be redundant. For "id=foo or side=2 or canrecruit=yes" I'd use [any_of] with three [filter]s inside it, one key=value in each [filter].

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 4th, 2018, 1:01 am

It can be made unambiguous, but currently the ActionWML engine only ignores tags that begin with "filter", so it would try to execute the [any_of]. You could of course add additional exceptions in the ActionWML engine if you wanted to, and I guess that could even allow you to do things like this:

Code: Select all

[any_of]
	[filter]
		ability=thing
	[/filter]
	[filter_second]
		ability=thing
	[/filter_second]
[/any_of]
Basically that means extending event syntax, not filter syntax; filter syntax is what goes inside the filter tags.
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 4th, 2018, 7:51 pm

And that syntax doesn't have an easy equivalent in current 1.14, does it? Best I can think of is to use two events:

Code: Select all

[event]
	name=foo
	[filter]
		ability=thing
	[/filter]
	[fire_event]
		name=bar
	[/fire_event]
[/event]
[event]
	name=foo
	[filter_second]
		ability=thing
	[/filter_second]
	[fire_event]
		name=bar
	[/fire_event]
[/event]

User avatar
Ravana
Moderator
Posts: 1873
Joined: January 29th, 2012, 12:49 am
Location: Estonia
Contact:

Re: [engine] alternate meta-condition behavior

Post by Ravana » October 4th, 2018, 8:12 pm

That could be done with [filter_condition], meta condition tags and [have_unit].

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 4th, 2018, 11:58 pm

Which definitely smells of a hack though...
Author of The Black Cross of Aleron campaign and Default++ era.
Maintainer of Steelhive.

Post Reply