1002 replies to this topic

[unclewilly]

There is actually a table dimensions manager built into vp now so tables should be sized correctly.
It even converts from inches to vp units

[boiydiego]

so it will set the table automaticly ? ? tspp +nm the where bad converted by author ..

[Noah Fentz]

Maybe for compatibility something like this helps? Const BallSize = 49.99

  It might work to reduce the ball size a bit, yes. I general I don't pay too much attention to compatibility here since it will be the basis for VP10 which breaks compatibility anyway, but for porting old tables it could be a viable workaround.    

 

@Mukuste   I tested the new Keyboard Nudge physics with the attached Accelerometer test table: The ball normally appears on the table with no slope or movement. When you nudge the ball with the keyboard it moves and stops but doesn't return to its original position. With the old nudge physics it would move and continue rolling.   With your test table that was attached to the physics4 release I lowered the slope down to .1 to slow the ball down to better see the effect of the nudging while still moving After it slows down bouncing around the table, you can notice that the ball nudges and seems to return but the trajectory of the ball is still changed some but not as much as it used to.   I feel in a real Pin the trajectory of the ball does not change, Unless of course the ball encounters a play field object because of the nudge.   The new changes are an improvement, but wouldn't it be even more realistic if the ball in the Accelerometer test table returned to its original position? This is just a suggestion not a complaint.   If you could also make a test release with the changes to the analog nudging, I would like to test that also. I have both a PBW desktop controller and Noah's controller in my cabinet to test with...   Thanks for your improvements on the VP physics, Rich

  Thanks for testing. I'm aware of this behavior. The table does return completely to its original position, but the ball retains some displacement because of friction effects. The reason, I think, is that the backswing is by necessity slower than the initial swing (otherwise the table would oscillate indefinitely). Therefore, on the backswing, the friction with the playfield has more time to work on the ball and displaces it more.   The same effect applies to the change of the trajectory. Of course, with a very slowly moving ball (at a slope of .1), the change of trajectory is much more pronounced. At a realistic slope, in my experience, the effect is very small.   All of these effects also depend on the nudge force and the nudge time, so try playing around with those!   In fact we have to try this with zero friction to see if my theory is really true, in that case the ball should return completely.   Anyone up for an experiment? Take a pinball, place it on a flat surface (a desk will do, I guess, depending on the surface material) and nudge away. Does the ball return completely to where it was? My guess would be no, but it would be interesting to find out!

That is 100% correct, contrary to what many others have argued. I've posed this very question to multiple, world class players, and they all concur. You can definitely alter the ball trajectory without hitting objects by simply nudging. The harder you nudge, the more it can be altered. Whether you can get away with that extent of nudge without tilting isn't relevant to the physics. Obviously, the less friction, the less it will be altered. I just picked up a JD, and it pisses off my friends when they watch me do it every game. The tilt is all but disabled, of course.

[unclewilly]

so it will set the table automaticly ? ? tspp +nm the where bad converted by author ..

No but it contains a list of most pinball table sizes by manufacturer and converts there actual dimensions to vp units so when building you can use the actual size

[Pinbotfan]

It only takes one nudge on a real machine to see that the table goes back to where it was . Not almost, where it was. And for all intents and purposes as fast as it got there. If I wanted to delineate the ball, it would not be a typical nudge (a bump), but I would hold the table (a shove) and let it back slowly while holding it so friction would overcome the swift shift in the table position. A split second versus a big chunk of a second, and though you can say you're changing the vector, it is still a small amount and because of the extra time involved in doing it, is limited in repetition as well. It's also a trick that would not serve a simulation very well unless it took something extra to achieve and a bump had an equal (within truly negligible value) spring back. This is my non professional opinion and experience. 

[Noah Fentz]

It only takes one nudge on a real machine to see that the table goes back to where it was . Not almost, where it was. And for all intents and purposes as fast as it got there. If I wanted to delineate the ball, it would not be a typical nudge (a bump), but I would hold the table (a shove) and let it back slowly while holding it so friction would overcome the swift shift in the table position. A split second versus a big chunk of a second, and though you can say you're changing the vector, it is still a small amount and because of the extra time involved in doing it, is limited in repetition as well. It's also a trick that would not serve a simulation very well unless it took something extra to achieve and a bump had an equal (within truly negligible value) spring back. This is my non professional opinion and experience. 

 

Trust me. I can change the trajectory of the ball with moderate nudging. I do it all the time, as do the pros.

 

To appease everyone, just put a return factor that, at 100, returns the ball to exactly the same place, and 96 would cause a 4% differential. Otherwise, we'll just be going 'round and 'round about it.

 

[chepas]

There is actually a table dimensions manager built into vp now so tables should be sized correctly.
It even converts from inches to vp units

 

Genius!

[RYSr]

 

@Mukuste

 

I tested the new Keyboard Nudge physics with the attached Accelerometer test table:

The ball normally appears on the table with no slope or movement. When you nudge the ball with the keyboard it moves and stops but doesn't return to its original position.

