The differences between bugs/hardware/io

[DannyC]

Hmmm, just had an idea pop into my head which could need solving because now its baffling me.

Being a programmer, I've never actually done alot of coding on IO (Input/Output), serial or socket coding.

A Free Win (emptier whatever you wanna call it)is supposed to be but most of the time is a 'bug' in the software coding. For example

BERTS RAMPAGE:
Play for red board, exchange up the cash ladder @ £10 into feature board, take HULA HOOPS feature, next board will be same, repeat until emptied.

Ok, so its quite obvious what the bug is here in the software, but my point is not exactly what it is, but why it is.
Dependant on machine/manu emptiers can vary from the way they are obtained.

A BUG: Hole/Loophole/Misinstance error (not reported back to the software there for leaving an 'open-space').

BUT for a bug to become known, show any instance that it is a bug in the software, it must therefore clash with 2 or more other events that are triggered in that time.

I wont give any coding examples, but if your understanding what I mean carry on, if not turn away!

Action 1 > Action 2(triggers action 4)> Action 5(triggers action 18.a)
Action 1 > Action 3(triggers action 4)> Action 18.a(triggers action 4)

Action 1: User presses Gamble button
Action 2: Display "You Won" message
Action 3: Display "You Lost" message
Action 4: Count Hopper, Retally totals, Distribute to bank
Action 5: Dim Lights, Return to Board
Action 18.a: Add totals to bank, retally hopper totals, percentage key

When the player loses its triggering action 4 on 2 accounts therefore creating a collission in the code, either loopholing or returning errors 'dependant on how the code is handled later on' dont forget programmers are looking at 100,000's lines of code just for one program sometimes, its easy to skip bits, forget or not including certain events/actions/conditions.

If a certain condition is not met, it should create an error and return to a different section of the code that will handle that error, if no sub of the code is put in to handle this error then the software does not know how to handle this error, why or how these things get past the testers I have no idea.

Like I said i've had no experience with hardware-to-software or vice versa coding, never ventured into it, but maybe because of the amount of coding/time to finish project/capital for project and another shitload of reasons or other the software may contain bugs, maybe just maybe hardware could actually create a bug involved in todays machines?

For example, a notechanger, as in my experience some can be pretty unreliable (chewing your notes up) maybe the Hardware-to-Software conversion in the code could return something unhandled?

IE: Im on BERTS RAMPAGE on an IM board, if I stick a £20 note into the machine when on IM board, it slips through the code and cocks up the mech, dont ask me what or why but what other section of the code would it be affiliated? So putting a £20 note (unlikely) in on an IM Board, would make Jackpot repeat for infinity? Because the machine wasn't coded to NOT HANDLE the input of notes into the machine whilst on IM? It was coded to handle notes being put in when on the board, but obviously an IM board is different code to a standard feature board. Get what I mean?

Some mechs/machines also offer 'auto-dump' features on the machine which allow a win of any amount to be automatically dumped straight after its rounded up to its nearest pound and alerted the user of its amount won.

MaybeIm just trying to create scenarios here on why/how and where its going wrong in terms of bugs in machines coding and why there is soo many.

Im also asking the question maybe sometimes hardware can take a play in whats happening, aswell as just down to the code in itself.

End of blabbering, but maybe you get what I mean, when I wake up fresh in the morning I'll be able to correct my post if its gone wrong somewhere or ended up like a load of babbling shit, had a beer and its midnight so excuse me if it is

[Dunhamzzz]

Very interesting post, a lot of thought-provoking stuff in there.

How anyone ever finds out these emptiers is beyond me, must be an inside job tbh.

[levartemit]

Yes some very strange mistakes have got through testing before. Some, like the DK emptier was simply that the programmer forgot to remove his debug routine before releasing the program, and it would only take a sticky button to find this glitch. Others however, say JJ and RP, were extremely convoluted and in my opinion could never have been found by accident. It wouldnt surprise me if that was deliberately coded in, it would be very difficult to find. The SH flaw in LOTR CTL SRR was originally described as an error, but then someone pointed out that on LOTR, the 'feature' SH was not the same as the 'random' one, meaning they were running two different sections of code for the same process, why? Also, of course, a game can never be thouroughly tested for all outcomes until released, but I would be sure a free win could be found quite easily, simply by taking every win and checking the resultant figures afterwards. Very interesting post, I hope it startys some debate.

[Scott]

Free win is always something thats comfused me..

you would think there would be one signle routine in the machine that handled any amount to be added to the bank (ie. a win)

1) Show 'Youve Won: £Amount"
2) Preform any rounding needed
3) Show Bonus: £RoundedAmount
4) Work out new percentage and apply
5) Add to bank
6) Jump back to reel game routine

[anfield road]

I have always thought that if you get a free win on a machine from lets say the board off a £4 shot for example, does the machine think that it has killed you on the board or hasnt gave you a board?

So I thought the next credit may bring a board back? Its really weird theese sort of things with fruit machines. I belive strongly though that every single machine has a glitch or error somewere in it.

[glasagowblue]

For years i have said that these machines are getting more like computers wiith a monitor. I personally am a mame fan and on that front people have rebuilt old cabinets that interface with the pc and games ie coin slot i/o and button/lever use i/o so obvious it works.

