So.. I had a plan to do these developer diaries each week. That didn’t last more than a week. I found I was spending more time trying to record progress than actually making it. There’s also gaps where nothing actually gets done, which would make for some dull updates. So I’ve backed away from the idea of such regular updates and will do them at less regular intervals. I want to try and keep the format however. So anyway, this second entry will be covering progress from 23/11/2020 until 23/12/2020.
The long play session from Sunday brought up a number of things to address with the latest build of the code. Two bugs I thought I had seen the back of came up again, although could not be reproduced 100% of the time. The first one was two balls being served up during ball save. This came up twice during the session. I’ve further tightened up the timeout config settings on the outhole and ball trough ball devices. I have also switched the ball serve for the ball save to occur on a slightly later event that occurs during the ball save process. The second bug is related to the animated star field background stopping in some cases after a second player is added to the game. To get this to occur was not easy as it’s very timing specific. The root cause is somewhere under the MPF hood and not specific to my game. I worked around this same issue last week in other areas of PINBOT 2.0 so was able resolve it using the same method. The animated star field background is an animation I rendered to an animated GIF file that MPF then plays. Currently, this animated GIF is used across many slides and shows in PINBOT 2.0. What I think is happening under the hood is the same animated GIF asset is use across multiple slides and when a slide that uses it is destroyed, it “stops” animating the GIF even though other slides that are active are still using it.
A new bug that came to light during the test session yesterday was the high score mode music would play for a short period when there were no high scores to enter at game over. Since the high score table is cleared with each deployment, it’s not often I complete a game without setting a new high score. Because of how MPF integrates the high score mode into the framework, it will always start the high score mode. With the mode running it then checks for any high scores before either exiting when none are found or running through the name entry process when new high scores exist. I had the music starting on the “mode_high_score_started” event, which isn’t what we want in this case. A new event was created when a high score is detected, which the music handler now listens for. This will now only play the high score entry background music if required.
During the play session, it was found that the drop target timer for advancing to the next planet was a little too short. I’ve increased this by 2 seconds to 16 seconds total. I originally had this set at around 20, which felt too long. So hopefully 16 strikes the right balance.
A suggestion that came out of the play session was to have some small variations on the matrix target SFX. This will add some subtle variety to the progression on the chest matrix. Two deeper pitch versions of the current SFX file were created, along with two that are slightly higher. These were then hooked up to the check matrix switch listeners.
I noticed that the grace period on the ball save wasn’t working as I expected. This turned out to be related to the lamp show that flashes the shoot again insert. I want the insert to stop flashing at the start of the grace period, but it was instead playing during the grace period and then stopping once the ball save had completely timed out. MPF generates several events based on the life cycle of the ball save (started, hurry up, grace period, disabled), so the one I needed to use was grace. Then there is a 3 second window where the light has stopped, but the player can still have their ball saved.
A very minor fix to close out the day was a spelling mistake found in the super pops feature show name and show file name. The file was renamed and references to the display show were corrected.
Today I put together some basic assets for the mystery award feature. These are nothing more than place holder until I have time to come up with better slides and animations.
I decided to change which switches control the extra ball lane change. Initially it was using the new AUX switches I installed on the cabinet, but these were a little too sensitive for my liking. The flipper assemblies have dedicated switches for lane change, so I swapped over to using these. The AUX switches were added primarily for cases where the flippers would not be enabled (video mode, service mode, etc). In this case, the flippers will be active, so I’m best to use the existing lane change switches.
A couple of hours were put aside today to code up the mystery feature. I’ve started out with a simple list of point awards (50K, 100K, 200K, etc) which are rotated between by the pop bumpers and sling shots. Once the player hits all 3 single switches on the playfield (see my previous update for their locations), the mystery award will pop up on screen. It’s unpolished, but the feature is now there and ready to be improved on.
I updated the way in which the mystery award is collected by the player. Once the player has activated all 3 switches, the ramp will lift up. Hitting the stand up target under the ramp will cause the ramp to lower and essentially capture the ball there while the mystery award animation plays on screen. Once complete, the ramp will lift up and release the ball. There are no inserts on the playfield that can be used for mystery, but I have an idea of how I can get around this, which I’ll cover shortly.
The light panel I made awhile back has been crying out for some attention. Now that I’m starting to think about mini / sub modes in the game, I put some thought into how these could be presented to the player since there are no playfield inserts for them. The original PINBOT light panel has eight CPU controlled lamps. These are Match, Game Over, Ball in Play and five lamps for PINBOT talking. I’m going to repurpose those to represent the following: Mystery Award Ready, Retro Mode 1 (BoP), Retro Mode 2 (JACKBOT) and five x mini modes. To start though I need to build a new wiring harness that will plug in to the existing headbox wiring. The original light panel has two connectors which are use for CPU lamps and flasher drivers. The other is for the GI and #1251 lamps.
I hunted through my spare parts and came up with the connectors and pins required. I have a couple of old wiring harnesses that were stripped out of wrecked machines which I can raid for the new harness.
Because I will need to get a new translite designed up, with new artwork, the position of lamps will be subject to change for awhile yet. I decided to design a lamp layout for the GI, flashers and CPU controlled lamps for the lamp panel in Inkscape. The light panel was measured up, along with the size of the sockets to give an accurate layout (in mm) for the position of everything. The good thing about doing it in a program like Inkscape is I can eventually overlay the new translite on top and make sure I get the lamp positions correct.
The position of all sockets were then mapped out onto the light panel ready to drill. I’ll also take this opportunity to trim the lower section of the panel as it’s currently not able to open without the DMD display panel down.
Not much activity to on the PINBOT side of things today, but my very own P-ROC board finally arrived from Multimorphic – which is exciting! I’m looking forward to installing it sometime over the next few days.
Today I drilled all the holes for the small and large sockets. I also trimmed the lower section of the panel so it would better fit in the headbox. The rough edges were patched, sanded and painted.
I took time to map out the old and new connectors, flash board and relay to ensure I would wire up the new lamp panel correctly.
The sockets for the GI, cpu lamps and flashers were installed with the first step of the wiring. This took longer than I expected and I ran just short of the braid used to chain the GI together.
Over the last couple of days I have slowly progressed with the rest of the wiring for the lamp panel.
Something I came to realise as the wiring neared completion was I had not allowed enough room for the 2 PCB’s that are required for the flashers and GI. I’ve updated the lamp socket layout in Inkscape so when I start moving lamps around for the new translite, these will be factored in.
All lamps were installed on the front. Due to the way System 11 games pre charge the flashers, I won’t be using LED flashers, but sticking with the #89 and #1251 globes.
Today I wanted to double check the wiring on the new lamp panel. I put the old and new light panels side by side and double checked the old wiring against my designs above. Went over my new light panel with a multimeter to ensure everything was wired up correctly.
Today is the day to install the new light panel into PINBOT.
The P-ROC board I had on loan was swapped out with my own P-ROC. The new lamp panel now correctly opens without needed to lower the display panel.
I updated the attract mode code to include the eight CPU lamps from the light panel in the animation. The GI and lamps are working as expected, along with my new P-ROC board.
A small code update today to fix a long standing issue. MPF has a “flasher_player” section in the config where you can tell MPF to pulse one or more flashers in the game. While this works, it does run into a few issues with the System 11 platform. The system 11 platform, flashers are essentially just coils and are activated via an A/C relay. This relay switches between the A side and C side depending on what you’re wanting to do. The important coils like ball serve, pop bumpers, ramp, outhole, etc are all on the A side. While the C side is the flashers. If you use the flasher_player to activate a flasher while also needing to raise the ramp or perform a ball save (with the outhole and ball serve coils) it would often result in a locked on flasher coil. Switching the use of “flasher_player” to “coil_player” resolves this issue.
That’s it for this update. This turned out to be quite a large update, with the progress made over the space of a month. There wasn’t as much code progress as I would have liked, but that’s mainly due to me needing to settle on some ideas for the game.