Please document how to specify event posting delays

[PinGizmos]

From looking at some of the sample configs, it looks like there is a way to specify a delay in posting events in the event_player.
For example:

event_player:
  some_posted_event:
    event_to_be_posted|100ms

Is this "piping" of a delay time officially supported? If so, can you please add it to the docs?

Thanks

[flamtime]

Researching this for you.

[jabdoa2]

I think this works only in a few places:

• Specifically in event_player. This is logic inside the player.
• This is also implemented device_control_events (https://docs.missionpinball.org/en/dev/config/instructions/device_control_events.html). You can find out in the config reference if something is a device_control_event type. Most xxx_events properties are.

Maybe more places but I don't recall any. I totally agree that the documentation could be better here and this also confused me in the past.

[founfabug]

Just mentioning that this doco could also reference the delay available in actioning events in some devices, such as reset_events:

[gbouthenot]

warning, those delays (the ones like reset_events) create a python delay. If the object disappears before the delay, MPF will crash ! Example: when you enter service mode, all modes are ended, even if they are some delays pending, and since the mode no longer exists, when the delay trigger, it will reference a object that does not exist anymore -> crash !
I recommend to NOT use this syntax !

The sound_player: "delay" also have the bad behaviour to trigger if the mode is ended.

I recommend using only this syntax:

event_player:
  the_event: trigger_this_event|delay

or:

event_player:
  the_event:
    - trigger_this_event1|delay1
    - trigger_this_event2|delay2

This delays won't trigger if the mode is ended.

[bosh]

@gbouthenot do you have any stacktraces (and MPF log lines of the triggering event if possible) for this crash? If you post the trace and the device event config for an example, I'd be interested in looking into a fix.