For as long as I've played these things, there has been a school of thought that Electrocoin low-techs contain several pre-determined payout ladders of 10,000 spins per RTP setting (the industry standard whereby Cat C should hit percentage). So, there is no active "compensator" working in the background, the machines are simply following a script and just doing what the script says to do on every spin.
Time to test.
Game: Bar-X 7 - 96% setting, RAM cleared, 10,000 spins on turbo.
Rules: Mess up any nudges offered and refuse the wins
Mess up any 2-symbol holds and refuse the wins
Spin away from any holds offered after a win roll in
Direct roll-ins have to be collected of course
Result after 10,000 spins
Wagered £3000
Winnings £1350
P&L -1650
Payout 45%
Drift £1530
Now you would expect a "normal" compensated machine to start going crazy after a few hundred in and being behind percentage, rolling in jackpots, constantly holding two symbols, nudging, and generally making the test very long winded and tedious. That simply did not happen. At no point did the game attempt to get back to percentage or offer more opportunities to the player than would be the case if playing properly.
After the test, with the machine £1530 ahead, I started playing "normally" to see what it would do and it just behaved like a Standard bar-x 7. 100 quid in for 90 back, 90 in for 50, 50 in for 100 etc. There was no mad payout cycle, nothing. Taking wins did not suddenly kick it into life for the next 1000 spins.
Conclusion
I believe the "payout ladder" theory to be correct. The machine simply offers the player a set, predetermined number of opportunities within the 10,000 spin payout cycle. If an opportunity is missed, bad luck and the machine just trousered a bit of extra cash which will never come back. There are no compensators in the game at all, in the conventional sense.
I also find the suspiciously round number of exactly 45% payout to be another "smoking gun" - as if a certain amount of wins are allocated to roll-ins. If the test were repeated, this time taking roll ins and nudge wins and binning off holds, it would probably be another round number, say 65% (guesstimate).
Thank you for reading these nerdy ramblings and I hope someone finds it slightly interesting!
I do remember hearing, years ago, that the very early machines worked exactly that way: win tables that paid better or worse depending on what the compensator wanted, churned through in order, with a fresh table picked at the end of each sequence, and that the design was changed after the regulator of the day took an interest. I have never found a verified source for any of that, so treat it as folklore. What I can say is that the very first version of Bar-X we have (c. 1990) has echoes of that design in it, percentage tables and a literal 1% threshold, but nothing that stores or replays result sequences. If there is any truth in the story it would be the very first generation of machines (pre-1990), for which I don't think any ROMs survive.
In the versions we do have, everything I have seen while building the emulator says there is no list of results waiting to be played out in order. Every spin is decided live, from a random value the game fetches at the moment of the spin, so two identical sessions will not play out the same. The compensator is much quieter than the folklore says. It keeps a running total of staked and paid and compares it with the percentage setting. When it is behind, it does not go into a frenzy of holds and nudges. There is no code for that at all. All it does is quietly favour the bigger wins for a while, and those arrive as ordinary roll-ins. So the catch-up you were watching for is invisible by design. Your test felt like nothing was happening because that is what it looks like.
The thing that has surprised me most while developing the emulator is how random these machines are. Like many people, I played them for years before quitting and had all sorts of pet theories about how they worked. The boring, brutal truth is that the compensator gating wins through when the machine is behind target (and holding them back when ahead) is the only structure there is; everything else is chance, streaks included. They are probably the fairest machines out there. This was one reason I favoured them as a player: you wouldn't get professional players emptying them, simply because they couldn't. They hold their percentages faithfully over the long run, and the drift (or volatility) either side of target is where all the character is. We have all walked onto a Bar-X and had the Bars drop in and hold within a few quid, and equally I have pumped £500 into one as well (Nobles used to have massive drifts). Some older machines are very "flat" and the drift won't be more than £20/30 either way (under or over paid), making a total drift range of around £50.
Another cold, hard truth is that any difference between the emulator's numbers and a real cabinet's is probably down to the emulator. Machines are notoriously bad at generating random numbers. Basically they can't, so all sorts of clever algorithms are devised to generate pseudo-random numbers from things like timers, how long the machine has been switched on, and exactly when the player presses the start button. All machines (and early computers) start with a "seed" which produces a list of random numbers that will be identical for that seed every time it is used, which would make for a very predictable (and dull) player experience. These machines get round that by generating fresh seeds every time they are powered up, so no two boot-ups play out the same. The money bookkeeping is different: that survives the power cycle in the battery-backed memory, so the machine remembers where it stands against its percentage even though the dice are new. One nice detail from the reverse engineering: in attract mode the machine runs a timing counter that rolls round on roughly a 21 second cycle (the exact length is itself set by the seed at power-up), and where you are in that cycle when you press start feeds into the result. So even the time you spend fishing for a coin changes what you get. Not that anyone could ever use that: there is no way of telling where the counter is from the outside, which is rather the point of the design. My soak tests use the same seed deliberately, to get consistency when testing. I found that the point at which start is pressed is a massive influence: the first version of George (the emulator's autoplayer) pressed start at exactly the same instant every spin, which skewed the numbers in a way no human player would produce. George now has "jitter", which adds a random number of milliseconds before pressing start, and that restored the natural spread you see from a real player.
Getting the emulator to hit percentage at all was one of the hardest parts of the whole build. The payout behaviour on these boards depends on parts of the hardware that have never been documented anywhere, and the emulator has to get those exactly right for the numbers to come out. This is the reason there are so many stats and tests in the emulator. I did wonder whether I should include them in the release, but thought some people would find them of interest. Small differences move the payout figures, and early versions were further off than the current one. So treat the emulator's RTP as close but not gospel: it may not match a real cabinet exactly.
So, with all this said, EFME makes an absolutely sterling attempt at recreating the real machine but it will never be 100% accurate to a cabinet. Indeed, each cabinet will vary due to individual component tolerances on the board. Wizard made the same note about MFME, and I have added a note to the About page so people are clear on this point.
Which leads us to the results you got. Your refused wins are the interesting bit. When you mess up a nudge, the game books that spin as a zero-payout game, so it does know it is behind. Whether the money finds its way back depends on the machine. I repeated your test with the emulator's autoplayer set to refuse everything (mess up the nudges, hold two different symbols, spin winning lines away, collect roll-ins only). On Bar-X 7even 25 quid at the 88% setting it still paid 89% over 10,000 spins, the whole percentage delivered through roll-ins. On the 35 quid version at 96% it managed about 85%, so refusing cost about 11 points there. Nowhere near 45% on either. So I can't explain your results. All I can suggest is that I am running a newer version, and I am constantly refining the payout behaviour, which may account for it.
Your tests have prompted me to add George profiles to the next version of EFME, of which there are two initially:
1. Best Strategy (the default): George plays like a competent player - nudges to the best reachable win, holds winning pairs and triples.
2. Reject Wins (the experiment profile): he deliberately refuses every player-assisted win - wastes nudges on a losing line, holds two mismatched reels, spins a showing three-of-a-kind away; direct roll-ins still collect.
I have also added the ability to specify how many spins George does before stopping (default 10,000) to allow scientific tests.
In conclusion, the testing is more about the distribution of random numbers than anything else. For me, the drift is the most interesting part. It shows the volatility of the different machines, and in a world where people are losing thousands on digital machines, volatility is certainly a hot topic.
If you do spot any further oddities please post them and I will investigate. The emulator's main soak test (on the Developer menu) runs 50,000 spins across 5 different seeds and works to a tolerance of +/- 2 percentage points. Interestingly, the compensator is what makes that possible: a pure-chance machine with no compensator would need millions of spins to prove its percentage to that standard.
Very interesting write up, thank you. I wonder why we ended up with such different final % results.
I wanted to add that I have repeated this several times with similar results now.
One interesting point that I didn't mention before but it's happened on most runs - on spin 10001 the machine can error with code "EE" in the credit display and requires a soft reset to continue. I have had this error a few times in the wild but only on 94% RTP setting, after the machine has done a massive dead spell for real.