About the "ball through flipper" fix

[sleepy]

It occurred to me.
In past versions of VP, did the flippers have a Z-axis?
I'm remembering back in the days when the ball was passing through the Ramps, apparently a Z-Axis error, and I'm trying to remember if the Flippers have always had a .Height parameter or was the Flipper.Height parameter added recently in the last several years?

I've seen "ball though flipper" errors on older Flash pinball games. They did not use a Z-Axis. Instead, they used 2D Control Map imaging for collision detection, as a hidden second image of a Ramp, etc., even as the ball is active on a virtual Z-Axis table slope.

I've been trying with no luck to run an older version of VP and have the ScoreText.Text = LeftFlipper.Z
On VP8.1 it will display as ScoreText.Text = LeftFlipper.Height, though that will not necessarily account for the base height of the flipper relative to the ActiveBall.Z position.

 

[sleepy]

And then back in the pre version 6 days there was also the ball through the top of the Wall getting trapped within the outline of the Wall, again indicating a Z-Axis error.'
Once the ball's base Z-Axis was past the top surface, it was trapped, else in those days there was no top surface or was overtaken by the ball's .VelZ.

So what I'm saying is, maybe the ball through flipper error was really the ball Under the flipper on the Z-Axis?

 

[faralos]

no i actually saw the ball traveling OVER the flipper in my versions of vp8. but if you increased the flipper return speed to more closely match the ball speed it stopped the ball-thru-flipper crap altogether!

 

[tiltjlp]

no i actually saw the ball traveling OVER the flipper in my versions of vp8. but if you increased the flipper return speed to more closely match the ball speed it stopped the ball-thru-flipper crap altogether!

Your solution is what Shockman figured out about 5 years ago, but for some odd reason no one has ever paid him any attention. Or given him any credit for it.

 

[StevOz]

No the z-axis makes no difference, you can create multiple superimposed flippers at all sorts of heights or depths in VP8 via setting them to different wall surfaces and you will still get the ball through flipper, a fast down swing is the only known solution that works for most.

 

[faralos]

I've had ball thru flipper with upper tables too so yes it happens no matter where or the z location that flipper happens to be, but that was fixed in vp9.

 

[sleepy]

I'm not arguing, but if there was an error in the Flipper's Z-Axis or the Flipper Z-Axis was simply not implemented then setting Flippers at different Surface heights would make no difference. They would still be operating in 2D or with any potential error.

 

[sleepy]

That the fast return of the Flipper does work might account for offset timing differences or errors in the Z-Axis.
I bring this up only to consider another workaround for older VP versions, but only if the Z-Axis is the point of error and can be controlled in script, or corrected for if and when compiling an older version of VP from source code.

 

[sleepy]

The thread title only refers to the internal fix/code correction in use by the recent VP releases and how they might be getting it to work and not to dispute the value of Shockman's solution.

I'm also out of the loop on this topic, but wanted feedback on the consideration of the possible effects of the z-axis present or absent.

 

[Shockman]

The z axis is most definitely not the point of error. And the faster return does not fix the problem, it reduces the possibility of it by not letting the ball hit the flipper while the flipper is returning.

Now that VP9 is out with a proper fix, it does seem that the problem with it in VP8 has increased. This is not the case.

If you still have problems with balls through the flipper with VP8, the reason, and the solution is the same as it has always been, and the reason is that balls are sometimes moving faster than the flipper is returning, and the solution is to increase the flipper return speed, or throttle the ball down.

I have heard about 4 people, two of which I do not believe out of hand, say that the problem still occurs even with the fix in the core. If this is true for you you should edit the core.vbs file, or set your return speed faster in the tables that it happens. Start by increasing it to .15, this will be physically drastically faster, but not faster enough that you will likely notice it.

It's really a shame. As VP8, with the UC physics is using code from a version that the problem was already fixed in but it did not make it through Randy's porting of it. It was not until we got UC's proprietary, or closer to that, build, that no longer gave us an option to use VP native physics, that we got the fix (VP9).

We can hope that a fix for this will show up in an otherwise VP8 based build, but it is sounds like it is defiantly not going to come from the VPF dev team, if it does at all.