With the old nudge physics it would move and continue rolling.

 

With your test table that was attached to the physics4 release I lowered the slope down to .1 to slow the ball down to better see the effect of the nudging while still moving

After it slows down bouncing around the table, you can notice that the ball nudges and seems to return but the trajectory of the ball is still changed some but not as much as it used to.

 

I feel in a real Pin the trajectory of the ball does not change, Unless of course the ball encounters a play field object because of the nudge.

 

The new changes are an improvement, but wouldn't it be even more realistic if the ball in the Accelerometer test table returned to its original position?

This is just a suggestion not a complaint.

 

If you could also make a test release with the changes to the analog nudging, I would like to test that also. I have both a PBW desktop controller and Noah's controller in my cabinet to test with...

 

Thanks for your improvements on the VP physics,

Rich

 

Thanks for testing. I'm aware of this behavior. The table does return completely to its original position, but the ball retains some displacement because of friction effects. The reason, I think, is that the backswing is by necessity slower than the initial swing (otherwise the table would oscillate indefinitely). Therefore, on the backswing, the friction with the playfield has more time to work on the ball and displaces it more.

 

The same effect applies to the change of the trajectory. Of course, with a very slowly moving ball (at a slope of .1), the change of trajectory is much more pronounced. At a realistic slope, in my experience, the effect is very small.

 

All of these effects also depend on the nudge force and the nudge time, so try playing around with those!

 

In fact we have to try this with zero friction to see if my theory is really true, in that case the ball should return completely.

 

Anyone up for an experiment? Take a pinball, place it on a flat surface (a desk will do, I guess, depending on the surface material) and nudge away. Does the ball return completely to where it was? My guess would be no, but it would be interesting to find out!

-----------------------------------------------

 

I tried using Physmod4 with CFTBL Melon/UW physmod table as well as the physmod WW and the ball jumps halfway across the table when I use the keyboard nudge, the test tables I mentioned earlier didn't act like this.

x and y gain are set to 15% in keys settings for physmod programs to reduce the analog nudge settings as needed, but I thought that was only for analog nudge. Is it possible the keyboard needs this setting lowered somehow?

 

Any one else tried the keyboard nudge with a real physmod table and had similar reaction?

Edited by RYSr, 13 May 2014 - 12:48 AM.

[unclewilly]

You would need to disable the nudge subroutine in the script as it will mess with vps routine as it was made to compensate for vp9s overpowered nudging

[Pinbotfan]

 

Here is not only a pro, but a champion. He is not sliding the machine because the flippers would not do the job. he is sliding it because nudging would not do the job either.

 

I agree though, that it would be pointless without a user defined variable. 96-100 sounds good. 0-100 would be good. anything with 100. It would be great if adjoining keys could do the slide save or if the key time was polled and it fell in. 

 

His tip pass video is also a good one. All hid demos are good if it is something you don't already know.

 

 

EDITED for a better link

Edited by Pinbotfan, 13 May 2014 - 06:02 AM.

[mukuste]

I actually tried the nudging with no friction, and still the ball doesn't return, so I realized that there's a bug in my nudging logic which causes this. After I fixed this, the ball returns much more closely to its original position/trajectory.

 

Also the needed nudge forces are different with this change, so I recommend not tweaking any tables for the new nudging until the next update.

[Slydog43]

this is GREAT news as I really think this is the last "big" thing that needs to be updated for VP to become "real", Thanks!

[RYSr]

I actually tried the nudging with no friction, and still the ball doesn't return, so I realized that there's a bug in my nudging logic which causes this. After I fixed this, the ball returns much more closely to its original position/trajectory.

 

Also the needed nudge forces are different with this change, so I recommend not tweaking any tables for the new nudging until the next update.

 

Mukuste,

 

That's good news, where as I do agree (as Noah stated), there should be some change in trajectory, however it seemed to be a bit excessive in the test table with this release.

 

Could you also provide a test version (physmod5a) with the new nudge routines for the analog devices included with the next update. Or add the code and make it selectable in the editor for the old or new analog version for testing?

 

I'm sure that others using analog accelerometer nudge devices would like to try it out and report back if it's the way to go in the future VP10 releases.

 

Rich

Edited by RYSr, 13 May 2014 - 04:34 PM.

[Pinbotfan]

I actually tried the nudging with no friction, and still the ball doesn't return, so I realized that there's a bug in my nudging logic which causes this. After I fixed this, the ball returns much more closely to its original position/trajectory.

 

Also the needed nudge forces are different with this change, so I recommend not tweaking any tables for the new nudging until the next update.

Great work. It is as vital as anything else pinball. Do you think you will be able to animate the table (optionally) during the nudge?

 

The flipper work is great as well, with the duel or dual powered solenoid. Like in this video

[mukuste]

 

I actually tried the nudging with no friction, and still the ball doesn't return, so I realized that there's a bug in my nudging logic which causes this. After I fixed this, the ball returns much more closely to its original position/trajectory.

 

Also the needed nudge forces are different with this change, so I recommend not tweaking any tables for the new nudging until the next update.

 

