[Engine] WML "Game Idle" event

[Samonella]

The idea is that this event would be a way to postpone actions until the game is idle, meaning it is waiting for user (or ai) commands.

For example, a unit named "Joe" kills someone, causing a "last breath" event. In this die event, however, you want to store Joe in a variable, but it's possible (but uncertain) there is also a "die" that (if it exists) should fire before Joe is stored. Or, in case the kill earned Joe enough XP to advance, you don't want to store him until he advances and a subsequent "advance" event is fired. These problems could simply be solved by using a "game idle" child event, something like this:

Code: Select all

[event]
    name=die
    # Some filter...
    # Some WML, like messages or something
    [event]
        name=game idle
        # Store Joe (or whatever else)
    [/event]
[/event]

This could also be useful in an "attacker hits" event, if you wanted to immediately display a message and then wait until the fight is over to do something else... or if there was an action in a certain "turn end" event that you want to make sure fires after any other "turn end" events... or a "moveto" that shouldn't fire until after a potential attack... Sure, some of these things could easily be done differently (like by creating an "attack end" event inside the "attacker hits") but "game idle" would be a reliable, universal way.

[The_Gnat]

This sounds like a good idea. Since it is a fairly unique concept though i am not sure now the developers would add it, but it is possible that a filter could be added that searches through all other events and if any other have criteria to fire, they fire first.

Though i haven't seen [event] tags inside [event] tags before...

It might work to add instead of a new type of event a new criteria in a filter:

Code: Select all

[event]
    name=die
    # Some filter...
    # Some WML, like messages or something
   [fire_event]
          name=SomeEventToBeFired
   [/fire_event]
[/event]
[event]
     name=SomeEventToBeFired

    [filter]
        {NEW_GAME_IDLE_FILTER}
    [/filter]

[/event]

If a NEW_GAME_IDLE_FILTER, like mentioned above, could be added then this would solve the problem without having to change the mainline wesnoth game.

Can something like this be done with lua?

[Pentarctagon]

I'm not sure I'm understanding the problem. Is there a case that isn't solved by setting some sort of flag in "event A" and then checking for it the later "event B"? This doesn't seem like an "idle" event in any case, since it sounds more like you want to conditionally delay when a particular piece of WML is run based on the presence or absence of other related events.

[The_Gnat]

I'm not sure I'm understanding the problem. Is there a case that isn't solved by setting some sort of flag in "event A" and then checking for it the later "event B"? This doesn't seem like an "idle" event in any case, since it sounds more like you want to conditionally delay when a particular piece of WML is run based on the presence or absence of other related events.

What i am saying (and I think what samonelle is saying) is that if you have a event for example:

Last breath event (new event i have created)
- messages

- store unit that killed him

Die Event (always happens in game)
- the unit that killed him gains experience

This will store the unit Before he gains the experience. If there was a idle filter then it would work like this:

Last breath event (new event i have created)
- messages

- fire event A

Fire Event A
- wait until idle

- store unit

Die Event (always happens in game)
- the unit that killed him gains experience

This then will fire the "Fire Event A" only after the Die Event happens because of the idle clause. The idea is good if it can be implemented without too much work, however it is usually not necessary.

Thank you for responding Pentarctagon!

[zookeeper]

Well, it's an interesting idea, although I'm having difficulty thinking of actual usecases. Basically, it would be an event which fires whenever normal gameplay control is returned to a player (or AI) after an attack/move/animation/endturn/etc (and all associated events) has finished? Yeah, maybe that could be useful.

There's a bit of ambiguity to resolve, such as whether the event should fire during or before victory/defeat or not, whether to fire it before or after auto-moves at turn start, before or after healing, etc.

[Samonella]

This sounds like a good idea. Since it is a fairly unique concept though i am not sure now the developers would add it, but it is possible that a filter could be added that searches through all other events and if any other have criteria to fire, they fire first.

Though i haven't seen [event] tags inside [event] tags before...

Nested events definitely work, I do it all the time. For example, nesting "new turn" events is useful if to start a chain of messages that appear one per turn or something. As for a filter, as far as I know filters only control whether the event fires or not, they can't do anything about letting other events fire first. Good idea, though.

Well, it's an interesting idea, although I'm having difficulty thinking of actual usecases.

The idea is good if it can be implemented without too much work, however it is usually not necessary.

Yeah, it obviously isn't too important, since wesnoth has come this far without it. I did want to do this once in my campaign, in a two part scenario. First, you kill an enemy leader, then all your units get put to the recall list and you begin the second part (which was basically just a short cut-scene). But by storing away the unit immediately, no experience was rewarded. An awful shame, since the enemy leader was pretty high-level. I could have given the experience manually, but what if it's enough to advance... I could advance it manually, but what if there are different options... I could probably get around that, but what if that unit had an "advance" event... I really just wanted to let the game do its thing, and pick up control again whenever it finishes. I got around it by using an unfiltered "select" event to do almost the same thing as the proposed "game idle" event, but that leaves a moment of confusion as the player wonders why nothing happened immediately after the kill.

