Posting a tip for those running the new code here - make sure your spinners, especially the left ball walker lock one, are TUNED to go to OPEN when they're done spinning!
Some time after I'd put in the new code, a strange condition would begin to appear - I'd launch a ball past the ball lock spinner, it would spin and show the count in the ball in play display, and the ball would land at the top of the walker (properly closing that switch). Then...nothing. I'd wait and wonder when the game was going to drop the ball into the mech and then pop out another ball for play. If I took the ball out of the top of the walker, or rolled it back and then again onto the switch, the gameplay would be destroyed, as the game state around captured/pitted/in-play balls was messed up. The only way to clear it was a reboot, it seemed.
Under more intense scrutiny this holiday season, I decided to really break down the case. I messaged Slochar, and described the condition. He and I agreed the cap at the top switch of the walker, a .05 uf, could stand to be replaced. This had no effect as the issue would come back just as often - in my case, about every six or seven trips up the lane. I decided to look at the spinner itself, since I could not see the code, but assumed that it had to have a routine where it knew the spinner was stopped (to get all the points) before the walker kicked in - how would it know? My guess was that the spinner stopping HAD to stop open, not closed. While the game can and does ignore a closed spinner target switch in play, the walker code needs to be sure of the condition.
Sure enough, the trick to spotting this case is in the ball count display! If your left spinner lands in a closed condition due to tuning/abuse/etc., and it hits the waker top switch and nothing happens - check the ball count display! If it shows spins, vice the ball in play, you can be assured your spinner stopped in a closed state, and the code is waiting for it to open. The spin count is always normally brief, and returns to ball count fairly quickly on either spinner, but if it is stopped, you can address it.
If you want to keep the game playing, and it's not about to multiball, a few gentle spins of the spinner by hand might cause it to land open again, and then walker sequence will proceed. A quick snap of the glass back into place, and you're playing again until you can properly address it. I say not with multiball, because the code is going to empty the walker and you'll be panicking to close the glass and get back into play.
I hate tuning spinners, and I never ever mess with them if they're performing. I just spent days tuning the two bonus X multiplier targets in my Fire!, which have the same switch mech design as spinners - two pieces of copper, one with a spring-like effect that hooks to a line that attaches above to the target. The rest and connection states have to be perfect to keep the mech moving without locking up, or never connecting. When I have to work on them, the playfield is at an angle that is NOT the same as play, so however I tune them, they don't perform with the playfield down - I have to lift and repeat sometimes DOZENS of times to get them to perform flawlessly.
As I told Slochar, I don't consider this a code bug - he did AMAZING work in the very tight memory space he had to work with, and he should not have to tune the routine to fix this case - WE should properly tune our spinners!
Happy New Year to all.