blackmogu wrote:I have to assume you are playing devils advocate here !
Yup. Like you say, something like that is a bit of a no-brainer. Doesn't mean it doesn't happen though.
Plus, it wouldn't necessarily have to be the bank. I presume to make these things playable, there's a lot of subtle juggling going on under the hood. Any small part of that could screw up and have an avalanche effect.
blackmogu wrote:Never tried extreme coding, but I do practice structured development that is scrutinized by hostile parties.
The trouble happens when said hostile parties get their tyres slashed by the object of their scrutiny. Our lead coder was not happy with the repair bill on his Boxter, and he never did find out which one of the 12-strong team did it. It wasn't me, before you ask. ]isn't[/i] professional, but there's only so much crit you can take, no matter how self-effacing you are.
Weyland wrote:I remember when we tried the "Extreme Coding" method as well. We stopped that after the third punch-up erupted in the office. I kid you not. ]
Unforgivable. There is no excuse why the bank is not treated as a locked variable. Any addition to it should be done by one calling function that also references the floating percentage adjustment function. It's then inescapable. Make it transactional as well to account for powerouts, and there is no problem. It's so simple it's ridiculous.
I have to assume you are playing devils advocate here !
Never tried extreme coding, but I do practice structured development that is scrutinized by hostile parties.
I've always thought clubbers were just reworked S34s with different prize structures.
Correct. Bigger prizes. Also better code (for the supplier!).
Ive always wondered why the bank isnt linked directly to the payout!
Actually, I've barely seen any emptiers myself. Do they normally appear to be a "proper" win - IE the display does all the fuss associated with the JP or whatever, or are they just a way of getting the hopper to spit out coins with no other visible change?
If the former, that's far more likely to be a bug in the game code. If the latter, then the comms with the hopper screwing up.
Very interesting thread! I program on a lot lower (or perhaps higher, you know what I mean!) level than you chaps, but the same principles still apply.
I never bought this 'free win' idea before. Surely it'd be simple to have a repeating check to the bank value, and if it doesn't correspond to the value that it 'knows' it has paid, then pop up an error. I realise this wouldn't really be any good 'out in the field' but as part of the testing process, surely it would eliminate 'all' unaccounted for wins?
I am, however, also under the impression that at least 'some' of these 'emptiers' are built in purposely. I'm not saying corruption is rife, but as in all trades / fields, there are the ones who do the corrupting...
If these guys are indeed paid peanuts (and I don't really think they should be!) then things are going to slip now and then...
"And do you ever contradict yourself, Minister?" "Well, yes and no..."
Weyland wrote:Actually, I've barely seen any emptiers myself. Do they normally appear to be a "proper" win - IE the display does all the fuss associated with the JP or whatever...
I've done a fair few in my time. Most emptiers go through the reward sequence for getting a JP. The two different types you get though are 'free win' based, where the floating % is not updated, but the bank increases. The machine pays out and gets progressively happier as a result. The other type, the machine updates everything correctly, but there is a flaw in the program that allows you repeatedly get JP even when the machine is on it's flattest profile (lucky strike, ready to rock, IJ2).
"The two different types you get though are 'free win' based, where the floating % is not updated, but the bank increases"
Like the old 'plugging' trick from years gone by, get win then (while the machine is offering a gamble) turn machine off/on, machine puts the win in the bank but didn't update the reflex, repeat until empty ;-)
Matt Vinyl wrote:Surely it'd be simple to have a repeating check to the bank value, and if it doesn't correspond to the value that it 'knows' it has paid, then pop up an error. I realise this wouldn't really be any good 'out in the field' but as part of the testing process, surely it would eliminate 'all' unaccounted for wins?
Yeah, there has to be some sort of testing done like that. If we presume there is, all these "wrong" wins have been passed - erroniously - by the program. Why it does that is the question. Because some internal store of how much it has to give away doesn't get the win subtracted? Because the % store doesn't get updated? (Although that shouldn't even be stored - it's a function of cash in / out, surely?)
Manufactures have never given a toss about program flaws mainly because they use the operators to "Field test" machines as manufactures testing is minimal.
The accountants that run manufacturing companies are only interested in sales figures,what happens to the machine after that is not of major concern to them, and left to their tech dept to sort out the complaints.
This has been an on going concern since the MPU took over from the electro-mechanical built machine that new machines are sold with unacceptable flaws in the software, resulting in heavy losses that have to be met by the operator of the machine.No operator has been re-embursed for losses incured due to software failure,If that were to happen the machine manufacturing companies would all go out of business due to their own incompetence.
Over the years as manufactures struggle to design games and had their backs to the wall, (they have all been sold so many times is any of them still under British ownership?), the under paid programmer has to turn the software out under pressure as advanced sales are made even before the machine leaves the assembly line.
Operators knowingly buy the machines expecting problems hoping its not an empty,but where else can they go? machine manufactures in this country are not exactly in abundance and all the same as regarding software problems.If operators contact a manufacturer and tell them they have a problem with all their machines showing faults or chucking their gutts out,the standard reply is "We have no software problems" or "We have not been made aware of any problems such as yours".
Manufacturers are constantly upgrading their software with bulletins headed "Critical" or "non critical"updates,but ask them what they are for and the reply will be to "simply correct and enhance the game".
But Mean this "non critical" Just to correct a small fault such as bulb illumination,a sound effect or something similar.
"critical" is the big shit problem and if you dont fit this its going to cost.
The manufactures will then send out these upgrades,to replace the flawed 1.1 version and all the other flawed versions as they will probably onto version 4.2 or higher by then.
The Black box or Data Retrieval system has been used in machines since the eighties,mainly to keep companies and Brewery machine controllers informed of how the machines are performing on their sites.The equipment records all the functions going on in the machine from cash in/out,alarms etc,to how many times the doors have been opened,and even how long in hours/days the machine is switched on/off.
Used correctly the system will detect problems such as fraud and % errors,giving companies some warning of empties and letting them know its time to yet again contact the manufacturer,who will be waiting for the information to help them correct their sub standard software.
The machine manufacturing industry is on a down hill slope desperate for ideas,no wonder players get pissed off with crap thats turned out.
