Queue event player makes MPF crash if no events_when_finished defined.

37 views
Skip to first unread message

Marc Rechté

unread,
Aug 30, 2025, 9:42:57 AM (8 days ago) Aug 30
to MPF Users
The following config makes MPF to crash when do_skillshot_yellow is received.

queue_event_player:
  do_skillshot_yellow:
    queue_event: do_skillshot_yellow_queue


15:12:11.393 : INFO [EventManager] Event: ======'do_skillshot_yellow'====== Args={}

15:12:11.394 : ERROR [asyncio] Exception in callback EventManager.process_event_queue()
handle: <Handle EventManager.process_event_queue()>
Traceback (most recent call last):
  File "/home/mrechte/Marc/Electronique/ARM/bronco/mpf/mpf/core/events.py", line 755, in _run_handlers
    result = handler.callback(**merged_kwargs)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/mrechte/Marc/Electronique/ARM/bronco/mpf/mpf/core/config_player.py", line 348, in config_play_callback
    return self.play(settings=settings, context=context, calling_context=calling_context, priority=priority,
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/mrechte/Marc/Electronique/ARM/bronco/mpf/mpf/config_players/queue_event_player.py", line 29, in play
    self.machine.events.post_queue(settings['queue_event'],
TypeError: EventManager.post_queue() missing 1 required positional argument: 'callback'

However if I change it as below it no longer crashes.

queue_event_player:
  do_skillshot_yellow:
    queue_event: do_skillshot_yellow_queue
    events_when_finished: dummy


Alex L

unread,
Aug 31, 2025, 5:59:29 PM (7 days ago) Aug 31
to MPF Users

This provides a default events_when_complete, generically named "queue_event_complete", with the additional parameter of "queue_event"=the name of your queue event (eg. do_skillshot_yellow_queue)

Anthony van Winkle

unread,
Aug 31, 2025, 9:17:35 PM (6 days ago) Aug 31
to MPF Users
This is expected behavior, because of how queue events work.

A standard event player in MPF will post all of its handlers when the triggering event is called, processing each handler according to its priority but also in parallel. Once the handlers have been called the event is done.

A queue event player still processes each handler according to priority, but they are queued up so the first one goes, and the second one waits for the first one to finish before it starts. That wait could be a few lines, a few cycles, or indefinitely (e.g. waiting for a player to push a button). Only after the first handler says "I'm finished" will the second handler be processed. How does a handler say it's finished? By posting the events_when_finished event(s).

If a queue event player has a handler with no finished event, the rest of the queue will never be processed and the game will potentially/eventually hang. If multiple queue event players have the same finished event, it could get real wonky because some handlers might jump the queue and be processed out of order or too early. That's why there's no default value.

It's perhaps an oversight that events_when_finished is not a required property in the config spec. That code is unchanged in almost a decade, from its first release, and very few people use queue events and those that do would always need to include events_when_finished.

So my question is: why is it that you need to use a queue event player instead of a regular event player, if you're not needing the events_when_finished event to know your callback is complete?

Reply all
Reply to author
Forward
0 new messages