So-- to talk this out a little bit before i move forward.
Optical Support is going to be tricky, because there are different ways to implement, the two primary ways being:
Ball drain optical switch in the RailIn this setup, the optical switch is put where the ball drain switch is in a normal skeeball machine. In this setup, every ball will hit the ball drain. So when you score a pocket we'll have to add a "score increment" to a variable, and every time a ball hits the drain if the score increment is >0, we'll have to decrement it. If "scoreincrement" is 0, it means we count it as a gutterball, no score, or whatever that means.
This is NOT the ideal setup becuase we will be unable to tell the timing of when the zero score happened (this may matter for some games).
Scenario:- - Throw 3 balls rapid fire
- ball 1 could go through the scoring hole (say 50), starts rolling down chute sets scoreincrement =1
- ball 2 misses all pockets and ends up in the drain, subtract 1 from scoreincrement, scoreincrement = 0
- ball 3 hits a scoring hole, (say 50) adds one to scoreincrement (scoreincrement =1)
- ball 1 comes through the ball drain, and sets scoreincrement = 0
- ball 3 comes through the ball drain, scoreincrement is 0, recording a gutterball.
Why is this bad?If we were playing bowling, the "gutterball" was recorded as the 3rd ball when it was actually the 2nd, so you end up with a strike in this frame instead of what you should have gotten, a 5 in this frame (5 -) , and a 5 as the first ball of the next frame.
The timing is off here. This might matter in a game like bowling, where the order of the gutterball matters.
Optical Switch spanning the scoring box on the bottom for "gutters".This woudl be ideal, because we can disregard a ball once it's recorded, and we'll know when a ball misses the scoring holes entirely. I'm worried this might be susceptible to "bounce" if the ball bounces or something causing it to record multiple gutters.
------------------------------
Current physical switch implementationAs it stands right now for physical swiches, we're always "Waiting for ball" once a ball hits a scoring pocket, because when it ball hits one of the higher pockets (say 50), it hits ths switches for 50,40,30,20,10 and ball drain. so we have to "turn off" the lower switches until the ball drains out. This is annoying as it prevents fast-throw and speed type games, because you very often don't end up getting scored the 2nd time, or you might even end up with a lower score depending on the timing of the ball drain switch
Scenario:- Ball 1 is thrown
- Ball 2 is immediately thrown after
- Ball 1 sinks in 50 and is scored fifty becuase waitingforball = false, and heads down the chute, sets waitingforball = true
- Ball 2 hits the 100 is not scored, because waitingforball = true and starts rolling down the chute
- Ball 1 hits the ball drain, sets waitingforball =false
- ball 2 continues down the chute and is down by the 30 switch, hits 30. waitingforball=false, so score 30. set waitingforball=true
- Ball 2 finally hits the ball drain sets waitingforball = false
You just got screwed out of scoring the 100 pocket.
Even in the worst optical case is 100x better than the physical switch case.
---------------------
So I'm definitely implementing optical and migrating my machine over to optical switches.. for sure.
So for optical options I have to implement 2 modes:
- Optical with Ball Drain
- Optical with Gutter detection
I'm worried about the 2nd optical option and the potential for recording multiple gutters due to a bounce, so I might just live with the ball drain option and tell people to not expect great results if you play these games like an ---uvula--- and throw 3 balls rapidfire in a game where that matters.... it won't in most games to be honest.
make sense? Comments? Insight?