I have overlooked the shoulder of the leisure link "rep" while doing the weekly visit to a tote b/m. Simply plugs in data port and downloads info and ticks visit box on paperwork. This info must then be annylised for machine profiit etc so any bugs would be found very quickly unless...........they are dusguised in the programme code !!!

As posted previously some "emptiers" are so far fetched that you HAVE to know what to look for and how to do it. This is why i believe these flaws are there by design, why ? well here i offer a couple of suggestions.

1) Mr programmer is poorly paid and builds in a backdoor to extra wage, puts on disguise or probably gets buddy to "hit" arcades etc for a month with info and build up a nice profit then either leak it to "reliable" source who will then pass it on to his reliable pal etc until the news is out and the machines get hit big time, set off warning bells and voila a re-chip is done. The re-chip software is already waiting as mr progammer has cleaned house to cover his tracks and waits till next reglass or liscense.

2) Mr Manufacturer tells his programmer to build in these flaws, Mr Manufacturer then goes out and leaks info via open forums and or paid "players" who are not discreet or shy in their use until eeveryone is doing the "vivd method". Now the re-chip comes to correct the flaw, try and calculate how many munters have heard of method and have filled hoppers trying it and failing and thought they got it wrong.

I will cast no stones of doubt here but with a few exceptions who can honestly say they alone have found a bug ? Who bar the few have had a machine at home to play for hours on end to see that a certain feature doesn't effect the % or taking it with a bonus number and a red bananna while facing east with a cream cake on your head gives JP repeat 1 in 3 times??

As said no offence to the dedicated few but the rest of us are merely the result of example 1 or 2. The trick is to be in the game while it's there to be played rather than be the profit.

Really need the prinston card counters to give this a look as like all software there will be patterns to learn and recognise but these will only give better chance of winning. What i really want is a mate that writes these progs and cuts me in !!!!!!

Anyone ??????

[Scott]

As far as I am concerned I cant fault the coders at all.. it would be VERY VERY difficult to not put some emptier into a machine or 'miss' a line of code that changes the percentage on some obscure win or setup that is only achieved with loads of messing about with a board...

The money for this could just easily hits tens of thousands of pounds profit from just one model.

[levartemit]

Yes Scott, but how can you explain how people FIND these things? Ok so some are easy but again JJ and RP, who would ever have stumbled on that, feature timeout timeout next win straight away jp hilo et al?? Either they were playing every concievable outcome (pro take years!!) or someone KNEW....

[DannyC]

True but im looking for some reponse in this, I only usually start threads to gain some interest in the title, yet only seems to me that the reguars and stew reply.

Come on, lets get our little thinking caps on and see what we can come up with!

[John Holmes' Stunt C**K]

Some interesting points brought up there Danny. I'm also from a Programming background (professionally), and have played machines for a number of years.

You ask why bugs appear. 2 possible reasons imo.

1 - By accident, the programmer has made a valid mistake, which has not been picked up in the testing phase.

2 - On purpose - I don't go by the theory that manufacturers' gain by placing bugs in their programmes. If a bug is found in a Microsoft product, Microsoft will release "new" bug-free versions for you to spend your money on. Where is the gain from say, Barcrest doing this?? I would say that it is more of a case of a programmer selling this information for a profit.

Using your original example of

BERTS RAMPAGE:

"Play for red board, exchange up the cash ladder @ £10 into feature board, take HULA HOOPS feature, next board will be same, repeat until emptied. "

How can this bug be installed so that it is missed during testing?

**I don't know exactly how a "machine spin" is worked, but i do know that the "spin" is pre-determined before you press start. I also believe each "spin" is distinguished by a unique number, that increases by 1 after each spin**

well....an example of the code for this machine could be:

************************************************** *******

Bank=0; -----ie, yet to bank anything
Credits=4; -----ie, 4 plays left
in=1000; ----ie, £1000 played
out=600; ----ie, £600 won
Current_percentage=(out/in) ---- ie, 60%
Wanted_Percentage=78; -----ie, percentage payout

**********the player is now on the red board, and has exchanged at £10, and taken hula hoop feature***********************************

Red_board=true;
Exchange10=true;
HulaHoop=true;
Procedure "collect_win" called ---ie, the player has pressed collect

*****now, if no bug was present, the following would happen********

Procedure "Collect_win" is: ----what happens when you press collect

bank=bank+win; --ie, the bank is increased by your win
out=out+win --ie, increasing whats been paid out by machine
Current_percentage=(out/in) --adjusting to reflect win
unique_no=unique_no+1; --spin is over, machine ready for next spin

*****now, if a bug WAS PRESENT, the following COULD happen****

Procedure "Collect" is: ----what happens when you press collect

bank=bank+win; --ie, the bank is increased by your win
out=out+win --ie, increasing whats been paid out by machine
Current_percentage=(out/in) --adjusting to reflect win

IF Red_board=true & Exchange10=true & HulaHoop=true

THEN unique_no=unique_no; ---ie, the spin is reset, so that the "spin" has never happened, but the win has still been banked, and so the same events will happen in the next spin, thus, the repeat win

ELSE unique_no=unique_no+1;

END IF

************************************************** ********

This sort of bug wouldn't be picked up in either the de-bugging process, or testing itself. Sorry if i've lost everyone

Going back to what your said originally though, danny. Different Manu's employ different staff, using different Prog languages, with different work ethics. Hence the differences in emptiers, etc