Perfect Deal Emptier Coding

[CraigDag]

Hey all,

So I have very fond memories of this emptier when it came out and have always been curious as to how it actually worked. I tried over the years to reverse engineer things from the binary files but I am just not that good or dedicated.

Recently with the uptick in AI I decided to let Claude loose on files I had been pottering about with over the years along with explaining the machine and the method for emptying it to the model. Everyone who played BellFruit DOND games had come across the free gamble from the extra life before but what I never understood was why you could keep gambling from the start square without dying. This of course appeared in a few other machine methods.

The reason for this turns out to be a flag set when achieving the feature. It's meant to make sure you have at least one press before you die, or at least have good odds at that. However by staying on the square and gambling hi and lo the counter never increases, meaning the threshold is never met and allowing you to farm the bonus and manipulate the boxes. This tiny little bug mixed with their game design is what allowed it to be emptied. Summary from Claude:

 

"Every time you gambled Hi or Lo, the machine had already decided whether you were going to win or lose before the number reel even started spinning. There was a function that ran first and set a simple flag: 0 for win, 1 for loss. Then a completely separate bit of code picked the actual number and physically moved the reel into position to match whichever outcome had already been decided.

Inside the "gamble outcome decision" function, there was a variable that acted as a feature board "step counter". It tracked how far you'd progressed around the feature board. The idea was the further you get, the harder the gambles become. Early on, easy. Later, harder.

The problem is this counter only went up when you moved to a new square on the board via a "Carry On" action. If you were gambling on a SPIN square and kept winning, you stayed on the same square. The counter sat at zero.

And when it was below 3, every single loss check inside that function was impossible. One check asked "is a random number plus 10 less than the counter?" - well, anything plus 10 is at least 10, and 10 is not less than 0. Another asked "is the counter greater than 2?" - it's zero, so no. They all failed the same way. The code fell through every check and landed on: you win.

As long as you picked the favourable direction on the number reel - Hi when the number was low, Lo when it was high - the machine literally couldn't make you lose."

 

Old news and not very relevant anymore but I thought it was cool to know.

 

 

[dondplayer]

Except that some of the above is inaccurate at best.

This particular emptier worked simply because the coder had not thought of a couple of options the bonus on the number reel could give.

Once on the feature board you could high and low forever until you reached one spin away from filling the grid for the DOND feature. So if you had boxes in view and held that would only be a few spins but if you had no boxes in view that would be infinite spins. This is not seen as a problem on the face of it but that's where the first mistake was made....... and so on.

[CraigDag]

That's right but apparently the reason you could hi lo until this point is because of this flag not being incremented during the hi lo sequence in the program, there is a flag to block the DOND game and 4 options for incrementation of the "player move" flag.

The Hi Lo on the first square doesn't affect that "player move" flag as long as you haven't moved, so the check written in the code for this flag always comes back as a pass. After you have moved, when you take a hi lo gamble it looks like the flag is incremented depending on various different outcomes.

[MikeyMonster]

Thank you - that's pretty informative.

[Chopaholic]

1 hour ago, CraigDag said:

That's right but apparently the reason you could hi lo until this point is because of this flag not being incremented during the hi lo sequence in the program, there is a flag to block the DOND game and 4 options for incrementation of the "player move" flag.

The Hi Lo on the first square doesn't affect that "player move" flag as long as you haven't moved, so the check written in the code for this flag always comes back as a pass. After you have moved, when you take a hi lo gamble it looks like the flag is incremented depending on various different outcomes.

But that suggests that no one noticed you can gamble on the SPIN squares until you're one away from getting to something important, during the entire coding and testing phase. You literally just need to play the game for five minutes to work that out.

[CraigDag]

You're right, in my excitement for getting the code decompiled and looked at I just gave it my memories of how I used to do it and didn't bother to look much further than that so likely I'm getting back biased information based on my incomplete understanding.

As best as I can see from the renamed functions, it is still to do with this "player move" or "player action" flag which it doesn't execute when gambling hi / lo on the spin square. As you play it increments, including during hi lo on other squares but not on the spin square on this first chip. Back to the drawing board and thanks for keeping me right.

Also happy to share the psuedo c decompile that I'm working with if anyone more knowledgeable than me wants to look through it?

Edited March 2 by CraigDag

[thealteredemu]

Was this chipped out in an update.

If so you could maybe decompile that one and you’ll be able to see what was fixed.

It sounds like the hi lo will win unless there is danger from achieving something the machine is actively blocking (depending on current %).  But the machines fails, as dondplayer points out, it’s overlooking potential gains on bonus numbers on the reels.

Strange that they did it this way.  Huge oversight especially since lots of the dond games had ways to be manipulated. 

J

[CraigDag]

I've got £100 version update but not the £70 updated program. Had this exact same thought earlier too but will finish the work on this one first and maybe keep my face shut instead of getting excited and posting ahead without checking things!

Will be interesting to see the differences between the two.

[thealteredemu]

What you’re doing is fantastic mate.  You’re only interpreting the code.  Those mechanisms you found are real and have a huge impact to how these were emptied.   Carry on the fantastic work on this disassembly project

J

[Chopaholic]

44 minutes ago, thealteredemu said:

Was this chipped out in an update.

If so you could maybe decompile that one and you’ll be able to see what was fixed.

It sounds like the hi lo will win unless there is danger from achieving something the machine is actively blocking (depending on current %).  But the machines fails, as dondplayer points out, it’s overlooking potential gains on bonus numbers on the reels.

