(Topic ID: 266636)

Pinball Poker? Poker Time? Undecided poker themed homebrew...


By zacaj

5 months ago



Topic Stats

  • 142 posts
  • 24 Pinsiders participating
  • Latest reply 9 hours ago by zacaj
  • Topic is favorited by 25 Pinsiders

You

Linked Games

No games have been linked to this topic.

    Topic Gallery

    There have been 205 images uploaded to this topic. (View topic image gallery).

    ezgif-3-fc38e1c6edf9.gif
    ezgif-3-d76c5cac3a21.gif
    pasted_image (resized).png
    ezgif-3-efb04764c225.gif
    pasted_image (resized).png
    pasted_image (resized).png
    pasted_image (resized).png
    pasted_image (resized).png
    pasted_image (resized).png
    pasted_image (resized).png
    pasted_image (resized).png
    pasted_image (resized).png
    pasted_image (resized).png
    pasted_image (resized).png
    pasted_image (resized).png
    pasted_image (resized).png

    There are 142 posts in this topic. You are on page 2 of 3.
    #51 4 months ago

    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

    #52 4 months ago

    It’s crazy how fast you have put things together the last couple weeks, very impressed!

    #53 4 months ago
    Quoted from Mbecker:

    It’s crazy how fast you have put things together the last couple weeks, very impressed!

    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

    #54 4 months ago

    Yeah but didn’t you catch up to real time about 14 days ago, so everything after that was happening ‘now’.. when you attached the cad print and started cutting holes in the pf?

    I took the opposite approach and built a white wood first and am now having to go back and CAD and wishing I had done that more in the beginning, even if it meant altering a lot of things.

    Are you off work for this time? I am grateful for a job but man I could a used 4 weeks to build pinball lol

    #55 4 months ago
    Quoted from Mbecker:

    Yeah but didn’t you catch up to real time about 14 days ago, so everything after that was happening ‘now’.. when you attached the cad print and started cutting holes in the pf?

    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"....

    Quoted from Mbecker:

    I took the opposite approach and built a white wood first and am now having to go back and CAD and wishing I had done that more in the beginning, even if it meant altering a lot of things.

    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.

    Quoted from Mbecker:

    Are you off work for this time? I am grateful for a job but man I could a used 4 weeks to build pinball lol

    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.

    #56 4 months ago

    Very impressive that you're not just homebrewing the pin, but also rolling your own hardware platform. It sounds really cool with the high level JavaScript-type language. Is that variant one that gets compiled or is it interpreted? After working with your Williams platform, I can't help wondering if you might release the platform your developing here too for other homebrewers. I'm not a big fan of the pricey options that are out there either.

    #57 4 months ago
    Quoted from HighVoltage:

    Very impressive that you're not just homebrewing the pin, but also rolling your own hardware platform. It sounds really cool with the high level JavaScript-type language. Is that variant one that gets compiled or is it interpreted? After working with your Williams platform, I can't help wondering if you might release the platform your developing here too for other homebrewers. I'm not a big fan of the pricey options that are out there either.

    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...

    #58 4 months ago
    Quoted from zacaj:

    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.

    Well Excellent work thus far, and I concur with high voltage on the board work- very cool to see! This is one of my top 3 threads, love the updates! Hope to see it thru to the finish

    #59 4 months ago
    Quoted from zacaj:

    To keep things clean, I'd like to stripe the wires, so I can tell the rows and columns apart when working. Sadly I couldn't find any cheap sources of stranded wire online, so I came up with this:
    [quoted image]
    Tried it first with a regular sharpie, but the ink would rub off quickly, so I got some oil based ones, which seem to stay on the wire well once they dry. Stick a marker in the top, pull your wire through the side, and you'll get a messy but usable stripe.

    Quoted from tjw998:

    You should consider posting this in the "Show and Tell" thread about homemade tools - https://pinside.com/pinball/forum/topic/show-and-tell-your-diy-homemade-tools
    I think a lot of people there would find this interesting. I certainly never thought of this.

    I remember wallybgood did this before for his MM build:

    Quoted from wallybgood:

    The wiring harnesses would also be more difficult without a sample... There were six major harnesses to build... My son came up with a simple tool to stripe (color code) wires. Exposed wiring for the ramps was purchased from BAA.

    Quoted from wallybgood:

    This is what I used to stripe wires for the MM that I built. Worked out OK. (rubber band keeps a little pressure on pen) Use fresh pens and let the wires dry for a few days before using.
    Wally

    Great minds think alike!

    Fantastic job so far, Zach. This machine is feeling like a totally wacky late 80s Gottlieb being completely PACKED which wacky custom mechs and unique gamplay features. I honestly love it!! The novel "Lets just add more" thing Gottlieb was doing was just awesome. Stern is all about keeping costs down but Gottlieb wasn't afraid to make a fun and quirky machine even if the idea was totally impractical!

    The excessive saves and mini below-trough playfield is ridiculous. The throwback Bally reverse-inlane is a beautiful choice. A lot of underrated Bally 6803s had reverse inlanes, like my City Slicker, and they are a TON of fun.

    Love the flow and love the huge amount of drop targets in this game. The left orbit return is insanely fast!
    If I can help in anyway, let me know! Good luck, I wanna play this things ASAP!

    #60 4 months ago

    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

    #61 4 months ago

    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
    #62 4 months ago

    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
    #63 4 months ago

    This is incredible, and I don't understand most of the electronics side of it, but I am in awe of your ingenuity and talents!

    Following this as it has some of the most innovative ideas I've seen in a long time!

    Chris

    #64 4 months ago

    Those clips work just ok for brazing .. if your just soldering though probably no issues.. I brazed bronze and it justbif melted 3D printed clips like that so I switched to wood blocks with holes I slid the wire thru to keep spacing

    #65 4 months ago

    I hope you're better with Java than the idiots that coded the ENTERPRISE LEVEL software I have to deal with on a daily basis. Shoddy trash full of memory leaks!

    This thread has more innovation on it than the entire time Jpop spent messing around with Zidware...unreal. That outlane upkicker is totally batshit insane, and I love it.

    #66 4 months ago
    Quoted from Frax:

    This thread has more innovation on it than the entire time Jpop spent messing around with Zidware...unreal. That outlane upkicker is totally batshit insane, and I love it.

    It is, isn't it? It's one of those zany never-done-before ideas you can make pretty much with off-the-shelf mechs that I wish I'd thought of. It's a great example of how 'innovative' doesn't have to mean 'overthought'.

    #67 4 months ago

    I LOVE your ball saver idea, it's unique and very satisfying to see!
    Great ideas and keep them coming!

    #68 4 months ago

    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

    #69 4 months ago

    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

    #70 4 months ago
    Quoted from zacaj:

    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...[quoted image]
    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

    You can also implement the BCP protocol and use the MPF monitor if you want. It does not require any MPF config except a bare machine folder with a playfield image in it.

    #71 4 months ago

    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

    #72 4 months ago

    nice progress.

    #73 4 months ago

    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

    #74 4 months ago

    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...

    #75 4 months ago

    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
    #76 4 months ago
    Quoted from zacaj:

    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.

    Ball 1 - no blind
    Ball 2 - small blind
    Ball 3 - big blind

    #77 4 months ago
    Quoted from Frax:

    Ball 1 - no blind
    Ball 2 - small blind
    Ball 3 - big blind

    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?

    #78 4 months ago
    Quoted from zacaj:

    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?

    True, I was just joking around, though. Blinds are basically just guarantees that there's a bet on the table, and that the stakes are being raised periodically to make sure people get eliminated. Thus, your comment about being forced to bet more on later balls/plunges reminded me of the blinds. I know it's not intuitive, and sometimes doesn't make sense in the context of playing a hand, but really, if we look at things like WPT, there's plenty of things in there that aren't really applicable "when they happen" such as "ace in the hole", so I don't necessarily think that would be a negative for me, personally.

    #79 4 months ago

    For your ramp lifter, maybe look at the mech used on devil riders for the drop ramps. Works like a clicky pen, just a short coil pulse to raise the ramp and latch, or pulse again to drop it. Doesn’t require a constantly activated coil. Very slick design that confused me for a while since it’s such a different approach.

    #80 4 months ago
    Quoted from HHaase:

    For your ramp lifter, maybe look at the mech used on devil riders for the drop ramps. Works like a clicky pen, just a short coil pulse to raise the ramp and latch, or pulse again to drop it. Doesn’t require a constantly activated coil. Very slick design that confused me for a while since it’s such a different approach.

    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

    #81 4 months ago

    I did too until I had a Devil Riders, it actually has a 1.5" bumper post that lifts and drops the ramp that is a separate mech from the targets. Zaccaria actually has a lot of wacky mechanisms in various machines. Just look at the 2nd playfield on Time Machine! Though I think your outlane ball save jump is much more fun than their little scoop flippers.

    Looking at your ball lock up-post, keep an eye on the under playfield mechanism for wear. It reminds me a lot of the neck post on Bride of Pinbot. The leverage from the ball can cause the bracket to wear and eventually the post may start to tilt and bind. Fixed that on a buddies machine by putting a bushing up higher just under the wireframe.

    -Hans

    #82 4 months ago

    Yes, most lift ramps in my experience use a latching mechanism. (My experience = Pinbot, Riverboat Gambler, Gilligan's Island, Getaway.) The latch is basically just a small relay.

    Going to be using a lift ramp on Volcano Blast and have the mech sitting in a box of parts pulled from a parted-out Pinbot. I'd be happy to take a few photos if you think it would help (and if nobody with a functional lift-ramp game photographs theirs first).

    #83 4 months ago
    Quoted from Gornkleschnitzer:

    Yes, most lift ramps in my experience use a latching mechanism. (My experience = Pinbot, Riverboat Gambler, Gilligan's Island, Getaway.) The latch is basically just a small relay.
    Going to be using a lift ramp on Volcano Blast and have the mech sitting in a box of parts pulled from a parted-out Pinbot. I'd be happy to take a few photos if you think it would help (and if nobody with a functional lift-ramp game photographs theirs first).

    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.

    #84 4 months ago

    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

    #85 4 months ago

    Do you have room to put a switch near the spinner? That way you could key off that to know that the ball is there and not residual spins.

    #86 4 months ago

    Good Lord this is fabulous. Great work man and some very cool ideas.

    #87 4 months ago
    Quoted from slochar:

    Do you have room to put a switch near the spinner? That way you could key off that to know that the ball is there and not residual spins.

    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
    #88 4 months ago

    you can get the Actual alien switches (just spendy) or the much larger Version on alibaba (cheap but large). Or if you just need a couple.. the Williams style reed switch that doesn’t need a power connection are $15-25 each, depending where you get them.

    #89 4 months ago

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

    #90 4 months ago

    Yes, I’m using them on my upper lane changes. Full playfield, no. Routed out a bit, perfect.. I have not tested the proximity switches yet thru wood, but it’s in my list.. I have both the alien ones and the alibaba ones to try..

    6E151A93-2C5A-48A6-B913-598E175FBDB8 (resized).jpegC1A4AAF9-5441-403A-9F28-098B4A701DCB (resized).jpeg
    #91 4 months ago

    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

    #92 4 months ago
    Quoted from zacaj:

    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.

    Can you embed a switch sideways into the playfield rail wood?

    #93 3 months ago

    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.

    #94 3 months ago
    Quoted from zacaj:

    Unsure what I should do if you manage to get multiple different hands.

    Mode and multiball stacking, of course!

    #95 3 months ago

    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...

    #96 3 months ago
    Quoted from slochar:

    Mode and multiball stacking, of course!

    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

    #97 3 months ago

    It depends on how many modes you're putting in and how difficult it will be I'd think to make stacking worth something. The only game I put it in was Lost Vegas because the goals during the modes (no multiball, there) were still mutually exclusive from one another - i.e. the inline mode is JUST the inline mode, the spinner was JUST the spinner, the 5 bank standup was just there, etc., so you still had to shoot around the playfield, it's just that before the mode start happened, you could qualify more than one mode at a time. You still had to complete them within the time period; there were only 3 time extensions available, so anything you didn't complete, too bad. IIRC I made it a dip setting to either make you requalify the modes you didn't finish, or let you start them again (although with progress lost.... there wasn't any free ram on that game to keep status).

    I suppose it really depends on how many shots you have in the game, and how many of those shots are used for more than one mode, and how difficult it will be to complete. Since it's a one-off I guess it doesn't make sense to code in dip switches and difficulty settings on your game.

    Holding the stack to 2 is a good idea as well, that way there's not too much stuff to decide on in the mode itself.

    #98 3 months ago

    As someone pretty deep rooted in both poker and pinball I am definitely enjoying the sweat on this build

    #99 3 months ago

    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.

    #100 3 months ago

    The balance is definitely something to thing about. Lost Vegas was definitely written in a different era than how I think about rulesets today. I think at the time I was thinking stack stuff to get through to the wizard mode (which was a switch frenzy with varying values) quicker.

    I would never write it again today the same way - first off, I'd use the pinbol/pigs hybrid OS, requiring the weebly board for more ram. A lot of the sloppy coding in it was due to being starved for ram on a -35 board, and having the OS do lots of things it wasn't designed for (no task switching for one), and crunching it down into 2x2732.

    Of course, since the project is more or less shelved because of No Artist and No Soundboard (the soundboard at least could be solved today with the wav trigger.... hmmm.... maybe I should finish the project.... the sounds were all done, at the time I was creating my own soundboard, which just didn't work. It would time out constantly, I was using an arduino as the playback device, or maybe I was using the arduino to control a propeller - I should dig that set of boards out somewhere and document it. Not that it worked correctly, but for posterity's sake.)

    I guess in your case would you want to have concurrent modes that just have differing timers? Don't some of the new stern games have separate timers for each mode even if stacked?

    One thing I do like the idea of is a mode extender target, to increase the timer, and also a grace period timer.

    How many modes are you planning anyway, if it isn't a lot, no need to stack them. STTNG (your favorite game to turn over, IIRC) certainly does well with just the 7 main modes and the 2/3 incredibly annoying neutral zone modes.

    Promoted items from the Pinside Marketplace
    $ 103.00
    $ 48.00
    Cabinet - Other
    ModFather Pinball Mods
    $ 15.00
    Playfield - Decals
    Metal-Mods
    $ 25.00
    Lighting - Led
    Pinshakers
    $ 5,699.00
    Pinball Machine
    Classic Game Rooms
    $ 18.00
    Playfield - Toys/Add-ons
    The MOD Couple
    $ 15.00
    Cabinet - Decals
    ModFather Pinball Mods
    $ 99.99
    Playfield - Toys/Add-ons
    Lighted Pinball Mods
    $ 999.00
    Pinball Machine
    Mircoplayfields
    $ 55.95
    Boards
    Allteksystems
    $ 10.00
    Cabinet - Decals
    Pinball Haus
    $ 115.00
    Playfield - Other
    Great American Pinball
    $ 24.95
    Playfield - Decals
    Hookedonpinball.com
    $ 29.90
    Playfield - Toys/Add-ons
    Pinball Haus
    $ 86.00
    Playfield - Toys/Add-ons
    The MOD Couple
    $ 7,599.00
    Pinball Machine
    Operation Pinball
    € 159.00
    Cabinet - Toppers
    FlipperLED
    $ 99.99
    Playfield - Toys/Add-ons
    Lighted Pinball Mods
    $ 20.00
    Cabinet - Other
    Filament Printing
    $ 16.95
    Playfield - Toys/Add-ons
    pinballmod
    $ 41.00
    $ 339.00
    $ 76.95
    Cabinet - Shooter Rods
    Super Skill Shot Shop
    From: $ 44.00
    There are 142 posts in this topic. You are on page 2 of 3.

    Hey there! Got a moment?

    Great to see you're enjoying Pinside! Did you know Pinside is able to run thanks to donations from our visitors? Please donate to Pinside, support the site and get anext to your username to show for it! Donate to Pinside