Mark Miwurdz
New member
- Apr 7, 2012
- 684
- 0
- Thread starter
- #21
Way too sensible.
Bugs require a certain series of events to occur. Because each person plays differently, the events may not happen that are necessary to reproduce the bug. The reason some people see the same bugs more often, most likely has to do with play style and reaction times. They hit the same shots a lot, etc.
When this sort of thing happens, any idea where the ball was last? Did the ball(s) in play drain and then it said they were lost, did they go into a trap, if so which ones, etc?
I think it would still be worthwhile to implement some user-activated feature to reset the balls to a known state. As more tables are released, each will bring the possibility of obscure bugs that will be difficult to anticipate, reproduce and fix. Having some sort of "table recovery" option in place for use when unexpected weirdness occurs would lessen the impact of these bugs on players, even if we can't identify what causes a particular issue yet. I could see where this feature might be difficult to implement, as the ROM might get confused if (for example) balls were suddenly "reset" and disappeared from physical locks, but I think the idea at least worth looking into. Of course, I just play the tables, not develop them, so feel free to disregard me if I'm heading completely off base!
Even if we just had an "end game in progress" option (with appropriate safeguards against accidental activation!) so that we could force a malfunctioning game to a semi-graceful conclusion and preserve whatever scores/goals we had attained up to the point when the problem occurred, I think players would be happier.
In situations on the two tables that I've had this happen on - Ripley's (multiple times) and Cirqus Voltaire it has always been during multiball and appears to always have been one of the balls going down a trap/scoop and then disappearing. In RBON, the ball has gone into the main scoop (the amazing events scoop?) during the standard multiball and in CV it went into the sideshow scoop during juggler multiball. It's almost as if the ball somehow falls through the geometry and off of the table, which would fit with what you were saying about it being 'dead'.
Hope that helps.
I was afraid of that. I don't know how much control you guys have over the ROM itself - if there are things you can do to "unconfuse" it or if it is more or less a black box from a coding perspective. Sorry if I sounded like I was trying to tell you how to do your job; that was not my intent at all.The problem is we're emulating real life, so if we do something like, remove a ball from a trap and stick it in the ball trough, the rom gets confused. In real life that can't happen, so it starts doing things like spitting multiple balls in the plunger, or breaking in some other way.
Whats worse, is every tables is different. So it's unfortunatly not a simple thing to fix. Still working on some solutions.
Every bit of information helps. If the ball falls off the table, gravity continues to pull it down. When it hits a certain distance down the ball is reset to the plunger automatically.
Balls in traps are considered "trapped" not "dead". So it's quite possible you are seeing a differnent situation than the one we saw here. If I were to guess it sounds like the ball is trapped, but the switch for the trap didn't get set properly.
This info does give me some things to look into. Thanks.
Thanks for the time Mike. As a Director of IT with a coding background I see your struggle with confirming bugs every day of the week. While we have a much smaller user base than you I find it important to educate that base on best practice for my team to track down a bug. While screenshots, in most cases, are probably out of the question, what would you like to see from us whenwe submit issues on this forum (outside of just giving as much detail as possible). I'd say that would lead to the most constructive reporting for your team.
I was afraid of that. I don't know how much control you guys have over the ROM itself - if there are things you can do to "unconfuse" it or if it is more or less a black box from a coding perspective. Sorry if I sounded like I was trying to tell you how to do your job; that was not my intent at all.
I recently saw something like this on Black Hole. A ball was locked in the capture hole on the upper level, but no new ball appeared at the plunger, and the game was therefore stuck in an unplayable state (with call attendant not working). What's potentially interesting is that, since you can see the locked ball in that case, I know that it wasn't that the locked ball somehow disappeared. It was there in the lock; the lock just didn't have the consequences it was supposed to.
Edit: Unfortunately, I don't remember whether there was another ball locked in the lower-playfield captive hole, which might be relevant to the question of whether the problem was something like a ball missing from the trough.
Mike, Why is the self-test part of the ROM missed out on TPA tables? Wouldn't running that on load be a good way of making sure all the switches and balls are accounted for?
Mike, Why is the self-test part of the ROM missed out on TPA tables? Wouldn't running that on load be a good way of making sure all the switches and balls are accounted for?
While watching the PAPA tutorial I saw the ball search kick in after a minute oF inactivity, but I cradled the ball for over 3 minutes on iPad 2 iOS 5.1.1 with no ball search.
I believe this table is scripted (very well I might add!) but it is still scripted. No ball search, overlapping music tracks, and mystery mirror not showing the bonus long enough (fixed).
I still love playing it, but I'm after authenticity. Can't wait for proper ROM emulation, Gorgar, BH & BK are crying out for Proper ROM emulation.
Is ROM emulation actually on the cards for these tables?
We save out an emulation state, so that the user can start playing immediatly, and so that we always start in a known state. The problem here is the bug appears to be a logic issue, not necessarily a rom issue. Ball is considered dead, but the switches on the table don't match. Seems like a switch isn't being set properly.
Funhouse is definitely rom emulated. The reason you don't see a ball search is because on the real table it doesn't search if the ball is cradled. Because you can cradle a ball to check scores and other info on the backglass displays.
That's what Call Attendant does now, but it doesn't work in all situations. I (and others) have suggested a more forceful version that would cause a stuck ball to be destroyed and re-served to the plunger, but this would often confuse the ROM running the table, as it is not expecting balls to suddenly vanish and reappear elsewhere. This leaves the table in an inconsistent state, which in turn can lead to various bugs and general weirdness.I've had this happen to me once, getting the ball stuck someplace in the top-right during Bride of Pinbot.
Wouldn't it just make sense to have an in-game timer programmed in, so that if there's no table activity, the ball is taken off the table and put into the plunger after xx amount of time elapsed without any on-table activity? Seems like a simple fix to me.
When this kind of thing has happened to me (on Ripley's, I think, which is an emulated table), the table software actually goes into ball-search mode. I think it'd be reasonable for TPA to assume a ball really has gotten stuck or gone missing if the table itself is in ball search: no need for a complex algorithm; the table devs have already done the hard part for you.
Of course, that strategy would depend on the table logic being emulated, which not all of them are. And it depends on whether it's easy for TPA to tell that the emulated software has gone into ball search.