Building an alternative to ActionWML

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: 1225
Joined: August 3rd, 2012, 11:26 pm
Contact:

Building an alternative to ActionWML

Post by Celtic_Minstrel » September 23rd, 2018, 3:28 pm

There has been a lot of talk about deprecating ActionWML some day, and there are a number of reasons why it has never happened. One of the big reasons, though, is that there's no complete alternative to ActionWML. If you want to code your scenario entirely in Lua, you can technically do it now, but you're actually still using ActionWML. This post is a collection of proposals to make it possible to completely avoid ActionWML. Even taken together, I'm not confident that they'd be quite enough to deprecate ActionWML if implemented, but they would overcome the biggest hurdles to deprecating it.

The first two of these ideas address the biggest hurdles to deprecating ActionWML.

Dormant events

I'd like to propose a new type of event, which I'm calling a "dormant" event. A dormant event is never triggered, even if the event occurs and the conditions match. It's not even triggered if a [fire_event] call matches it.

You might ask, how is this useful?

Well… a dormant event must have an ID – it's an error if it doesn't! It would not need a name, however. We would then add a new Lua API function, wesnoth.activate_event(id [, name]), which turns the event into a regular event so that it can now trigger. If the optional name parameter is passed, that overrides any name attribute that was specified in the event. We'd likely also add an [activate_event] ActionWML tag that wraps the function.

To specify that an event is dormant, I'd like to propose adding a new key to the [event] tag. It could either be active=no (default yes) or dormant=yes (default no). If the key is present with the specified value, the event becomes dormant and won't ever be triggered until it is explicitly activated.

Why might we want this, you wonder? The intent is to flatten nested events, because the Lua API for adding an event is still rather poor, and thus using events as ActionWML interferes with our ability to deprecate ActionWML… but if all the events were already present in the file, just not yet activated, then that problem would be solved.

I think this could also help with some minor issues we've discussed regarding the save game format (de-duplication of events, basically).
Example:
Events written in Lua

The #1 reason why we cannot deprecate ActionWML is that ActionWML is currently the only way to write an event. Even if you try to write the event entirely in Lua, that [lua] tag is still an ActionWML tag. In order to deprecate ActionWML, what we really need is something new. I'm going to take a leaf from the AI basket here.

So basically, we need another new kind of event, a Lua event. A Lua event would contain the regular keys (name, id, etc), maybe some filter tags, and optionally one or more [args] tags. It would not contain any ActionWML tags. Instead, it would contain some of the following new keys (exact names up for debate):
  • definition - The path to a Lua file defining the event. Might be optional, if the "Scenarios written in Lua" proposal is implemented; in that case this would default to the scenario's definition file. This key might be renamed, I just couldn't think of a better name for it.
  • evaluate - A Lua expression called to determine whether to trigger the event; defaults to true. Semantically this works the same as a [filter_condition] (which is still supported) but is written in Lua instead of ConditionalWML.
  • execute - A Lua statement called when the event is triggered; defaults to self(...). In both this and evaluate, the local variable self evaluates to the file loaded from definition; the variable ... contains the [args] tags as an array of WML tables.
This allows you to separate out each event into a separate file, if you want to. Or, if you prefer, you could put them all into the same file, in which case your execute values would look something like self.some_function(...). The file referenced by definition would be loaded using wesnoth.require.

In addition to [event], these new keys could be used in place of [command] in [menu_item], [set_menu_item], and possibly even [message][option]. The [menu_item] tag is a (possibly undocumented?) tag that behaves similar to [set_menu_item] (in that it adds a new menu item) but occurs outside an event, at scenario level; it's used in the save game format to track added menu items.
Spoiler:
Scenarios written in Lua

I'm less enthusiastic about this one, but... some people might prefer to even write their events entirely in Lua. Personally I don't think this is very useful, but... if there's demand for it, we could add a definition key in scenario tags that tags a path to a Lua file. It could be called before prestart (and even before onload) with the scenario WML as an argument, perhaps even giving the opportunity to actually mutate the scenario WML before it's processed.

Expanding Lua API

A number of core ActionWML tags have no clear alternative in Lua. It's not that they're impossible to do in Lua; it's just that they perform tasks that can get quite complex. Examples include [message] and [object], as well as [unit]. Before ActionWML can be deprecated, these need to have alternatives baked into the Lua API (rather than merely accessible through wesnoth.wml_actions.

You might say, "but [message] and [object] already have Lua ways!". But that's not entirely true. The underlying things they do are all possible in Lua, of course - the tags are implemented in Lua, after all. But if you take a look at that implementation you'll see there's a lot of logic going on there. Someone wishing to get the same effect without calling into the WML tags will have a lot of work on their hands. In other words, the lower-level Lua API is there, but we need some higher-level APIs too if we're to have any hope of deprecating ActionWML. Who would want to write 20 lines of code just to show a single line of dialogue for one character? No-one, I presume. We need something better.

Some examples:
  • A way to place a unit on the map using placement rules is needed. Perhaps something like wesnoth.place_unit(unit, "leader", true, false), with the booleans controlling whether to ensure the target space is passable and whether to find a vacant space if it's occupied. This is different from put_unit which always places the unit exactly in the specified location. It would also fire the unit placed event (at least by default), which if I recall correctly is not the case with put_unit (at least by default).
  • A high-level message function (or perhaps a builder) that can do everything the message tag can do. This would really need to support everything, especially options and text input. It could include support for dispatching the selected option to a Lua callback, or it could just return some indication of which option was chosen so that the following code can decide how to react.
  • For the most common case of messages without options, a unit:speak() function that just takes a translatable string and does all the logic to show that as a line of dialogue spoken by that unit. Like all unit metaclass methods it would also be accessible directly through the metatable (though that's not the case yet), so you can also call it as a free function with the unit as the first parameter. (Basically like wesnoth_unit.speak(u, msg) or u:speak(msg); exact metatable name to be determined.)
  • A function to animate moving a unit along a path, the same as [move_unit]. Perhaps other functions that wrap commonly-used animations, too.
Any ActionWML tag that has an implementation of more than a few lines might be a candidate for needing a higher-level Lua API, though there are some exceptions – [set_variable] doesn't need any further Lua support, for example, and most of the functionality of [modify_side] wouldn't need any further support either.

Decoupling Objectives from ActionWML

There's one other obstacle that I know of to deprecating ActionWML, and that's the fact that objectives are hopelessly coupled with it. Normally, the only ActionWML tag that the engine ever invokes directly is [command], when running the contents of an event or menu item. However, every time you show the objectives, it also invokes [show_objectives] in order to ensure the objectives are up-to-date with any changed variable values since they were last shown.

I can think of two ways to decouple this; one is to call a Lua hook instead of [show_objectives] (and the default hook invokes the tag). Another would be to change how objectives are stored, so that they don't need to be completely recalculated every time they are shown; currently, they're just a simple string. I'm not sure what the best option is here, but obviously something has to change, otherwise it'll be impossible to ever fully do away with ActionWML.
Author of The Black Cross of Aleron campaign and Default++ era.
Maintainer of Steelhive.

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

Re: Building an alternative to ActionWML

Post by gfgtdf » September 23rd, 2018, 4:08 pm

Even if you try to write the event entirely in Lua, that [lua] tag is still an ActionWML tag
this is wrong, [lua] tags in [scenario] are are parsed directly by the c++ engine and not part of actionwml.
Scenarios written in Lua
not oynl that you can write event entiely on lua with on_event already, you can even wrote scenarioes entirely in lua (which generated wml though) with scenario_generation=lua


i think that basicially everything you propose is already possibel with the current lua way, maybe with a slighly diffent syntax. In particular, if you currently wanted to use lua your first exampel would read:

Code: Select all

.. lua part 

function wml_actions.scout_trigger()
	wml_actions.message{speaker = 'unit', message = _"Oh no! There's even more here!"}
	wml_actions.message{speaker = 'leader', message = _"All we can do is hold out until the scouts return..."}
	wml_actions.event{ name = string.format("turn %i", wesnoth.current.turn + 4), tag.scout_returns{} }
end

function wml_actions.scout_returns()
	wml_actions.message{speaker = 'scout', message = _"I have returned!"}
end

.. wml part

[event]
	name=moveto
	[filter]
		x,y=12,22
	[/filter]
	[scout_trigger][/scout_trigger]
[/event]

of cource you could also do it compleley in lua:

Code: Select all

.. lua part 

on_event("start", function(cfg)
	wml_actions.event{ name = "moveto", tag.filter { x=12,y=22}, tag.scout_trigger{} }
end)

function wml_actions.scout_trigger()
	wml_actions.message{speaker = 'unit', message = _"Oh no! There's even more here!"}
	wml_actions.message{speaker = 'leader', message = _"All we can do is hold out until the scouts return..."}
	wml_actions.event{ name = string.format("turn %i", wesnoth.current.turn + 4), tag.scout_returns{} }
end

function wml_actions.scout_returns()
	wml_actions.message{speaker = 'scout', message = _"I have returned!"}
end



and currently i think the 'old' syntax is cleaner. Also note that even with your new syntax, people would probably still just put the old actionwmltags in [args] and have a handler that just executed them.

So in conclusion i dont think the event systrm really doesn't need be changed for this, what must be done if you want to amke people use more lua more ithough is to:
1) Give lua requavalents equivalents all tags,as you mentioned.
2) Port mainline to lua to give a good example
3) Make loading lua files a littel more convinient, for example it woudl be nice if a scenario with the id 'the_first_day' would automaticially load the lua file 'a_first_day.lua' if it exists, not sure what woudl be exactly the best way here.
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: 1225
Joined: August 3rd, 2012, 11:26 pm
Contact:

