Beginner questions with controlling lights

[zacaj]

I'm working on a rewrite of Genie for LISY1.  I'm a programmer professionally, although I'm not too familiar with Python, so I'm trying to use the config files mainly.

On games I've programmed manually in the past, the way I tended to program lights was to give the light a condition, such as "l_bonus_33 = player.bonus==3", but in the config docs I'm only seeing options for specifying that a light should be on or off depending on an event and condition. 

So, I could do something like

light_player:

    player_bonus{value==3}:

        l_bonus_3k: on

    player_bonus{value!=3}:

        l_bonus_3k: off

But that seems a bit tedious....

The bottom of the Dynamic Values documentation (http://docs.missionpinball.org/en/latest/config/instructions/dynamic_values.html#using-if-else-logic-with-dynamic-values) implied that I could probably do something like

player_bonus:
    l_bonus_3k: on if current_player.bonus == 3

But when I tried it, I get an error "Invalid RGB string: onifcurrent_player.bonus==3", so it seems like dynamic values aren't allowed here?  or is there some special syntax I'm missing to imply a dynamic value?

Setting lights like this also ties into another question I had with lights.  I was configuring an Extra Ball target, and my first thought was to conditionally award the extra ball based on whether the extra ball w/lit light was on, but I didn't see any easy way to just check if a light was on or not.  All the light documentation is focused on colored LEDs, not simple on/off incandescents :(  Then I realized, this may not be safe in cases where the light needs to carry over between balls (say if "extra ball memory" was enabled), since I can't find anything about how the lights act between balls (do they all turn off?  are they saved between players?  do they just stay however they were for the last player/ball?).  

So I figured I'd add some booleans to the player variables to encode the state of those lamps, alter my light_player: section to turn the lamps on and off based on those variables, and then just turn on the player variable when the target should light instead of directly turning on the lamp.  But the variable_player: section doesn't seem to support booleans at all?  The only options as far as type are int and float, and it's very cumbersome to even just set an int to 1 and 0 since I need to type out "int: 0, action: set" every time.  (is there a shorthand for setting as opposed to adding?)  

Am I on the right track at all here, or is there some functionality I'm missing?  Turning all these into Shots might help here, but I'm not sure how the carryover/memory works for those either, and I didn't really want to bother configuring a ton of shots for such a simple game...

[Anthony van Winkle]

Hey zacaj, and welcome to the group!

To answer your latter questions: yes all of MPF lights work with incandescents, just set the color to "on" or "FFFFFF"; and 1/0 ints are the best "boolean" we have for player variables. 

To answer the light questions: there are lots of different ways that lights can happen, but I'll try to give you some ideas. The light_player is the most hands-on way to do lights, so therefore the most verbose (and occasionally tedious). Shows are good for incorporating light commands in with other commands (slides, sounds, events). Shot profiles are great for defining a progression of lights that can be controlled.

Generally the lighting approach follows the game mechanic that drives it: i.e. is it a counter tracking progress, or a shot lit as a target, or an indicator that some mode/option is activated? I'll toss out a few examples from my game (which are just a few of the options).

Define shows and shot profiles globally

To save yourself some tedium, commonly-used lighting effects can be pre-saved into shows that use "tokens" as variables. For example, I have profiles for flashing alternate colors and a few pulsing patterns. When you play a show that uses tokens, you can pass in token values (like light names, colors, speed) and MPF will map them accordingly. (http://docs.missionpinball.org/en/dev/shows/tokens.html)

To abstract a level more, shot_profiles can hold a series of shows that they progress through (each time the shot is hit and/or manually by events). For example, a shot thats blinking slow, then gets hit to blink faster, then gets hit again and turns solid. Or a shot that starts blinking slowly, and as timer events tick off the blinking increases in speed.

Use shot profiles to bind lights to something you can enable/disable

The most common lighting effects come from shot profiles attached to shots, but these don't just have to be for targets you shoot with the pinball. A shot is an excellent way to control lights because you can enable/disable them with events and they automatically shut off when their parent mode ends and restore themselves when it comes back. For example, I have an outlane ball save that can be awarded and I use a shot "enabled" to light up the lights. And of course, anything that's an actual shot can use a profile (as much as possible, a common show with tokens)

Use common "shows" with keynames for specific events

For my extra ball, I use the show_player to handle the lights. I use two pre-defined shows ("flash" and "on", at least the latter if not both are included with MPF) and use show tokens to specify which light(s) those shows are played on. Because the "flash" and "on" shows are used frequently, I give these particular instances a unique key so I can address them later (to turn them off). It's a bit complex, but should be a familiar concept to a programmer (if you think of the shows as classes and the show_player using tokens as arguments to create an instance).

show_player:

  logicblock_omegarelay_extraball_counter_complete:

    flash:

      key: extraball_lit_show

      show_tokens:

        leds: l_kickback_arrow_amber

  extra_ball_awarded:

    extraball_lit_show:

      action: stop

    on:

      key: extraball_awarded_show

      show_tokens:

        leds: l_ball_save

  player_extra_balls{player_num==current_player.number and value==0}:

    extraball_lit_show:

      action: stop

Use show player with counters/variables to jump states

I've got three lights on a triple-dropbank and each time the bank is completed, another one lights up. Lighting all three starts a mode, and then they reset. This little setup turns off during other modes, so I use a counter to track the progress and tell the show player which step of the show to play on.

show_player:

  mode_field_started:

    sbdrops_show:

      manual_advance: true

      start_step: device.counters.sbdrops_counter.value % 4 + 1

  logicblock_sbdrops_counter_hit:

    sbdrops_show:

      action: advance

shows:

  sbdrops_show:

    - lights:

        l_dropbank_bottom: black

        l_dropbank_middle: black

        l_dropbank_top: black

    - lights:

        l_dropbank_bottom: white

        l_dropbank_middle: black

        l_dropbank_top: black

    - lights:

        l_dropbank_bottom: white

        l_dropbank_middle: white

        l_dropbank_top: black

    - lights:

        l_dropbank_bottom: white

        l_dropbank_middle: white

        l_dropbank_top: white

And there are plenty more approaches and examples for other strategies. My first recommendation is to look into defining some shows and profiles, and see what can't be done (or what's overly cumbersome). Then, we can look into some more complex solutions.

Hope that helps!

[jabdoa]

Hi zacaj,

Welcome to MPF! Anthony probably answered most of your questions. I just want to add two things:

1. You can kind of do what you want with light player. It can subscribe to a placeholder, play a show when it comes true and stop the show when the condition stops evaluating to true. See: http://docs.missionpinball.org/en/latest/examples/light_player/index.html#id2. Please note that this will not work with all placeholders currently (MPF will complain). Let us know where we should add it.

2. In addition to counter there are also state machine devices in MPF. Those can be used to model arbitrary mode logic with custom transitions, shows and events.

Let us know if anything is unclear. We also take Pull Requests if you want to add/improve something to MPF.

Jan

[jabdoa]

http://docs.missionpinball.org/en/dev/events/overview/conditional.html#subscribed-config-players

[zacaj]

Thanks, jabdoa.  The subscribed placeholders were sorta what I was thinking off.  I was able to tie most of my lamps directly to player variables with those, and also use them with a generic 'flashing' show if I want anything to blink instead of just stay on (although it's a bit annoying having to give every single blinking light its own key even if I never reference the show anywhere else).  Is there any documentation around about how exactly the subscribed placeholders know what to do when their condition isn't true?  In my case they seem to turn a lamp off when the condition isn't true and stop a show when its condition isn't true, which is what I want, but I'm not sure how it knows to stop the show instead of any of the other actions...

[jabdoa]

It depends on the config player. Show player just stops the show (exactly the instance which was added when it became active). Similarly, light_player will remove the color entry from the light stack. So in case you want to flash the light when a condition becomes false you can simply add a second entry with the inverted condition.

Jan