ball_device: auto_fire_on_unexpected_ball template support

[bosh]

Draft PR for now - I haven't actually tested whether this evaluates the template live, or just at setup-time.

Unfortunately this is also a breaking change. The property in question was previously a bool, which allows lowercase specification in our yamls ("true"). But changing to template_bool changes the requirement to a python bool, which MUST be either "True" or "False" if specified simply. We could instead make template_bool support either case of boolean, or even more variants (0/1, T/F, t/f, yes/no, etc), but Jan specifically coded this exception in and I hesitate to change this. (Current line) (Original Commit) So if we take this change, anyone who happened to use lowercase in their config there (I did) will crash until they find their ball device setting and capitalize it. Awkward

My use case is that my right outlane has a diverter post to redirect a trough-bound ball directly to the plunger lane instead. I'd like the option, when activating the diverter, to either let the auto-launcher fire as normal (which currently works) OR disable the autolaunching until the eject is confirmed or I manually turn autolaunch back on.

---

I've tried a few different solutions already, and I think managing the auto-launch setting myself has the most future promise right now. Failed solutions were:

• ball hold on the plunger
• new ball device representing the redirection pathway when the diverter makes a save
• ^ but registered to a separate playfield
• ^ but with a ball hold
• ^ with plunger attempting to request a ball (seems like because the plunger can request from trough, and trough has ample extra balls to provide, I can't make the plunger's request come from the fake ball device nor from the playfield, so it always results in an extra ball in play.

My other direction to try now is the fake ball save suggestion from https://missionpinball.org/latest/cookbook/fake_ball_save/ or see how mpf uses the ball_saves:auto_launch to manage this

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[avanwinkle]

Not related to the PR but to your underlying challenge, I feel like blocking the eject attempt with a queue relay player could get you what you need. I've done this in a number of places, and ball ejections include queue events for exactly this purpose.

queue_relay_player:
  balldevice_bd_plunger_ball_eject_attempt:
    post: dont_plunge_that_ball_yet
    wait_for: okay_now_you_can_plunge

You could put this logic in a mode that runs when you want the diversion to happen, or you could put a conditional an the eject_attempt to only conditionally block.

When you want the ball to fire, just post the wait_for event and the eject attempt will proceed. If the player can mechanically plunge the ball, there may be some finesse required to ensure that the ball device knows it doesn't have balls anymore (i.e. mechanical eject succeeded) so it doesn't try and fire on an empty plunger. I've never tried this so I don't know what will happen, maybe it'll need some special logic maybe not.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud