Switch and coil wiring complete!

It's hard to really grasp it from the pictures, but for comparison, here's the relatively empty bottom right corner with a few switches wired from before:
pasted_image (resized).png
And after:
pasted_image (resized).png

This area can still use a bit of cleanup, but I ran out of my little metal strips for wiring support as well as the plastic ones.

Also visible here is my attempt to save some more solenoid drivers: two gottlieb pop bumper driver boards. These are wired up to the slingshots. It seems to work fine, and makes me curious why Gottlieb still used EM style driving for their slings while using driver boards for their pop bumpers. Eagle eyed readers will also note that one of those driver boards says NG on it. Surprise surprise, that board was... not good. Instantly locked on one of my slingshots. Genius. I also figured I could very simply enable/disable these by just hooking their logic ground to one of my driver mosfets, but it turns out that makes them glitch and fire randomly when you turn them on and off, so I reverted to doing what gottlieb did, and cutting the ground signal to the switches.

Some more wiring pics:
pasted_image (resized).pngpasted_image (resized).pngpasted_image (resized).pngpasted_image (resized).png

I was able to mostly follow my sketched wiring from earlier without issue. The one place where it got weird was the mini playfield at the bottom. Since there's no support rail out there, I ended up having to run the solenoid wiring along with the switch wiring around the right flipper to reach it. I'd planned on it going around the lower edge, or between the drops and the flipper mech to leave all the area between and above the flippers open for lights, but there just wasn't roompasted_image (resized).png

Out of 62 switches, I only had three wiring issues to fix on my first switch test pass, which is nice. Very glad I didn't mess up a whole column or anything. There doesn't seem to be any sure fire way to confirm that a matrix doesn't have any issues, but I knocked down lots of drops and hit lots of switches, and didn't get any incorrect readings.

With that out of the way, I was able to get to the most important part: getting something on the playfield to react!

ezgif-4-ad6b4afe4ae9.gif

Now I can start actually coding a few simple rules, and try to play some test games where I imagine different targets are lit and shoot at them to try to get an idea for how my rules to work, and I won't have to stop every 30 seconds to manually reset a bank of targets or eject the ball from a hole

Some of this takes a bit longer than it looks (Some of it actually goes quicker! But I'm trying to focus on specific topics per post, even if I worked on two things in parallel). I probably spent a month or two on the cad at the beginning. In retrospect I should have taken a more 'sketchy' approach to that, if I'd known at the time I'd probably have to redraw it all anyway from the Whitewood before it could possibly be cnced. The playfield was cut last year, then I needed my work space to set up games for a tournament, so the project got put in storage, and I didn't work it at all for a while. Then quarantine happened, and I started working on it again and made great progress with the extra free time I had

All of this is past tense currently... I'm still working through a backlog of pictures to post currently. I'd say I was around post #20 when quarantine started. Flippers working, but no electronics or wiring, and most of the guides+not built yet. I was hesitant to post anything about it before I got everything working enough to say "yes, this all is possible, I can do this"....

Honestly right now I think that's a better approach for casual work. I don't think it's going to be worth using my existing CAD at all for the second draft (that presumably will go to CNC somewhere). I spent way too much time working on that first draft when really all I needed was some basic spacing and layout to work from. On the other hand, I'm sure it'd be great to make a first draft that was already CNCable, if I had easy access to a CNC machine. Then I'd have been more disciplined with the original CAD, and just started iterating directly from there.

Nope, working full time from home now. But I have no commute, no need to make breakfast/lunch before leaving, no need to get into and out of my work clothes, etc. And less need for time in the morning means I can work later into the night, and then sleep in later. It really adds up. Plus, the drive home kills what energy I have left, so I tend to be less productive at home after getting back from work, which is a bummer. And then I'd usually be out doing stuff multiple days a week. Way more free time when there's nowhere to go.

The JS is all interpreted, but technically the interpreter behind the scenes may be compiling it on the fly sometimes. I've run into issues when optimizing the code where, the first time I run some code, it's slow, but then if I run it again it's fast, presumably because the interpreter optimized it after the first time.

Just like my Williams platform, I'm happy to share the board designs and code with anyone that wants it, but it's not 'production ready' per se, and unless I got some interest in it becoming that, I don't really have any plans in making it so...

While getting some basic code running to reset the drop targets and eject the holes, I suddenly lost an entire bank of solenoids. Inspecting the board, I eventually figured out that the board had been repaired so many times as I modded it to test different things that one of the traces carrying the solenoid ground had just gotten ripped off completely. At this point it probably had 4 jumpers on it already, and multiple cut traces, plus some of the mosfets had been replaced three times, so I decided it was time to junk that pcb and build a new one.

One of the main issues that required all those modifications early on was my changing requirements for how the inputs would work. First I'd had them active high, then active low, and then I'd had to change which pin they were. Back when that happened, I redesigned the board to add some more configuration points, so each I/O could have a configurable pull up/down, as well as fix some other pain points. I added LED indicators that the fuses were good, test points for the voltages, and combined my 6/6/4 pin connectors into two 8 pin connectors. A big goal on these boards as I design them further is just making the connector count as small as possible, since they needed to get unplugged so often. I'd actually had the new PCBs on hand for months, but hadn't needed to actually use one yet, so I started assembling:pasted_image (resized).png

Sadly, I discovered an issue with my design early on: at some point I had mirrored some of the components. For the mosfets, that wasn't too bad; just turn them around, but I'd also mirrored one of my 16 pin chips, which resulted in the horrible hack of mounting the chip upside down:pasted_image (resized).pngpasted_image (resized).png
Sigh. I guess another pass at the design will be needed down the line. It'll work for now though, just hard to mount pasted_image (resized).png

Earlier, I went searching for an LCD to put in the middle of the playfield. After a lot of digging, I ordered this 9" screen from AliExpress. Seems to have HDMI support and can be powered with my ATX power supply, but it's hard to tell for sure. There's a ton of different badly documented screens for sale, with conflicting information about what they support or how to drive them. It seems like there's really only two driver boards floating around, one with VGA support and one without, judging by the pictures, but some of the items for sale are clearly wrong about what they're offering. Lots of fun. But for ~$30, I'll take some gambles. Any screens for sale from more reputable US sources seem to be $100+ which is a bit ridiculous. Originally I planned to just buy a monitor and strip off the case, but it's hard to even find a 9" monitor, and the more common 10" won't fit my playfield.

Sadly it's been more than a month since I ordered the screen, and it still hasn't arrived. Tracking last showed it leaving China on 3/30, so not sure if it's gotten lost or just stuck in customs or something forever...

Not a super big deal, I guess, since I don't have any way to really mount it yet.

I'm investigating different options for plastic to cover the hole. Not sure what material is best as far as being pretty sturdy but also thin and scratch resistant. Based on the Voyager homebrew, I'm also wondering about just using a single large sheet of plastic for the playfield as opposed to recessing a smaller cover. I wouldn't have to worry about routing out the recess for the window, or about doing any inserts either, and no need to clearcoat. A lot of other possible issues arise though, so that'll need some more investigation. Once I can find better what material to use, I'll try to order some sheets for experimenting

pasted_image (resized).png

Began work on the habitrail for the ramp, to return the ball to the left inlane. I 3D printed some clips with flat bottoms to make it easy to hold the rails while I align them and work. The plan is eventually to either use some brass and solder it, or try to braze some steel, but for now, I'm using some easy to bend 1/8" copper wire (and cheap, since it's just on spools at Home Depot) to get it right and test things. I'm curious to see if the clips can hold up to soldering/welding, it'd be convenient. pasted_image (resized).png

The actual alignment is a bit iffy; since my ramp model didn't match the actual model that means the habitrail I drew won't line up with the physical ramp either. I tried to eye-ball adjust it to match where it looks like the ramp actually is, but we'll see how well that works.

The actual attachment to the ramp will also be weird. It was designed to connect to a plastic tube that goes across the playfield, and didn't have much flow. Originally I just sorta hand-waved this part as "I'll make something to hold the habitrail, can't be that bad", but now I'm at the part where I need to actually figure out how to connect a ramp whose shape I don't know to the habitrail I haven't built yet.... Here's my first attempt. I'll probably just have to print this a lot of times to get the fit right, assuming the basic shape even works.

pasted_image (resized).png

