Config file section

Valid in machine config files YES
Valid in mode config files YES
Valid in shows YES


This section can also be used in a show file in the events: section of a step.

You can use the event_player: section of your config files to cause additional events to be automatically posted when a specific event is posted. The event_player can be thought of as a really simple way to implement game logic. (e.g. “When this happens, do this.”)

If you add this section to your machine-wide config file, the entries here will always be active. If you enter it into a mode-specific config file, entries will only be active while that mode is active.

Basic Event Playing

        - cmd_flippers_enable
        - cmd_autofire_coils_enable
        - cmd_drop_targets_reset
        - cmd_flippers_disable
        - cmd_autofire_coils_disable
        - cmd_flippers_disable
        - cmd_autofire_coils_disable
        - cmd_flippers_disable
        - cmd_autofire_coils_disable

The event player settings above will post the events cmd_flippers_enable, cmd_autofire_coils_enable, and cmd_drop_targets_reset when the ball_starting event is posted. Similarly they will post events to disable the flippers and autofire coils when ball end and tilt events are posted.

To use this, simply create an event_player: entry in your config file. Then create sub- entries for each event you want to trigger other events, and add a list of one or more events that should be posted automatically under each trigger event.

Remember that you can create this event_player: section in either your machine-wide or in mode-specific config files. For example, if you want a target called “upper” to reset when a mode called “shoot_here” starts, you could create an entry like this in the shoot here mode’s shoot_here.yaml mode configuration file:


Conditional Event Playing

Events in the event player can be conditional, to allow precise control over when an event is played:


In the above example, both “start_mode_superbonusround” and “play_show_richy_rich” will only be posted if the player’s score is over 10,000 when base mode starts. And if the battle mode is started, either “start_mode_choose_battle” or “start_mode_victory_lap” will be posted depending on whether the ironthrone achievement has been completed.

Conditions can also be applied to events within a list, to allow one event to trigger a variable number of handlers:

      - start_mode_shadowbroker_base
      - start_mode_n7_assignments
      - start_mode_overlordlight{device.achievements.collectorship.state!="complete"}
      - start_mode_arrival{device.achievements.collectorship.state=="complete"}
      - start_mode_shopping{current_player.cash>=1000}

In the above example, both “start_mode_shadowbroker_base” and “start_mode_n7_assignments” will be posted every time. One of either “start_mode_overlord” or “start_mode_arrival” will be posted, depending on whether the player has completed the collectorship achievement. And if the player_var “cash” is high enough, “start_mode_shopping” will also be posted.

In many cases, conditions can be applied to either the triggering event or the handling event. For more information and examples of conditions, see conditional events.

Dynamic Values in Events

There are numerous ways to include dynamic values (player variables, device states, mathematical calculations) in events.

Dynamic Event Names

An event name can use parenthetical values to dynamically determine the event.

    # Player variables can be dropped into event names
    - play_dynamo_show_phase_(current_player.phase_name)
    # Machine and device states can be used
    - dynamo_started_with_state_(device.achievements.dynamo.state)
    # Dynamic evaluations can be done to calculate values
    - player_score_is_("high" if current_player.score > 10000 else "low")

In the above example:

  • With the player variable phase_name having a value of “attackwave”, starting the mode would post the event play_dynamo_show_phase_attackwave
  • If the “dynamo” achievement was completed, starting the mode would post dynamo_started_with_state_completed. If the achievement was instead disabled, the event would be dynamo_started_with_state_disabled
  • If the player’s score is over 10,000 the event player_score_is_high will be posted, otherwise the event player_score_is_low will be posted.

Any dynamic values can be used. Because event names are always strings, all dynamic values will be converted to their string equivalent.

Dynamic Event Arguments

An event post can include arguments to provide event handlers with additional information about the event. An event configured as an object will post the object properties as its arguments:

    # Objects can be expanded for a key/value pair per line
      env_name: driving
    # Objects can be inline for brevity
    set_initial_laps_count: { count: 10 }

You can go a step further and include dynamic values as the values for event arguments. To indicate that an argument’s value is dynamic, use the value: property.

      phase_name: { value: current_player.dynamo_phase }

In the above example, if the player variable dynamo_phase had the value “attackwave”, the event would be posted as such:

Event: ======'set_dynamo_phase'====== Args={'phase_name': 'attackwave', priority': 0}

Because dynamic values can come from a variety of sources, you will need to explicitly define types for the value’s format. Acceptable types are int, float, bool, and string. If no type is configured, the value will be posted as a string.

    # This event arg will be correctly typed
        value: device.counters.dynamo_rounds.value
        type: int
    # This event arg will be converted to a string
        value: device.counters.dynamo_rounds.value