Mukuste,

 

That's good news, where as I do agree (as Noah stated), there should be some change in trajectory, however it seemed to be a bit excessive in the test table with this release.

 

Could you also provide a test version (physmod5a) with the new nudge routines for the analog devices included with the next update. Or add the code and make it selectable in the editor for the old or new analog version for testing?

 

I'm sure that others using analog accelerometer nudge devices would like to try it out and report back if it's the way to go in the future VP10 releases.

 

Rich

 

 

There are no changes to the analog nudging code so far as I don't have an analog nudging device as of yet.

[Noah Fentz]

 

I actually tried the nudging with no friction, and still the ball doesn't return, so I realized that there's a bug in my nudging logic which causes this. After I fixed this, the ball returns much more closely to its original position/trajectory.
 
Also the needed nudge forces are different with this change, so I recommend not tweaking any tables for the new nudging until the next update.

 
Mukuste,
 
That's good news, where as I do agree (as Noah stated), there should be some change in trajectory, however it seemed to be a bit excessive in the test table with this release.
 
Could you also provide a test version (physmod5a) with the new nudge routines for the analog devices included with the next update. Or add the code and make it selectable in the editor for the old or new analog version for testing?
 
I'm sure that others using analog accelerometer nudge devices would like to try it out and report back if it's the way to go in the future VP10 releases.
 
Rich
 

 
There are no changes to the analog nudging code so far as I don't have an analog nudging device as of yet.

Shoot me a PM with your shipping address, and we'll fix that.

[StevOz]

Sure the ball trajectory can change mid playfield via a nudge though the amount of change is going to be very much dependent on the velocity/speed ( inertia ) and spin of the ball. The higher it's velocity and the less it's spin the less it's trajectory will be effected by a nudge. Upon a nudge a fast moving ball will not change it trajectory by any significant amount, maybe as much as 1 degree at most, where as a slow spinning ball may have it's trajectory altered by a few degrees. The spin complicates this as it depends on which direction the ball is spinning and the direction the nudge is applied from, the nudge will actually alter the spin direction and spin speed slightly.

 

Physics 101...

 

http://en.wikipedia.org/wiki/Inertia

Edited by StevOz, 14 May 2014 - 01:23 AM.

[mukuste]

Sure the ball trajectory can change mid playfield via a nudge though the amount of change is going to be very much dependent on the velocity/speed ( inertia ) and spin of the ball. The higher it's velocity and the less it's spin the less it's trajectory will be effected by a nudge. Upon a nudge a fast moving ball will not change it trajectory by any significant amount, maybe as much as 1 degree at most, where as a slow spinning ball may have it's trajectory altered by a few degrees. The spin complicates this as it depends on which direction the ball is spinning and the direction the nudge is applied from, the nudge will actually alter the spin direction and spin speed slightly.

 

Physics 101...

 

http://en.wikipedia.org/wiki/Inertia

 

Yes, the new physics code takes all these factors into account. After the bugfix which I implemented and which will go out with the next release, I think you'll find the behavior to be quite realistic.

 

I actually tried the nudging with no friction, and still the ball doesn't return, so I realized that there's a bug in my nudging logic which causes this. After I fixed this, the ball returns much more closely to its original position/trajectory.

 

Also the needed nudge forces are different with this change, so I recommend not tweaking any tables for the new nudging until the next update.

Great work. It is as vital as anything else pinball. Do you think you will be able to animate the table (optionally) during the nudge?

 

The flipper work is great as well, with the duel or dual powered solenoid. Like in this video

 

 

The problem with animating the table is that many elements are still rendered statically. As VP10 is developed more, we can implement shaking either as a post-process effect or, once we have a completely dynamic camera, as a real movement of the table.

[lio]

...we should get these guys interested in pinball and have them take some supoer slow motion gameplay videos ;-)

http://www.youtube.c...r/theslowmoguys

[toxie]

As for lag: in the physmod, you should generally get away with setting the frame limiter/vsync field to 1 so that you get true vsync at 60 Hz. However, this might increase input lag a bit since the frame times are now longer, so to compensate, you could try changing the Max prerendered frames setting in the Video preferences to 1 if you have it at 2.

 

Just for the (dev-)record: I finally did some tests using NSight with the prerendered frames at various settings and vsync on/off (i wanted to do that for a long time, finally got around to do that now):

On my system here (GTX 580, Win7) prerendered frames at 1 and 2 both feature always roughly the same frame latency, from 3 on its getting worse, 0/off is also much worse.

This is for all kinds of vsync on/xHz/off (although with on the overall latency is increased (for 1&2 both only slightly(!!), for 3 upwards it always matches the vsync-rate (i.e. 16.666ms in my case)).

 

Quick summary for the users:

At least on my setup, prerendered frames set to 1 or 2 always behaves the same (and are the best setting), no matter if vsync is on/xHz/off.

If you want minimum possible lag, leave vsync at 0, prerendered frames at 1 or 2. Although note that this is most propably overkill and you could just set vsync to 1.