Code can't get very far without some read-outs. I don't have any lights yet, so for now my 'screen' will have to do. Currently that 'screen' is a 50' HDMI cable running to my livingroom TV, but it'll do.... I spent a long time trying to find a good R-Pi compatible graphics library that would work with Typescript/Node. For some reason, everything seems to have been abandoned 2-3 years ago, and doesn't work with modern Pi operating systems. I'd be fine with even coding the graphics from scratch with a plain OpenGL context, but even a simple library to provide that seemed to be missing.

Eventually, I found a simple library that supported things like basic shapes, images, and text, that was designed specifically for RPi game dev, but had been abandoned partway through development. The author's last update said that they were working on keyboard/mouse support, since without that a game graphics library isn't very useful. Well, it's useful to me! no keyboards here...

Only problem was, it didn't work with the latest RPi OS, since they introduced a new graphics card driver, and it wasn't compatible with Windows (my dev OS). So I dug in, forked it, and made my own version with RPi 3 support, some features and bug fixes, and, with one late night hacking session, a shaky but usable windows port. Not too bad, all things considered. The nice thing about this, vs using an established library (if one had existed), is that if I find any other bugs or shortcomings, I can just easily add whatever I need, since I'm already maintaining my own fork.

With that out of the way, I got some initial status displays set up. Very rough currently; I am not in any way an artist. Hopefully I can work up something half decent for the screen at least, but actually doing some art for the playfield is probably beyond me... More mountains to climb down the road
pasted_image (resized).png

I can add more cards from the drop targetspasted_image (resized).png

No scoring or ball logic hooked up yet though... I also need to figure out what exactly is actually going to happen once you complete a hand. To keep with the 'real poker' goal, technically you should have a final opportunity to bet before your opponent reveals their cards, so I figure you'll need to shoot a shot that can hold the ball to finally flip the cards and declare a winner. In this case, my only ball holds are the upper eject hole, the ramp, and the shooter lane, so I'll have to figure out some logic for that, as well as how exactly you can 'fold' if your hand is looking bad. I'd like it to be something on the playfield, vs some menu interaction, but it has to be something very hard to hit accidentally....

Current lines of code: 4,106

Here's a big case of 'wish I was using MPF'... Testing live on the machine was a pain since it was at the other end of the house from my regular computer. So I wanted to be able to easily test stuff virtually. MPF has a nice application for this. Lets you import a picture of your playfield, then drag and drop switches, lights onto it. Pretty handy, so I recreated it using my new rendering capabilities. Not a ton of work in the end, although mine lacks some polish...pasted_image (resized).png

Squares are switches. Red means closed, yellow/white means open. Left click to toggle open/shut, right click to quickly press the switch and release it again. Diamonds are coils, they turn red when energized. The white circle above the right inlane is a light, currently off, currently wired up as a 'lower ramp w/lit'.
Another in the left outlane will turn green when the mini-playfield is enabled, triggering the down post to let the ball in. Hopefully I can use this to get a slightly better feel for where lights will go.

I also added some code to do stuff like automatically opening the drop target switches when the bank resets, auto closing the shooter lane switch after a ball is released from the trough, etc. Stuff that would happen physically on a real machine. Otherwise it gets to be a pain to use, since the drop target coils would repeatedly fire until you remembered to click each switch again

Got the basic habitrail installed. Made a half height, low quality mount to hold the other end, which seems to work okay. pasted_image (resized).png

ezgif-4-cb271ff4781b.gif

It looks like I can make the curve on the entry mount wider for a smoother feed. This is the original: pasted_image (resized).png

And here's my current iteration:pasted_image (resized).png

Mounting the entry mount was also an issue, since I didn't really plan for that. I ended up putting it on a standoff on top of one of the existing ramp's mounting holes, but I still only have one screw holding it. It seems to work okay, so I'll leave it for now. I could probably extend another support out to the posts behind the 2-bank if necessary, but I don't want to cover the playfield any more than necessary.

I also needed a place to mount the switch, so I stuck a microswitch through a small gap. To prevent airballs, I put holes on the top to screw a sheet of clear plastic into. Still need to figure out how to attach the plastic on the left side of the ramp. I don't understand how Mars never has airball issues on its ramp... seems hard to believe that they managed to make it the exact height needed for their flipper strength, especially since I'm using the same flippers!

This is my final entry design. Looks pretty weird, but it works. :pasted_image (resized).png

I had to add some side rails to keep the ball from falling off, especially at higher speeds. Lock post worked on my first try with a random guess for the pulse length, which surprised me. ezgif-4-eefde8c14d59.gif

