Prevent the auto-plunging of a ball to the playfield from the plunger lane when a physical multiball_lock captures ball?

[bernarma]

I have a multiball lock that when a ball is captured it automatically plunges the ball from the trough -> plunger -> playfield - this plunger has been configured as follows:

ball_devices:
  bd_plunger:
    ball_switches: s_plunger_lane
    eject_coil: c_plunger
    mechanical_eject: true
    ball_missing_timeouts: 10s
    eject_timeouts: 3s
    entrance_count_delay: 600ms # down from 900ms
    player_controlled_eject_event: force_plunger_launch
    ball_search_order: 1
    eject_coil_retry_pulse: 50ms
    retries_before_increasing_pulse: 3
    max_eject_attempts: 6

Is there a way to prevent the automatic plunging of the ball to the playfield and let the player control this using the mechanical action instead?

The area of code I have traced down the function is here - last line does not provide additional parameters to the add_ball function - basically I would like the player_controlled to be set to true:

multiball_lock.py

    def _request_new_balls(self, balls):
        """Request new ball to playfield."""
        balls_added = 0
        for device in self._source_devices:
            balls_to_add = max(min(device.available_balls, balls - balls_added), 0)
            device.eject(balls=balls_to_add, target=self.source_playfield)
            balls_added += balls_to_add

        self.source_playfield.add_ball(balls=max(balls - balls_added, 0))

ball_device.py

    def add_ball(self, balls=1, source_device=None,
                 player_controlled=False) -> bool:

Context: MPF 0.8 (latest from Github)

[avanwinkle]

There are two ways to do this, off the top of my head.

First would be to use a queue_relay_player to block the eject attempt until after the user plunges the ball, at which point MPF may recognize that the ball is missing and if the playfield has already accepted the ball, the eject path may be cancelled. Or, it may try again and you'll have two balls.

Second would be to use the replace_balls: config option set to zero so no balls are replaced in the lock. It'd be up to you to manually trigger an add_ball event to add a ball to the playfield, which should accept the player_controlled argument to require a pluge.

I haven't looked into the code for either approach, but I think the second would be better because it's imperatively instructing MPF to behave the way you want instead of tricking it to.

[bernarma]

Thanks... I'll take a look at the replace_balls way.

I too looked at the relay option but I didn't want a ball search / eject failure to be triggered for a normal action.

[bernarma]

Got option 2 to work... thanks a lot... It's nice and clean. If only I could trigger that without requiring Python code (as it's the only thing I have in the class for that mode), it'd be perfect.

[avanwinkle]

Glad you got it working! It seems like the Playfield class should expose event handlers for it's add_ball() method, something like add_ball_events so that this could be done without custom code. I can think of a few other situations where it might be useful, for example awarding an add-a-ball outside of a multiball.

I see that the BallDevice class does have a request_ball() method which is how it typically gets a ball delivered. Playfields are treated as a type of BallDevice but don't inherit that class, and when they want to add a ball they simply eject one from the source device and wait for it to arrive. So it's probably more of a hassle to try and implement that, just going with the add_ball_events would be simpler (with the caveat that it doesn't affect the game balls_in_play count, but you're already facing that by manually calling the method).