With a background as a software engineer (and the precision and rigidity that comes with that), I’m mainly concerned about the “vagueness” and “wishy-washy-ness” of the rules in some places. I’ve followed numerous discussions here about rule interpretation, what do to in situation X, Y, and Z, etc. What worries me is that some rules (and rulings) are essentially arbitrary. Not because the rules are bad per se, but because various pinball machines keep throwing spanners in the works.
Machines keep changing all the time because manufacturers come up with new and creative way to make a game more interesting, and machines keep coming up with new and creative ways to make a mockery of the rules because they add new failure modes or exceptions that never existed before.
I am wondering whether it would not be all-round simpler to accept that a machine is as it is. In the sense that, unless there is something clearly wrong, such as a switch registering when it shouldn’t, or a switch not registering when it should, what the machine does is what counts.
It certainly would make a lot of rulings a lot simpler. “The machine did X, all switches were working, play it as it lies.”
It seems that some of the rules try to impose a sense of “fairness” that, in reality, does not exist. Trapping up behind the barrier on AFM is OK because some clever programmer thought that Dirty Pool was a good joke. But trapping up behind the barrier on Spiderman is not OK, because some other programmer didn’t think of the same joke. Really?
Immediately is as soon as you notice it. You dealing with it by “keep flipping at the other balls in play” is not appropriate. The stuck ball rules should be followed, and it’s quite clear:
“If a ball becomes stuck during a multiball mode, the player should attempt to trap the other ball(s) in play and request assistance.”
Keep flipping is about the opposite rule from attempting to trap the other ball(s) in play and requesting assistance.
I’ve had to deal with stuck balls in multiball quite a bit. Stern’s Star Trek it seems to happen all the time with a ball being stuck on the top of the jet bumper. At IFPA12 Jorian trapped 3 balls on his flippers, called us over to make a ruling on the stuck ball in question on the jet bumper.
What happened next was WRONG, and actually led to the verbiage that Ian posted explicitly calling out what to do in that situation.
Jorian didn’t want to free the stuck ball by opening the game because he would lose control of the other 3 balls he had trapped (coin door ball saver has turned on, so interlock was not disabled). He asked if he could shoot an orbit to free the stuck ball himself. We said that was “fine” (it is no longer “fine” per the IFPAPA rules).
I believe the FSPA rules tend to trend more to this area, so there’s a foundation of rules that do follow this method.
With these rules I would hate for a player to be on Frontier, down 100K, but with 220K in bonus built up. They find themselves with a stuck ball on an inlane/outlane divider, and really just want the ball to drain so they can win the tournament.
The TD comes over and says . . . “There doesn’t seem to be any switch problems with the machine, so what the machine does is what counts”. Player is left to tilt his ball in order to drain, or leave the ball to sit forever and refuse to take action on the stuck ball. TD then DQ’s the player for delay of game and they lose either way.
Yes, this is really in the rules. It’s super easy to understand because we explicitly call it out with the official verbiage. This ruling is far easier to make than rulings where the verbiage may not explicitly cover the situation in question.
PS: I mentioned Keith only because he is the only player I know of who can trap four balls on the left flipper while proceeding to continuously score 1.7 billion per shot with the remaining ball on the right flipper…
Now we really have problem. Giant ball pile-up on the flippers, while the thirteenth ball gets stuck on on a roll-over lane switch and keeps scoring indefinitely.
This reminds me of that not-so hypothetical at a recent (major?) tournament with Doodle Bug, where the ball was perched on the base of the right flipper. (I think Cryss was playing at the time.) The ruling was “play on”. The commentators pretty much asked “What should the ruling be in that case if the doodle bug was doodling at the time?”
FWIW, this happened last night to my opponent in a three-strikes match. I considered it stuck, or at least in a “you need to free the ball” situation, but I wasn’t 100% certain of the rule’s fine print and the TD was playing another game at the time, so I let it slide [it’s a mildly casual event]. I mentioned it to the other player afterwards. [I won the game anyway.] He disagreed with my assessment and had considered it live. I figured I’d confirm what I thought about it here, if true, for future reference.
We were ready for this and watching (at Pinburgh 2016): the answer is the intentional delay clause, which requires the player to take an action within 30 seconds.
However, one of the examples in the IFPA rules for Delay specifically mentions holding the ball on a flipper, which I presume would be the normal way to time out a mode. In other words, sitting there with a ball held on a flipper is by rules definition “Intentional Delay.”
EDIT: FWIW I agree with you, I think it’s a big dodgy. I had actually thought about the Doodle Bug situation before, and my understanding is that a ball touching a flipper is never stuck, so infinite points
"Intentional delay is defined as time when the player is intentionally making no progress towards in-game objectives, including but not limited to time during which the ball is left in the plunger lane, held on a flipper, or passed from one flipper to another. "
My understanding has always been that if a mode timer is progressing, then you are making progress towards in-game objectives, and as such you are not “delaying” for the purposes of the rule.
Well, I side with @jdelz on this then, since scoring points is the ultimate in-game objective. Doodle Bug is kind of a one-off though, so maybe it’s best handled with a specific exception.