While it's nice to know this works, I probably will avoid locking multiple balls this way, since I don't have any way to mount a switch behind it to know if it failed to release a ball due to the ramp positioning. Sadly, this was the only position I could fit the post mech in, so I'm a bit constrained here. I'mthinking I'm going to have most multiballs work by locking one ball on the ramp, and then you get a second ball to plunge, and the ramp ball is released once you hit a switch. Maybe there will also be something to let you short plunge and combo up the ramp to lock a second ball, for three ball, or a rule about locking both balls during MB to release a third. Since there's no auto plunger I can't really have a normal add a ball. I feel like multiballs lately have been a bit boring design wise, so I'm hoping to do more stuff with multiple phases like DE used to do, or maybe more advanced stuff like a special multiball that you can only work towards qualifying while you're already in another multiball, at the cost of ignoring the current multiball's jackpots to make that progress...

For normal ramp shots, I programmed the game to engage the post as soon as the ball makes the ramp, and then disengage once the inlane switch registers, but I had issues with the ball bouncing over the switch since it was just dropping off the end.Inspired by Metroid which I saw at Pintastic last year, I made this end cap for the rail to make the ball drop nicely. pasted_image (resized).png
pasted_image (resized).png

It worked, but I didn't like how it looked, so I made this instead, which seems to work fine and looks more natural:

pasted_image (resized).png

As I tested the game a bit more, I ran into an issue with the ramp. Once it was on for 10 minutes or so, I started to smell the coil cooking. EOS was still working fine, but even on 'low power', it was eventually heating up. So I switch it to use PWM as well. 1ms on, 5ms off. It made a bit of an annoying whine, but it didn't heat up anymore. However, this ran into a new issue. If you flipped both flippers, sometimes the ramp would fall down. My guess was the flippers were momentarily pulling enough of the current that the 1ms 'on' pulse wasn't enough to hold the ramp up anymore. I started running into similar issues with my other PWM coils, such as the up post, down post, and controlled gate.

I then wondered again, why was the ramp heating up? Mars obviously couldn't be making smells like that within 10 minutes of some kid ignoring the game in an arcade. And if this was such an issue with the PWM, then how did other games ever manage to work? I wondered if it was something with my PWM timing, since on other games you never hear the PWM nearly as loudly as you do here, but reading through the MPF source code, and looking at scope readings of some other games confirmed that most of them used a 1ms pulse too.

Eventually, I realized that the issue causing both of these was the capacitor I'd put on the solenoid voltage to make it strong enough to power the bally 50V knock down coils. With that removed, the PWM coils could reliably be left on while flipping, and the ramp coil didn't heat up anymore, even without PWM (or at least, it stays comfortably warm). But I need the capacitor for the drop targets, and also I liked how it made the flippers + outlane saver work. So I had to rewire the power wiring for the playfield. I added a second bridge rectifier to the 24VAC line from the transformer, without a capacitor, and then adjusted the playfield so only the coils where I really need the power get the higher voltage from the capacitor. I'm glad it was a simple enough solution in the end, but was quite a pain

I've spent a good amount of time playing with the upper magnet. It's positioned next to the shooter lane, right orbit, so that it can drop the ball to the upper right flipper.

The magnet had two use cases:
1. for the skillshot, if you plunge the ball up so that it stops next to the magnet, and then the magnet activates, pulling the ball sideways from the shooter lane to then release it to the flipper
2. to feed the upper flipper via left orbit shots. this is the main use case, with the skillshot just being a bonus. I didn't really forsee a problem with this while designing, but I've come to realize that this just isn't how magnets are normally used in machines. Games like Twilight Zone will stop a fast moving ball on an orbit, but they have the magnet directly under the ball's path. The magnet acts only as a ball grabber, not a diverter. Most cases I can find of magnets being used as diverters are things like TWD's crossbow, or WCS's lock. WCS is the closest to my use case, since it specifically grabs a moving ball, stops it, then drops it. But even WCS has issues grabbing a fast moving ball.

