Looks great! I like the simple artwork and the woodgrain area around the flippers. It definitely fits the theme. Can't wait to see it in action.
Great work! Big fan of the cabinet artwork and coin door inserts. Very tastefully done and reminiscent of the old spray on work of the 50s/60s/70s.
This is a gorgeous homebrew and looks like a fun pin to shoot, love the choice to put a pop bumper down low on the playfield. Great work on the art direction, layout, everything. I was considering doing something similar at one point (EM-style homebrew on a Proc or something similar) but was overwhelmed with where to even start. Did you use mostly original hardware from an EM or all new components (like the bumpers and everything)? And how'd the you handle the score reels, what kind of stepper motors?
I can't wait to see the final product! My two daughters are Potterheads and they love the concept.
Alberto
Quoted from nogoodnames222:Did you use mostly original hardware from an EM or all new components (like the bumpers and everything)? And how'd the you handle the score reels, what kind of stepper motors?
I did have a donor pin that was really rough. I used a few of parts from it including the cabinet. Most of the above playfield parts are new.
I used the original score reels from the donor pin, no steppers. All of the guts are Proc and new stuff. I made my own lights as I only needed one color- (most of the stuff you can buy for lights are RBG type.)
The main goal is to make it appear to be a EM...
Thanks for all the compliments, greatly appreciated.
Are you going to be able to bring this thing to TPF? I saw in an earlier post that you didn't think you were going to make it... but it looks like things might be coming along? Would love to see this thing in person.
Quoted from ryan1234:Here is some more game play and rules
That’s very nice. Classic.
This turned out phenomenal, and I love how you stuck to the actual scoring of Quidditch (but in a way that makes sense for a balanced game of pinball). This might be one of the most well polished homebrews I've seen, really making me want to do something of my own in the future. I think I might need a Silmarillion EM-style machine to put next to Hobbit + LOTR...
Great work on this.
Quoted from nogoodnames222:I think I might need a Silmarillion EM-style machine to put next to Hobbit + LOTR...
YES
No real updates... I am hoping that Texas Pinball will happen in 2021 so I can take it....
Thanks for all the kind words!
It has been working well. Thanks for asking.
I added a center post between the flippers to make it slightly easier to catch a snitch. Other than that, it has worked better than I expected- I thought it would be more finicky being a homebrew.
So cool. Question: do the chimes sound out after something is hit? Seems like it has a bit of latency and wondering where that’s coming from
Yes, the chimes are slightly late… I am using MPF for programming- it doesn’t work correctly unfortunately. I sure wish it did. I just think that the chime part of their program is not used alot so they have not fine tuned it.
I just discovered this thread. Great build! Chimes: are you using a coil_player to run them? If so, you are loosing a bit of time due to USB latency and also processing on the host computer. If you set up each chime as an auto fire coil linked to the pop bumper, slingshot and drip target switches your latency will go away. You can use enable and disable events for the auto fire coils on the fly to allow different chimes to be controlled by the same switch. The code for this kind of setup is easy-peasy. Reach out here or on slack's PinDev if you want any help.
Quoted from Cmartin1235:I just discovered this thread. Great build! Chimes: are you using a coil_player to run them? If so, you are loosing a bit of time due to USB latency and also processing on the host computer. If you set up each chime as an auto fire coil linked to the pop bumper, slingshot and drip target switches your latency will go away. You can use enable and disable events for the auto fire coils on the fly to allow different chimes to be controlled by the same switch. The code for this kind of setup is easy-peasy. Reach out here or on slack's PinDev if you want any help.
This had been a real bummer, and I remember trying everything to get rid of that lag…
I had problems when set it up for auto-fire, they way chimes work, it doesn’t always fire the same chime for a switch, sometimes you needs it to fire the 10 point chime, sometimes that same switch needs to fire the 100 point chime (at 99 points -next 10 point needs to hit the 100 point chime.)
I am very open to a neat way to solve this problem. Please help!
Are you using the score_queues and score_queue_player to do this in MPF? I'm not sure when this got added to MPF, and while I have set it up in my current project I do not yet have the machine built so am not sure how well it works.
https://docs.missionpinball.org/en/dev/game_logic/scoring/ss_style_score_queues.html
Quoted from BorgDog:Are you using the score_queues and score_queue_player to do this in MPF? I'm not sure when this got added to MPF, and while I have set it up in my current project I do not yet have the machine built so am not sure how well it works.
https://docs.missionpinball.org/en/dev/game_logic/scoring/ss_style_score_queues.html
Yes, I do use the score_queue_player or the score_reel_player(I can’t remember the exact name) It works, for keeping track of score and the score reels, just the chime part doesn’t work.
I admit, I am not the greatest programer- I am probably missing something… I did try everything I could think to try.
Anything that MPF drives from the a player is subject to latency. You can see it with sounds and lights which lag a little bit behind switch closures. Normally this isn’t very noticeable unless something is bogging down the system or the host MOBO is slow (like a raspberry pi). For very tight integration between flashers or chimes setting them up as an auto fire coil works great, But they have to be on a PD-16 driver circuit for it to work.
Can't see in the video, but are the chimes in sync with the score reels? I wonder since the score queue player has a delay to make sure the chimes don't fire to fast if it has that delay before the first firing in the queue, which would certainly explain what you are seeing.
although looking into it, they are likely using score_reel and score_reel_groups for the config which also has chime setup in it and setting for repeat_pulse_time which would be a similar thing.
I know Hot Rod used that setup as well and just looking at a video of his it shows the same thing, but the video shows the backbox so it does show that the chimes are firing when the score reel fires, not necessarily when a switch hit happens just like you are seeing. Might be worth a post on the mpf user groups forum to see if the devs there have an idea.
I looked a an old video of my machine that uses chimes, but is setup to pulse just on switch hits, and there is no noticeable delay, so I think it is something in the score reel programming that introduces the delay.
I will have to look at it again. I do use a raspberry pi, but everything else seems to work fairly quickly. I think I have the chimes auto-fire off the coils off the reels- because the score reel group did not work with chimes…
I am also using a PD-16
The asynchrony is probably multi factorial. A faster motherboard might remove it but being that the chimes are firing with the score reel, that means that it’s all being processed by MPF first which creates the latency. If you drive the chimes as auto fire from the switches, the issue can be made to go away. But it boils down to is it worth revisiting the code for such a minor thing When the rest of it is complete and is working so well.
Quoted from Cmartin1235:The asynchrony is probably multi factorial. A faster motherboard might remove it but being that the chimes are firing with the score reel, that means that it’s all being processed by MPF first which creates the latency. If you drive the chimes as auto fire from the switches, the issue can be made to go away. But it boils down to is it worth revisiting the code for such a minor thing When the rest of it is complete and is working so well.
I have no problem driving the pop bumpers with auto fire, and there is no latency on the reel coils, so it is not the raspberry. If I remember correctly, there were limitations on using auto fire- like how many switches it could be tied too?… I need to take a look at it….
You probably already know all this but other people reading may not. Auto fire bypasses processing by MPF Creating a connection from the switch to the p3-roc and directly to the coil. Latency with auto fire is something like 5 ms, undetectable by even the best gamers. That’s why it’s used for flippers, pop bumpers and slingshots. Sounds, light shows, score reals (and in your case chimes) take an indirect route through the p3-roc to the raspberry pi, are processed by MPF and then driver commands go out again. Depending what else is going on in the pi the latency often adds up to more than 100 ms which people notice easily. One time on a relatively fast motherboard when I had a bunch of light shows and some intensive graphics going on, my sounds and lights were delayed for a whole second because MPF couldn’t keep up. I had to solve that one in hardware by putting a graphics card on my motherboard, offloading graphics processing from the i3 and returning cycles back to MPF. Anyway, I digress. It’s a great game and I hope I get to see it in the show someday.
Really cool project! Your rules are really clever, especially making it work for a simple EM design. "Chasing" the yellow targets to eventually get a big payoff with the snitch is the kind of creative pinball rule I love: makes sense for the game, AND captures the idea of the theme. Great work!
Quoted from Cmartin1235:You probably already know all this but other people reading may not. Auto fire bypasses processing by MPF Creating a connection from the switch to the p3-roc and directly to the coil. Latency with auto fire is something like 5 ms, undetectable by even the best gamers. That’s why it’s used for flippers, pop bumpers and slingshots. Sounds, light shows, score reals (and in your case chimes) take an indirect route through the p3-roc to the raspberry pi, are processed by MPF and then driver commands go out again. Depending what else is going on in the pi the latency often adds up to more than 100 ms which people notice easily. One time on a relatively fast motherboard when I had a bunch of light shows and some intensive graphics going on, my sounds and lights were delayed for a whole second because MPF couldn’t keep up. I had to solve that one in hardware by putting a graphics card on my motherboard, offloading graphics processing from the i3 and returning cycles back to MPF. Anyway, I digress. It’s a great game and I hope I get to see it in the show someday.
I am not sure how to get auto fire to work for the chimes. Auto fire only works when one coil is tied to one switch, I need to fire different chimes based on the score at the time the switch is hit. There is a chime for each- 10’s, 100’s, 1000’s.
Example- switch “1” scores 10 points per hit.
When switch “1” is hit, it would trigger the 10’s point chime. But if the score is currently 90 and then switch “1” is hit, the 100’s chime needs triggered. That would be one switch tied to two auto fire coils…
Maybe there is a way to disable and enable auto fire based on current score(that may lag?)
I really appreciate everyones thoughts!
Thanks for the help.
Wanna join the discussion? Please sign in to reply to this topic.
Great to see you're enjoying Pinside! Did you know Pinside is able to run without any 3rd-party banners or ads, thanks to the support from our visitors? Please consider a donation to Pinside and get anext to your username to show for it! Or better yet, subscribe to Pinside+!
This page was printed from https://pinside.com/pinball/forum/topic/my-homebrew-lots-of-questions/page/2?hl=sixtyfourbits and we tried optimising it for printing. Some page elements may have been deliberately hidden.
Scan the QR code on the left to jump to the URL this document was printed from.