Re: Building an alternative to ActionWML

Post by Celtic_Minstrel » September 23rd, 2018, 4:34 pm

gfgtdf wrote:
September 23rd, 2018, 4:08 pm
Even if you try to write the event entirely in Lua, that [lua] tag is still an ActionWML tag
this is wrong, [lua] tags in [scenario] are are parsed directly by the c++ engine and not part of actionwml.
You completely misread what I said there. Yes, I know that about scenario-level Lua; that's not what I was talking about.
gfgtdf wrote:
September 23rd, 2018, 4:08 pm
i think that basicially everything you propose is already possibel with the current lua way, maybe with a slighly diffent syntax. In particular, if you currently wanted to use lua your first exampel would read:
I did say it's kinda possible already. The problem is in the syntax. Neither of your two examples satisfies me - the first is still using ActionWML, and the second is adding the events from Lua, which in my opinion is not a nice way to do it.
gfgtdf wrote:
September 23rd, 2018, 4:08 pm
So in conclusion i dont think the event systrm really doesn't need be changed for this,
If you look at it from the perspective that ActionWML might someday be removed entirely, it's clear that this statement is false. Both your examples rely on the existence of the ActionWML system in order to work. We need a new type of event that doesn't pass through ActionWML at all – it just directly calls a Lua handler. Whether it has the proposed syntax is, of course, not set in stone, but we do need something new.
Author of The Black Cross of Aleron campaign and Default++ era.
Maintainer of Steelhive.

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

Re: Building an alternative to ActionWML

Post by gfgtdf » September 23rd, 2018, 4:58 pm

You completely misread what I said there. Yes, I know that about scenario-level Lua; that's not what I was talking about.
if you were taking abotu actionwml lua then you statemenjt is still wrong, becasoue you dont need that for execute lua events if you can use toplevel lua tags, in either case, your implied statement 'Even if you try to write the event entirely in Lua, you need ActionWML' is wrong.
I did say it's kinda possible already. The problem is in the syntax. Neither of your two examples satisfies me - the first is still using ActionWML, and
is this a very bad reason, you implycialy saying, the actionwml implenentation code is bad by itself without giving any reason, The main reasons that why peoepl dislike 'actionwml', that is, the reyiance an store-unstore, the shittly control flow tags, the dependence on macros, etc don't apply if you use it this way. What i basically mean is: you dont write _programmcode_ in wml if you use it like that.
the second is adding the events from Lua, which in my opinion is not a nice way to do it.
Again you give no reasony why you don't like it, i have used it often in my addons and found it very easy and clean to use, the main problem with it are its interactions with wmltables which just badly translate to lua tables. in particular with set_variable etc. which is ahat your suggestion doesn't solve at all.

If you look at it from the perspective that ActionWML might someday be removed entirely, it's clear that this statement is false.
even if not, you then have two system that do exaclty the same thing, for no reason at all which is just as bad.
Both your examples rely on the existence of the ActionWML system in order to work.
yes i and i see nothign bad with this.
We need a new type of event that doesn't pass through ActionWML at all – it just directly calls a Lua handler. Whether it has the proposed syntax is, of course, not set in stone, but we do need something new.
why is that? why do we need a new sytax that has no advantages over the old syntax?
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
Pentarctagon
Forum Administrator
Posts: 3543
Joined: March 22nd, 2009, 10:50 pm
Location: Earth (occasionally)

Re: Building an alternative to ActionWML

Post by Pentarctagon » September 23rd, 2018, 5:13 pm