I quickly discovered that my original plan of wiring and mounting this magnet the same way the magna save is mounted just won't work. The magna save coil is being powered using 25V, while most newer games use 50V for their magnet. So I hooked up my 50V line to my magnet relay, instead of 25V, and... immediately fried my relay. The 50V is strong enough that, when the relay deactivates and its contacts move apart, the voltage will just arc across the gap and continue powering the magnet while melting the contacts. I had a similar issue with the 5-bank reset coil, and was able to fix it by adding a 10uF, 300V capacitor across the contacts. For some reason this doesn't work on the magnet. I wondered if the magnet was stronger, but the magnet actually has more resistance than the drop target coil. My random relay was only rated for 3A@25V though, so I ordered a really beefy relay, which was rated for 30A (!). I think my magnet should be drawing about 10-12A at 50V, so that should be plenty. But that relay also had constant arcing issues. I tried bigger snubber capacitors, other snubbing solutions, even disassembling the relay and physically bending it so the contacts are farther apart, and nothing helped.

It seems like switching 50V@10A just isn't reliable via a relay somehow, though I don't understand why. Modern games all control their magnets via transistors and mosfets, although I don't know if that is specifically to avoid this issue, or for other reasons. The problem is, I can't use those here, since my 50V has a separate ground from my 25V. My next plan is to get a TIP36C (which is what williams used for their 50V coils in the 90s), and then try to use a relay to switch the gate (instead of having a microcontroller switch it like normal) which feels like horrible overkill, but it may work. Even at that point, I'll still have issues because I can't PWM a relay, so I'll basically be running the magnet at full power. I'm not sure how long I can power the magnet like that, hopefully it's long enough to get the ball settled.

The magna save is also a completely 'below playfield' magnet, with no visible core. Adding a core that goes all the way through the playfield helps make the magnet stronger, and I assume that this is why games like TWD, which need to grab a ball shot at their wide bash toys, use an even bigger exposed magnet core. At first I figured I should just order one of those larger exposed cores, but they're incredibly expensive somehow (the large core costs more than the magnet itself!). Even a regular size core is expensive. I don't really want to spend that much money on something that may not even be useful, so for now I've just bought some 3/4" steel roundstock that I'll use to test the smaller exposed core. I can't find any info on how much stronger this make the magnet.

All this is still up in the air, too, as I don't know if the magnet will be able to grab the ball properly even with a large core and 50V, given the crazy speed my left orbit shot has. I've spent a lot of time trying just to get the 50V to work, and still haven't been able to even do a single test yet to see if the 50V can grab the ball since it keeps melting stuff

I'm also trying to consider other approaches, such as replacing the magnet with a physical diverter, but currently I can't find any good way to fit one in with my current constraints, and I would still need a magnet or an up post to hold the ball for a reliable side flipper shot after the diverter gets the ball to the flipper...

I may also try putting an up post in the shooter lane, specifically to stop the ball as it comes down the lane from the left orbit, and then using the magnet to pull the stopped ball over the flipper. I am running low on drivers for the coils though, so I want to avoid adding in more coils if possible...

Coded the basic structure of the skillshot. I'm pretty dissatisfied with most skillshots in games currently. Most seem to either be 'just plunge the lit lane', or plunge to a flipper and hit a lit shot. You don't really care about your plunge at all. Some games like Deadpool make it a bit more interesting by locking in your lane choice. Most games that actually require you to plunge to a specific spot (such as Taxi) just make you learn one or two plunger positions, which I think can get boring once you've learned them, since at that point you're just slowing down your game to squint at the plunger. My goal here is to have a lot of different places to plunge to, and have the context of the game make you change which one you're plunging to frequently.

There are seven different places to plunge to:pasted_image (resized).png

Red: plunge just far enough to clear the diverter. Diverter will close, leading ball to right inlane
Orange: plunge so that the ball hits the lower magnet switch, without hitting upper magnet switch. Magnet activates, pulling ball to the left and feeding upper right flipper (well, hopefully, if I ever get it working)
Yellow: if you plunge past the magnet and hit the upper magnet switch, you'll fall back down and feed the right inlane, similar to the red skillshot
Green: The lower 3 lanes. Not sure what will happen with each lane yet, maybe one will be lit as an extra target
Blue: Upper 3 lanes, same as green
Pink: plunge and fall into the upper eject which will then feed the upper left flipper. Really hard to do, worth the most
Purple: Hard plunge all the way around and feed the left inlane

The Pink and Purple skillshots are made harder since there's a one way gate to the left of the lanes, blocking them. Currently I have it timed so it's open for 2 seconds, then closed for 2, so you'll get redirected to the lanes or let through based on your timing.

