What is Wrong With Visual Pinball?

[Isaac Sauvage]

Here is a flipper tester table I made to see how many shots were possible with anyone's flipper settings. I made this to see how the different speeds and flipper settings effected the shots. I thought I might find a nice combination of settings, but without any objects on the playfield, you will soon see that VP flippers have limited shot possibilities at any settings.

that's really neat. tried it once with the default settings:
http://i170.photobucket.com/albums/u258/nicolasb1966/fliptest.jpg

looks like there were 2-3 blind spots for each flipper, although the corner shots probably created one of those blind spots by virtue of added difficulty.

 

[Shockman]

I was surprised about the number of lights I could light up, and the actual lights I was lighting up with certain settings. Meaning the ones hit vs the ones aimed at. Usually off by only one or two in either direction which is not a problem, and realistic, given their small size. Of course the ball is fairly slow and a faster ball seems to screw with the predictability. Sure the timing would be harder, but when a vector is whack, it shows. It is basic and simple geometry though. The angle and speed should be all that is needed to get proper trajectories. However, the speed at the tip is much faster than the speed at the base so the algorithm would have to know the speed of the flipper where the ball is at on it. VP obviously is equipped for this though, but the resolution of that would probably need expanded as well. Hopefully, someday the frequency could be vastly expanded and the scatter angle and oblique correction taken out, which I believe then would make these strange vectors disappear.

 

[sleepy]

Well duh!

I actually tried adjusting table min slope and I note that the ability to levitate the ball on center nudge vanishes if
(1) The table min slope is set to a reasonably higher level relative to the normal force of a slope on a pinball
or
(2)The nudge level is turned down.

I think (1) is the first way to go because a good slope setting cures the problem of floaty balls drifting lazily across a flipper and out the opposite outlane.

And of course with more force on the slope, the strength of Plungers, flippers and other Objects which strike the ball will also need to be adjusted.

The problem is, there are a few authored tables that go with the default settings, and I thought it was the program; that the authors would have adjusted the parameters like min slope/max slope and nudge for accuracy in play.

I am still not clear what Table max slope actually does.
Does that affect slope/ball behavior at the bottom of the table around the slingshots and flippers?
Because a ball coming to a stop on the low end of a playfield appears to be too slow in accelerating even though the table slope is the same as at the top of the table, except that on these tables, the ball is usually also floating around as if on a low slope machine.

 

[Shockman]

I'll check that out. I have asked about slope many times an no one knows. I have been setting both the same because there is no such thing as a range in a set slope. As far as nudging, there is not one or two things missing or incorrect. Everything about it is either wrong, missing, or backwards.

I have spent hours with many of the new settings, trying to set up mmpac for VP9. It's incredible what can happen with bad settings, as far as ball reaction. I have not gotten to the point where experimenting with VP9s settings is actually a settings mode. Right now it is trying to get rid of some strange, stupid, and unrealistic ball behavior. It appears that more physics settings are proprietary to UCVP hardware than many people realize.

At this point, I would be thrilled to hit on physics settings close to VP8 down to VB beta. That is not going to happen though. Not when it comes to nudging. Nudging is now a matter of doing the best you can to script something that is not insulting to pinball. One of the plunger settings I tried put the ball at the same place regardless of pull amount.

There are a lot more combos and values to try though, so it would be some time before I would give up on it.

 

[sleepy]

I remember you saying the nudging is backwards, and sometimes it does feel like it is.
I see that the nudge can be scripted in the keycodes Subs at any direction within 360 degrees if that helps, but then it isn't a default as should be.

But if the slope and nudge are set to the way they are in VP9 in order to facilitate the controller products...why not have the controller software check the ratio of slope to nudge strength and direction in any table and auto-adjust for the controller?
VP could be coded to allow the controller or controller software to override any table settings.

 

[Shockman]

VPdev have admitted that mass appeal has been dropped in favor of niche market. And the niche is a market, where it is not merely made to use expensive hardware, the stewardship is selling the hardware.

That's fine, if it was not argued.

For VP to be as usable to the masses as it has been in the past will take another entire project, which is out of the question at the perhaps hub of the community, as far as availability of it if it did happen.

It really does not matter what the defaults are. What matters is the capability, which has been butchered.

There is only one widely used build of VP9 though it has variations which are mostly the build environment. Usability of this build on desktop computers is arguable, but the fact that it is wanting for what it has already had for so long is not.

Due to the once unimaginable attitude at VPF, and the fierce ease of restoring function which code already exists in other builds, another build that works as good as previous builds on desktop systems would do nothing to bring an end to the split in the community. On the other hand a desktop build at VPF would bring the community back together, but probably diminish sales there, with is obviously the top concern there.

That keycode section scripting option you mentioned, works a great deal, but falters in the recoil timing, as compared to the hard code. It was introduced here at PN and appeared at VPF within a couple of days, and was presented as new and original. I know. I wrote it.