Mutiple events of the same type - when?
Moderator: Forum Moderators
Forum rules
- Please use [code] BBCode tags in your posts for embedding WML snippets.
- To keep your code readable so that others can easily help you, make sure to indent it following our conventions.
-
- Posts: 1308
- Joined: August 26th, 2018, 11:46 pm
- Location: A country place, far outside the Wire
Mutiple events of the same type - when?
I've noticed that some events can have multiple instances. A good example of this is moveto.
Some don't seem to allow this, such as prestart.
I'm not seeing a reason why in the wiki. I'm guessing it is based on filters, which makes some sense (though I'm not sure what happens if multiple events have filters which match, say a moveto based on x,y and a moveto based on terrain type, assuming that's possible). It sounds like id could play a role here, if used.
I'm looking at some code (teleport units to leader in LotI) which is used in multiple scenarios, and requires updates to set_menu_item, prestart, new turn, and probably scenario_end. I'd like to wrap this all up in macro, so including said functionality is simple and repeatable. So ideally, the macro would contain a prestart event which adds some things which need to be initialized when providing the teleport functionality, but I don't want to override any existing prestart. Is this kind of thing even possible?
TIA
Some don't seem to allow this, such as prestart.
I'm not seeing a reason why in the wiki. I'm guessing it is based on filters, which makes some sense (though I'm not sure what happens if multiple events have filters which match, say a moveto based on x,y and a moveto based on terrain type, assuming that's possible). It sounds like id could play a role here, if used.
I'm looking at some code (teleport units to leader in LotI) which is used in multiple scenarios, and requires updates to set_menu_item, prestart, new turn, and probably scenario_end. I'd like to wrap this all up in macro, so including said functionality is simple and repeatable. So ideally, the macro would contain a prestart event which adds some things which need to be initialized when providing the teleport functionality, but I don't want to override any existing prestart. Is this kind of thing even possible?
TIA
Re: Mutiple events of the same type - when?
You can't show a
[message]
in a prestart, which might be why it doesn't seem to work in your tests. Try putting some units on the map, and you'll see that multiple prestart events work.-
- Posts: 1308
- Joined: August 26th, 2018, 11:46 pm
- Location: A country place, far outside the Wire
Re: Mutiple events of the same type - when?
Hmm. I didn't use a [message]. I set a couple variables. Originally, they were set in the one prestart event and that worked. When I moved them to a second prestart event (included from a macro), they never got set. And if I look at debug>inspect>events, I only see one prestart which is my new one (which looks like it should be setting the variables).
Still, it's good to know that I can use multiple events, thank you, that gives me something to work from. Not that it matters at this point, but are they executed in order of definition, or "randomly"? Could I use an id= to enforce an order?
Still, it's good to know that I can use multiple events, thank you, that gives me something to work from. Not that it matters at this point, but are they executed in order of definition, or "randomly"? Could I use an id= to enforce an order?
Re: Mutiple events of the same type - when?
Functionality stays the same no matter if you use macro or WML. When in doubt remove macros and look pure WML.white_haired_uncle wrote: ↑June 28th, 2023, 12:43 pm I'd like to wrap this all up in macro, so including said functionality is simple and repeatable.
Event priority is in progress https://github.com/wesnoth/wesnoth/issues/7582
Make sure you have first_time_only=no. If event is not relevant anymore it wont be visible in debug either.I only see one prestart which is my new one (which looks like it should be setting the variables).
-
- Posts: 1308
- Joined: August 26th, 2018, 11:46 pm
- Location: A country place, far outside the Wire
Re: Mutiple events of the same type - when?
I think I might see what's happening here. Maybe.
The [set_menu_item] stuff that I want to replace is itself in a prestart event. So I'm trying to create a prestart event inside a prestart event. Which works, but there's no guarantee it will ever get run. I think this explains why before I started using first_time_only=no it still showed up but the other (outer) one didn't.
I also create a new turn event inside the outer prestart, and that works fine, BTW.
In my case, I don't really need a second prestart, I can just use new turn (perhaps an additional new turn with first_time_only=yes).
If I could set priorities on the prestart events, I could probably force the new one to be fired after the outer one. At least until systemd infects that too.
Thanks for the help
The [set_menu_item] stuff that I want to replace is itself in a prestart event. So I'm trying to create a prestart event inside a prestart event. Which works, but there's no guarantee it will ever get run. I think this explains why before I started using first_time_only=no it still showed up but the other (outer) one didn't.
I also create a new turn event inside the outer prestart, and that works fine, BTW.
In my case, I don't really need a second prestart, I can just use new turn (perhaps an additional new turn with first_time_only=yes).
If I could set priorities on the prestart events, I could probably force the new one to be fired after the outer one. At least until systemd infects that too.
Thanks for the help
Re: Mutiple events of the same type - when?
Why you need prestart then? [fire_event] the one which contains what you need during existing prestart event.
-
- Posts: 1308
- Joined: August 26th, 2018, 11:46 pm
- Location: A country place, far outside the Wire
Re: Mutiple events of the same type - when?
I don't. I started off down a path to solving a problem. When confronted with new information, I changed my implementation of the solution to the problem, without going back to address whether this new information should have challenged my understanding of the problem itself.