Your current 'bet' amount is determined by where you plunge, so you can choose to bet a little or a lot while still keeping it 'pinball'. I'm thinking the bet amounts will be percentages of your total 'bank', so you'll be forced to bet more later in the game. You can return to the shooter lane at any point while playing your poker hand by shooting under the upper right flipper, so you can adjust your bet if your hand is looking better or worse.

In addition, there will be an award on each skillshot, that you can only get if you 'call' your shot by selecting that award with the flipper buttons. Currently it's just points, but I want to eventually put other stuff in there to mix stuff up. If it's only ever points, they'll either just be ignored, or they'll be so big they're unbalanced, so I like to put 'in game' effects into stuff wherever possible. But that will have to wait until I have more game coded to affect.

The graphics themselves on the screen are pretty basic right now, but serviceable. I kinda dread getting to the point where I actually need to make this stuff look nice somehow. Even for a simple screen like this, I think more code is dedicated to drawing and updating the screen than there is to the actual skillshot logic... It must have been nice in the DMD or alphanumeric games where you could often just slap some text up and be done with it

pasted_image (resized).png

I don't actually know how to play Texas Holdem

Also, there's no guarantee the plunge at the beginning of a ball will be the start of a hand, which I think is when the blinds come into play?

Interesting, I always assumed those ramps were just held up by the drop targets.

I've heard a similar single coil mech is used for the diverter in mousin around, which surprised me. I've never heard of that sort of thing being used before, but when I first got into pinball I assumed most mechs would work that way

It seems like williams always used the latching ramp style mech. I'm familiar with the design from my Whirlwind and Black Rose. Sadly this gottlieb mech isn't like that. I think it's workable as is, with some careful management, but it's just really surprising to me that it's running so close to the edges of its operating window during normal use...

It must not have been a major problem, since it appears the same mech was used even on some of their last games like Street Fighter 2.

Coded some initial spinner rules. First time you shoot the spinner, it stops it in the upper lanes. Next time it orbits around back to the left flipper for a 2x spinner shot, and stops it in the lanes. Then you get two orbits before it stops it, etc.

Coding this was way harder than that sounds, due to me not really thinking about 'shots' and such when I designed the playfield. A ball shot through the spinner could go in one of six lanes. Or it could fall back through the spinner. Or fall down the shooter lane. Or it could manage, theoretically, to go below the left one way gate and continue on to the left. When the gate is open, it will usually go all the way around, triggering the left orbit switch and the left inlane on its way down. But it could also fall short into the upper eject, or go under the ramp, or fall even shorter into any of the lanes, etc from before.

Originally I figured I didn't need to care about this too much. I'd just consider a shot to the spinner as whenever the spinner suddenly spun a few times. But when I'm purposely designing the code to let you repeatedly rip the spinner, it's very likely the spinner will still be spinning somewhat by the time you rip it again, or you could even go right under it while it's spinning, so I ended up with a ton of code for different edge cases trying to detect when the player does a successful orbit or not, multiple timers going on, etc. It's a bit of a mess, and it's going to be even more of a pain to debug if something goes wrong.

It would have been really nice to close up some of the areas a bit more so I could know 'for sure' whether a ball passed through there, rather than having a big open area up there for the ball to bounce around in. Too bad big areas for the ball to bounce around in are fun...

Scoring wise, I'm trying to sorta take a page from Meteor, since I like the way its spinner value is continually fluctuating. For the first iteration of that, my attempt is to make the spinner score more when you having matching numbers of drop targets down on each bank. For instance, the spinner starts at 10 points. You knock down one target on bank A, that goes up a bit. You knock down one target on bank B as well, that number goes up even more. Two targets down on each bank is better than one, etc. I'll try to balance it so you can get the spinner up really high, but at the same time if you hit one stray target it may ruin it completely.

Hopefully this will also encourage people to 'shoot around' more, instead of finding one or two banks they feel safer on and just picking targets off those

I can't think of any place to position it... The spinner (red) is placed a bit weirdly, at the end of the right side wall and the beginning of the left side wall. I considered adding a wide roll-under switch (blue) going from the spinner's guide wall to the right side wall, which could then serve as both a 'spinner shot' switch and as the magnet rollover switch in the shooter lane, but I can't come up with any way to actually attach the roll-under wireform to a switch, given its positioning.