There's a bit of ambiguity to resolve, such as whether the event should fire during or before victory/defeat or not, whether to fire it before or after auto-moves at turn start, before or after healing, etc.

All good questions. I would say definitely before auto-moves, probably after healing. Maybe after victory/defeat events, but before the game actually ends?

[Pentarctagon]

There's a bit of ambiguity to resolve, such as whether the event should fire during or before victory/defeat or not, whether to fire it before or after auto-moves at turn start, before or after healing, etc.

All good questions. I would say definitely before auto-moves, probably after healing. Maybe after victory/defeat events, but before the game actually ends?

I don't know what this would do for the complexity of coding, but those could be attributes used by this event.

[gfgtdf]

The idea is that this event would be a way to postpone actions until the game is idle

This is really nontrivial to implementt specially when making sure that, the game must stay synced in mp, basically there are 2 wqys to implemt it:
1) Add a 'after user action' event that basicall fires at the end of any user action like move/attack/recruit/toggledsu/disacrdrecallunit etc, such an evene would fire also uin the middle of a move+attack actions and after every auto-move so things like

... or a "moveto" that shouldn't fire until after a potential attack...

couldn't be implemented with that.
2) Add a true 'game idle' event, such an event would usually be unsynced since the other player just don't know when a the game is idle on a host, e.g whether a move was a auto move or whether it was part of a move+attack. Dealing with unsynced events is a little harder since people could not change the gamestate directly in it but only via [do_command] (1.13 action tag)

could advance it manually, but what if there are different options... I could probably get around that, but what if that unit had an "advance" event... I

If you unstore the unit with too many expereince with advance,fire_event=yes,yes it will do all the advanement stuff for likre showing the advancement dialog if nessaary, fireing pre/post advance events, or do just nothing if the unit doesnt have enough xp.

[Ravana]

Additional (to select) unsynced event might be nice for interface actions that do not need to be synced.

[Samonella]

could advance it manually, but what if there are different options... I could probably get around that, but what if that unit had an "advance" event... I

If you unstore the unit with too many expereince with advance,fire_event=yes,yes it will do all the advanement stuff for likre showing the advancement dialog if nessaary, fireing pre/post advance events, or do just nothing if the unit doesnt have enough xp.

That sounds much better than using the "select" event, I'll change to that sometime. Thanks!

[gfgtdf]

Additional (to select) unsynced event might be nice for interface actions that do not need to be synced.

Note sure what you mean, is this a suggestion to wesnoth core?

[Ravana]

Yes, better support for interface changes that should only be visible to certain client(either player or observer).

[gfgtdf]

There are already some other events, in particular the theme ui callbacks whihc is alos in 1.12 and the click/mousemove events in 1.13. Both are only accessible from lua though.

[Samonella]

Hey, I'm just bringing this topic up again because I'm more and more frequently wishing it was possible. Most recently I ran into this situation: I have an area that units should be able to move around freely without ending turn, so there is an unfiltered moveto event that refills their moves. However, there are also certain locations that they can interact with an item or something, which takes time, so their moves should not be refilled. I'd like to do something like this:

Code: Select all

[event]
    name=moveto
    id=refill_moves
    first_time_only=no
    < use [modify_unit] or something to refill moves >
[/event]

[event]
    name=moveto
    id=pick_chest_lock
    first_time_only=no
    [filter]
        x,y=<whatever>
    [/filter]
    [message]
        message=_"Try to pick this chest's lock?"
        [option]
            label=_"No"
        [/option]
        [option]
            label=_"Yes"
            [command]
                < among other things, code to set the unit moves to 0 so the player must end turn before moving this unit again >
            [/command]
        [/option]
    [/message]
[/event]

However, since the actual code is fairly complicated and is spread out across multiple files (some from unit_types, some from util files or macros) I can't guarantee which of the two moveto events will fire first. So in some cases pick_chest_lock can't do anything to prevent the moves from refilling.

The only thing I can do right now is make a filter for the refill_moves event, so it doesn't fire on such special locations, but that's a serious pain because there are multiple locations like this one, that sometimes I move around, and even if you do move to those locations sometimes the moves should still refill, and sometimes it depends on user input... You can see how much simpler it would be to just include a "game idle" event inside the "Yes" option, so I can set the moves to zero after the refill_moves event fires.

EDIT: I just thought of a better way to get around this: I'll make a custom event, "post refill moves" or something, that "refill_moves" fires via [fire_event] when it's finished. But a "game idle" event would still be better.

[Ravana]

In refill, filter units that do not have variable set, and in lock set that unit variable.