Strange that they did it this way.  Huge oversight especially since lots of the dond games had ways to be manipulated. 

J

Yeah it really felt like they were playing were fire with that mechanic. I never worked out the emptier myself (never had a real one here and I don't have the skills to work out that sort of thing anyway), but when I first played it in the emulator I thought, 'Hmmm, this seems a bit risky', and so it proved!

I talked about this in the video I made for it, direct timestamped link:

(For some reason this video got age-restricted.)

 

[Chopaholic]

48 minutes ago, CraigDag said:

I've got £100 version update but not the £70 updated program. Had this exact same thought earlier too but will finish the work on this one first and maybe keep my face shut instead of getting excited and posting ahead without checking things!

Will be interesting to see the differences between the two.

It's an interesting conversation to have but in this case I honestly think the critical mistake was the code not looking ahead enough and accounting for the other factors that could lead it into a situation where the DOND game could be trapped, and then the invincible (as the mechanism is the same, filling up the boxes).

BFM's DOND output was notorious for being doable, some players say that basically every single DOND they made had something on it at some point.

[dondplayer]

16 hours ago, CraigDag said:

The problem is this counter only went up when you moved to a new square on the board via a "Carry On" action. If you were gambling on a SPIN square and kept winning, you stayed on the same square. The counter sat at zero.

This is where 'Claude' made a wrong assumption. You can stay on the first SPIN square but you can move around the board until you land on another and then still h/l forever if boxes not in view.

As I said before it's simply the coder thought it was of no consequence and as someone else said it would have been flagged in testing as a weird quirk if it was an error.

Carry on deciphering though

[CraigDag]

To be fair to Claude, I think that's from what I told it since that's how I used to do it. I got carried away with the method I had used IRL instead of checking out the entirety of what's going on inside the emulator. My context gave it the wrong idea of what was going on.

I'm just really curious to see where everything collides to make it possible. As you say it's likely this one oversight and as had been mentioned above almost all DOND's had something on them at some point be it reversing lives, forced GATW for multi potting, bonus rips etc etc etc Many different bits to be looked at but for some reason this one has always stuck in my head and to see it in the code is kind of cool considering how many hours we spent travelling and looking at these things from the outside.

[Boulderdash]

3 hours ago, Chopaholic said:

Yeah it really felt like they were playing were fire with that mechanic. I never worked out the emptier myself (never had a real one here and I don't have the skills to work out that sort of thing anyway), but when I first played it in the emulator I thought, 'Hmmm, this seems a bit risky', and so it proved!

I talked about this in the video I made for it, direct timestamped link:

(For some reason this video got age-restricted.)

 

What's the timestamp please - this goes to the start for me

[CraigDag]

If anyone is interested in the difference between the two that Claude found when comparing the files I've put the analysis in this folder under "exploit_comparison.md" and I've also included the two psuedo c files I was working from.

Google Drive Folder

 

Not claiming them to be accurate, just if anyone wants to see!

[spa]

Pre everything on this we always hi/lo'd so it was 1 away from opening. Even without all the good stuff, it was very playable, playing it like a mega. Then the empty came along but even after that it was so twattable! Still is on £100, they just couldn't fix it.

[dondplayer]

1 hour ago, spa said:

Then the empty came along but even after that it was so twattable! Still is on £100, they just couldn't fix it.

Yeah I thought they would take the rip out of the £100 which was easily done by stopping that last gamble winning (which is blocked sometimes anyway) but they just left it in.

[logopolis]

3 hours ago, spa said:

Pre everything on this we always hi/lo'd so it was 1 away from opening. Even without all the good stuff, it was very playable, playing it like a mega. Then the empty came along but even after that it was so twattable! Still is on £100, they just couldn't fix it.

The last one I played in the wild was in Andy's at Hunstanton. The  machine company guy told him to get rid of it from his arcade!

[spa]

2 hours ago, dondplayer said:

Yeah I thought they would take the rip out of the £100 which was easily done by stopping that last gamble winning (which is blocked sometimes anyway) but they just left it in.

If it just didn't skip the phone, that would have done it.

[Chopaholic]

15 hours ago, Boulderdash said:

What's the timestamp please - this goes to the start for me

1m48s should be the charm.

[dondplayer]

12 hours ago, dondplayer said:

Yeah I thought they would take the rip out of the £100 which was easily done by stopping that last gamble winning (which is blocked sometimes anyway) but they just left it in.

 

9 hours ago, spa said:

If it just didn't skip the phone, that would have done it.

Actually maybe not - if you still had your life and it landed on the phone you could make your way up at the expense of the life then, if necessary, do the routine.

[spa]

You lose the bonus if you lose the hi lo?

[dondplayer]

10 minutes ago, spa said:

You lose the bonus if you lose the hi lo?

If the bonus not taken it just stays lit where it is if you lose the h/l - unless it's different on that particular square but I don't see why it would be. Or I am misunderstanding what you meant originally.

[spa]

I think so, if you hi/lo the bonus and lose the hi lo, does it not reset it back to the bottom? Pretty sure it does.

[dondplayer]

13 minutes ago, spa said:

I think so, if you hi/lo the bonus and lose the hi lo, does it not reset it back to the bottom? Pretty sure it does.

No mate I think you are mixing it up with when you take the extra life (second up) and that removes it and you gamble to start your way back up from the bottom.