When first starting on this project, I was really hoping to be able to use eddy sensors instead of rollovers, which could avoid many of these problems and also make the playfield construction much easier. Someone on here a few years ago was planning on reproducing the ones used on Alien and Full Throttle, and said that their repros would would with any normal switch matrix, but they haven't ever materialized

pasted_image (resized).png

Would those Reed switches work through a playfield though? Half an inch of wood vs a thin piece of plastic...

Got a sheet of 1/16" lexan to experiment with. Going to make a test cut the size of the screen, and mount the lexan over it using the same post locations the real playfield will have, see how it flexes over the hole. if the flex from a ball is low enough, I may just cover the whole playfield with the sheet. Only other issue with that is the star rollovers... Will have to play around with that too

Screen is still stuck in shipping, so I'm investigating other sources

Coded the logic for actually determining which hand won, and displaying the best 'hand' from each hand of 7 cards. The code for finding pairs, straights, etc was surprisingly simple and fun to write.

pasted_image (resized).png

Since it can identify what hands you got, I can now tie that into what modes/multiballs are enabled at that point. Unsure what I should do if you manage to get multiple different hands.

For instance, what if you manage to get three pairs? Technically only your better two pairs will count as far as the poker game goes, but if each pair qualifies a mode, should you have the choice of which one(s) to play? Should only the higher two pairs' modes be lit, effectively making lower cards' modes harder to get?

If you get a straight and a pair, and then you play the mode you get from the pair, does the multiball you got from the straight go away, or could you go play it after finishing the mode?

If you qualify a mode, but then immediately go into the shooter lane to start another round of poker, should you lose that mode, or should it still be available? Should you be able to start a mode mid-way through a hand?

So many questions... Luckily the decisions on these aren't really hard to change the code for, they could even be settings technically, although I'm not going to bother coding any settings menu or anything since I can just edit the code I'll probably go with the most restrictive options for now (if you take a mode you lose your multiball, etc) just so I don't have to deal with coding a mode select screen yet.

Displaying the final hands also leads into my next 'fun' structural/code problem. For instance, say you collect your last card, but you haven't 'flipped' the opponents card (is there a poker term for this) to see who won. Technically at that point, I can now light the ramp and eject hole if you've qualified a mode or multiball. When you shoot the ramp, the 'ramp switch closed' event tells the code to display the cards and who won, and then the multiball needs to start, probably with its own intro animation eventually, releasing the new ball, possibly displaying the skillshot again. At this point, I have two modes (the poker hand finishing up its display and the multiball that's starting) that are both running at once. Unlike in other instances where one mode just overrides another, here they need to coordinate at some level.

I could just handle this manually by having the poker mode directly start other mode once it's done, but I worry that will get messy as I get farther in. I'd like to have some more generic system where a display effect (like showing the final poker hands) can delay the starting of the next mode somehow, but that might also get messy, knowing exactly what bits of code need to be delayed and what don't. Will require more planning...

Nope, no stacking like that. I dislike games where you can just stack everything together. My current thought is that if you get two pair, that will be two modes stacked, although that might end up resulting too much mode stacking. I'd like the stacking to be fairly rare. Also, if you get a full house, then you'll get a multiball where you stack two modes (the three of a kind and the pair). But in general I want most of the game modes/multiballs to be their own dedicated thing to concentrate on and try to play well, and to make each of them in depth enough that that can be fun and varied by itself. Plus, there will usually still be other stuff going on, like the spinner rules, and other 'side' scoring systems that aren't on the level of a full blown mode

See, to me, having one mode on each shot, not overlapping, means that effectively every shot is now worth points, and thus there's no reason to care about what shot you're shooting. In effect, having all the shots lit is the same as having none of the shots lit, from a play perspective, which isn't very fun. The fun thing about stacking modes to me is when you can align things so one shot gives you credit in both modes. Thus you'd want to try to get two pairs, specifically two pairs that you know the mode shots overlap well, for an optimum stack. Meanwhile, especially if they are timed modes or have other failure states, stacking the wrong two modes could mean you don't finish either of them, or maybe you get worse value, depending on how they interact. Hopefully there will be some good stacks, some bad stacks, some modes you want to play on their own, to influence what cards you're going for, and make you try to balance winning the hand with getting good modes out of it.