gfgtdf wrote:
September 23rd, 2018, 4:58 pm
If you look at it from the perspective that ActionWML might someday be removed entirely, it's clear that this statement is false.
even if not, you then have two system that do exaclty the same thing, for no reason at all which is just as bad.
Both your examples rely on the existence of the ActionWML system in order to work.
yes i and i see nothign bad with this.
We need a new type of event that doesn't pass through ActionWML at all – it just directly calls a Lua handler. Whether it has the proposed syntax is, of course, not set in stone, but we do need something new.
why is that? why do we need a new sytax that has no advantages over the old syntax?
Unless I've misunderstood completely, I don't think the proposal is to add ways to not need ActionWML at all and then continue keeping ActionWML in addition to this new way. Rather, the proposal is to make WML only be used for structural things, and then use lua for everything requiring logic.
99 little bugs in the code, 99 little bugs
take one down, patch it around
-2,147,483,648 little bugs in the code

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

Re: Building an alternative to ActionWML

Post by gfgtdf » September 23rd, 2018, 5:16 pm

the post you are quoting are an answer to his post saying actionwml will _not_ be compltetely removed ('If you look at it from the perspective that ActionWML might someday be removed entirely, it's clear that this statement is false. ').

ok maybe i misread, i read it as that 'this statement is false' refers to 'that ActionWML might someday be removed entirely', if it refers to my post, then again, is see no reasion to revmove it entirely, all we have to do, it not to use it to do progammcode and simply use it as a map for the lua event handlers.
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: 1225
Joined: August 3rd, 2012, 11:26 pm
Contact:

Re: Building an alternative to ActionWML

Post by Celtic_Minstrel » September 23rd, 2018, 5:27 pm

gfgtdf wrote:
September 23rd, 2018, 4:58 pm
if you were taking abotu actionwml lua then you statemenjt is still wrong, becasoue you dont need that for execute lua events if you can use toplevel lua tags, in either case, your implied statement 'Even if you try to write the event entirely in Lua, you need ActionWML' is wrong.
In fact, even if you do use toplevel Lua tags, you still need to use ActionWML when you actually add events from that Lua code.
gfgtdf wrote:
September 23rd, 2018, 4:58 pm
the main problem with it are its interactions with wmltables which just badly translate to lua tables.
Yes, this is exactly the problem. Filters in particular don't work as well in Lua as they do in WML, largely because of the and/or/not tags.
gfgtdf wrote:
September 23rd, 2018, 4:58 pm
in particular with set_variable etc. which is ahat your suggestion doesn't solve at all.
I'm not sure what you're getting at with this part.
gfgtdf wrote:
September 23rd, 2018, 4:58 pm
even if not, you then have two system that do exaclty the same thing, for no reason at all which is just as bad.
Huh? What's so bad about that? I can see potential objectives if the idea were to keep them both around indefinitely, but when it's part of a transitional period… frankly, I consider it absolutely necessary to have two systems doing the exact same thing.
Pentarctagon wrote:
September 23rd, 2018, 5:13 pm
Unless I've misunderstood completely, I don't think the proposal is to add ways to not need ActionWML at all and then continue keeping ActionWML in addition to this new way. Rather, the proposal is to make WML only be used for structural things, and then use lua for everything requiring logic.
gfgtdf wrote:
September 23rd, 2018, 5:16 pm
ok maybe i misread, i read it as that 'this statement is false' refers to 'that ActionWML might someday be removed entirely', if it refers to my post, then again, is see no reasion to revmove it entirely, all we have to do, it not to use it to do progammcode and simply use it as a map for the lua event handlers.
Yes, the false statement was about the need to change the event system. Why would we leave vestiges of a system that we don't want people to use? Better just to create something new which doesn't rely on the old system that you want to get rid of.
Author of The Black Cross of Aleron campaign and Default++ era.
Maintainer of Steelhive.

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

Re: Building an alternative to ActionWML

Post by gfgtdf » September 23rd, 2018, 5:54 pm

In fact, even if you do use toplevel Lua tags, you still need to use ActionWML when you actually add events from that Lua code.
you can use on_event, as i said before, you don't need actionwml for that.
in particular with set_variable etc. which is what your suggestion doesn't solve at all.
.. Yes, this is exactly the problem. Filters in particular don't work as well in Lua as they do in WML, largely because of the and/or/not tags.
And what you you going to do about it/how does your suggestion improve the situation?
Note that a lot of filters do not appear in event filters but rather in argument to tags/lua functions like store_unit/get_units, store_locations(get_locations etc.
Huh? What's so bad about that? I can see potential objectives if the idea were to keep them both around indefinitely, but when it's part of a transitional period… frankly, I consider it absolutely necessary to have two systems doing the exact same thing.

Yes, the false statement was about the need to change the event system. Why would we leave vestiges of a system that we don't want people to use? Better just to create something new which doesn't rely on the old system that you want to get rid of.
The point is that you so far gave no reason why the old actionwml system is bad, or why you dont wan people to use that, or why the new one is better.

I say that bad thing currently is not actionwml itself, but just rather how its used: to write progamm code. If you use it as a simple map to match the 'event' to the hander rather than being the handler itself, then there is nothing bad about it.

Also note that, even with your proposal it doesnt really solve the problem of people abusing wml: people can still put their old actionwml code in [args], copy a lua code that executes them to their addon, and progably add WML_EVENT macro for convinience to make just as easy as with the old syntax.
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: 1225
Joined: August 3rd, 2012, 11:26 pm
Contact:

Re: Building an alternative to ActionWML

Post by Celtic_Minstrel » September 23rd, 2018, 6:30 pm

gfgtdf wrote:
September 23rd, 2018, 5:54 pm
In fact, even if you do use toplevel Lua tags, you still need to use ActionWML when you actually add events from that Lua code.
you can use on_event, as i said before, you don't need actionwml for that.
...

Um, like all your other proposals, on_event is built on top of ActionWML. It does make adding events from Lua a little nicer, admittedly, but it doesn't help to avoid ActionWML.
gfgtdf wrote:
September 23rd, 2018, 5:54 pm
And what you you going to do about it/how does your suggestion improve the situation?
Note that a lot of filters do not appear in event filters but rather in argument to tags/lua functions like store_unit/get_units, store_locations(get_locations etc.
Yeah, I don't think that's easy to solve. For some use-cases you could put filters in [args]; but that won't always work.
gfgtdf wrote:
September 23rd, 2018, 5:54 pm
I say that bad thing currently is not actionwml itself, but just rather how its used: to write progamm code. If you use it as a simple map to match the 'event' to the hander rather than being the handler itself, then there is nothing bad about it.
I don't get your logic here. ActionWML is program code. What you're proposing is to keep ActionWML but not write program code with it.
gfgtdf wrote:
September 23rd, 2018, 5:54 pm
Also note that, even with your proposal it doesnt really solve the problem of people abusing wml: people can still put their old actionwml code in [args], copy a lua code that executes them to their addon, and progably add WML_EVENT macro for convinience to make just as easy as with the old syntax.
Well... yes, I can't deny that they could do that, but then it'll be entirely their own fault if it breaks later when ActionWML is eventually removed.
gfgtdf wrote:
September 23rd, 2018, 5:54 pm
The point is that you so far gave no reason why the old actionwml system is bad, or why you dont wan people to use that, or why the new one is better.
WML is fundamentally a markup language. It's designed for data, not code, and it does quite well on that front, actually. (I'm not saying it's the best or anything, but it does an acceptable job of encoding data.) But ActionWML is fundamentally code. You're writing code in a markup language. It also quickly gets unwieldy, particularly when using flow control structures that require two extra levels of indentation.

Why is the new proposal better? Because you write all your code in Lua. There's no WML involved. I'm not saying it's a perfect solution, but that's why I've started this thread, so that we can discuss it and decide if it's a good enough solution or if we can work out an even better solution. For example, perhaps you'd prefer to have the option of writing your Lua code inline, as is currently possible with [lua] tags. If so, the proposal can be tweaked to support that.

Can we please stop with the arguments that ActionWML should not be removed and start talking from the premise that, assuming ActionWML will be removed, we need to come up with something better? Maybe in the end we'll decide not to do it, but arguments for why ActionWML actually isn't that bad are not helping here.
Author of The Black Cross of Aleron campaign and Default++ era.
Maintainer of Steelhive.

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

Re: Building an alternative to ActionWML

Post by gfgtdf » September 23rd, 2018, 6:44 pm

Celtic_Minstrel wrote:
September 23rd, 2018, 6:30 pm
WML is fundamentally a markup language. It's designed for data, not code, and it does quite well on that front, actually. (I'm not saying it's the best or anything, but it does an acceptable job of encoding data.) But ActionWML is fundamentally code. You're writing code in a markup language. It also quickly gets unwieldy, particularly when using flow control structures that require two extra levels of indentation.
All this points don't apply if you just use the actionwml 'engine' to map events to handler like my example in my first post does.
Celtic_Minstrel wrote:
September 23rd, 2018, 6:30 pm
Why is the new proposal better? Because you write all your code in Lua. There's no WML involved. I'm not saying it's a perfect solution, but that's why I've started this thread, so that we can discuss it and decide if it's a good enough solution or if we can work out an even better solution. For example, perhaps you'd prefer to have the option of writing your Lua code inline, as is currently possible with [lua] tags. If so, the proposal can be tweaked to support that.

Can we please stop with the arguments that ActionWML should not be removed and start talking from the premise that, assuming ActionWML will be removed, we need to come up with something better? Maybe in the end we'll decide not to do it, but arguments for why ActionWML actually isn't that bad are not helping here.
No, because so far you have been consequenctly ignoring my main point which is that if you use actionwml like i said in my first example, you are not using wml to write code. Even in this quoted post , you fail to make a difference beween the actionwml 'engine' and the common usage of actionwml how most addons/mainline use it.
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: 1225
Joined: August 3rd, 2012, 11:26 pm
Contact:

Re: Building an alternative to ActionWML

Post by Celtic_Minstrel » September 23rd, 2018, 7:10 pm

I don't see why you insist on making this distinction between an "engine" and a "common usage". Your distinction doesn't make any sense. It's all part of ActionWML, after all. If you're removing it, why would you want to keep vestiges of it around?
Author of The Black Cross of Aleron campaign and Default++ era.
Maintainer of Steelhive.

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

Re: Building an alternative to ActionWML

Post by gfgtdf » September 23rd, 2018, 7:32 pm

If we removed all actionwml tags (maybe except "command" for technical reasons) (i'm not really propsing that) (we codul also force the maximum number of nonfilter tags in a event to 1 but i don't really see an advntage in that), we'd basicially have a lua-only event engine without the disadvantages of the old actionwml that would allow writing events like i did in my first post. In particular it would for example allow 1.14 authors to write forward compatible code already. I also think it is a little easier to use than your suggestion, for example in your samplecode the author needs to explcitly write a id=scout_returns event warpper around the scout_returns function, while in my code the scout_trigger handler can just reference the scout_returns lua function directly.
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.

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

Re: Building an alternative to ActionWML

Post by josteph » September 23rd, 2018, 7:40 pm

gfgtdf's example uses WML for filtering: tag.filter { x=12, y=22 }. Even today, using the [lua] tag one can write their events logic in lua, but conditions have to be written in WML, right? Would it help to implement a condition tag that evaluates a lua expression? For example

Code: Select all

[lua]
function scout_trigger()
    print "Hello world"
end
[/lua]
[event]
    name=moveto
    # condition
    filter_lua = "function (u) return u.x == 12 && u.y == 22 end"
    # action
    [lua]
        scout_trigger();
    [/lua]
[/event]
instead of [filter]x,y=12,22[/filter].

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

Re: Building an alternative to ActionWML

Post by Celtic_Minstrel » September 23rd, 2018, 8:12 pm

Josteph, if you read my original proposal more carefully, you'll see that I have that in there already – it's the evaluate key. Of course, it could be renamed if you don't like that – I only chose the names evaluate and execute to mirror AI candidate actions. Perhaps I should've also used location instead of definition for the same reason...

gfgtdf, if I understand correctly, you're suggesting that the wesnoth.wml_actions table becomes an index of registered events, in a sense? This is probably something that could be done, I guess. I'd need to think about it in some detail to decide whether I really like it better than my own proposal, but just off the top of my head I can see one minor disadvantage to it: the process of switching from the old to the new system is less smooth, because the new system is a mutation of the old. With my proposal, they're entirely separate and can thus very easily coexist for a period; with your idea they can probably still coexist but I think it would be more difficult.
Author of The Black Cross of Aleron campaign and Default++ era.
Maintainer of Steelhive.

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

Re: Building an alternative to ActionWML

Post by josteph » September 23rd, 2018, 8:46 pm

I saw that. What I was trying to say is, making it possible to write conditions in lua is a small incremental step, that can be done right away, in the direction you're proposing. It will be an improvement in its own right since it will let people write lua instead of using [and] and [or] and [not] and {VARIABLE_CONDITIONAL foo boolean_equals true}.

I don't disagree with your other suggestions, such as expanding the lua API. I am just saying that it is already possible to write the actions in lua, if anybody wants to (maybe because they don't want to write control structures in WML), but it's not already possible to write the conditions in lua, so maybe start there. If UMC authors write their conditions in lua and their actions in WML, it will be easier to eventually transition to an all-lua system as you propose.

Post Reply