1002 replies to this topic

[mpad]

Hey mukuste, thanks for all you did. Finally had the time to check out v9.9.0 and physmod. What a difference!
Feels absolutely realistic! Never was a friend of the old physics in vp - (being an old pro pinball player). Now vp really seems up to date and even better considering all you did there and plan to do. Great.

Only tried the recommended tables bop and cftbl. Got repeatedly stuck on some occasions, but overall it was fantastic.

[mukuste]

I hope your move went well.
Can't wait to test out the new nudging.

Is the default table set up with testable parameters for the new nudging.

Really appreciate the work you've done here. Looking forward to your contributions.
It amazes me how far this has come in such a short period of time

 

Yes, the default table will work. In fact, any table which calls the Nudge function should still work, although the force and maybe the Nudge Time may need to be tweaked.

 

 

I agree with UW VP has never played so good as it does now. Thanks for  all your work, mukuste!

(and don't forget the wall target error, the ball only creates a hit event the first time the ball hits the target, the successive hits are ignored )

 

Ah yes, sorry, I knew I forgot something! This will still be fixed, thanks for the reminder.

 

 

thanks for another physics mod, really making VP play so realistic its just amazing.  Are the keyboard nudging changes going to change the analog nudging at all? in future?  This is something that I think needs to be perfected.

 

everyone should call their mom today and say thanks

 

So right now I don't have a nudge device, but thanks to Slashbot I should soon receive a U-HID G. What's the state of analog nudging in VP? I had the impression people are mostly happy with it, except that calibration can be tricky (which is a hardware issue)?

 

I would definitely like to have a unified code path for nudging instead of the two or three disparate, cobbled together solutions which exist currently. Just don't want to break anything which works well.

 

 

Hey mukuste, thanks for all you did. Finally had the time to check out v9.9.0 and physmod. What a difference!
Feels absolutely realistic! Never was a friend of the old physics in vp - (being an old pro pinball player). Now vp really seems up to date and even better considering all you did there and plan to do. Great.

Only tried the recommended tables bop and cftbl. Got repeatedly stuck on some occasions, but overall it was fantastic.

 

Yes, unfortunately with the latest changes to ramp and wall collisions, again some tables are broken. I know it's annoying, but in the long run I think it's worth fixing those bugs and having a consistent and realistic collision model.

[Slydog43]

if noah ever gets the new plunger in stock, I will donate one to you mukuste if you want, seems like the least I can do.  (problem is I have been waiting for 1 for 3 months

[Noah Fentz]

if noah ever gets the new plunger in stock, I will donate one to you mukuste if you want, seems like the least I can do.  (problem is I have been waiting for 1 for 3 months

It's not an 'if', it's a 'when', and when is this week!

I'm happy to send him one for dev work. In fact, I hear he plays mostly desktop, and I have a slightly beat up PBW controller he can have, too.

[BuckoBundy]

Found a bug with Physmod4. When a ball collides with a thin wall at a certain angle, it goes right through. Ends up under the playfield in this example table even:

https://docs.google....Y1VlbXpMRDV0MXM

 

The left wall in the test table is at a 1 degree angle and there things work as expected. The other wall... not so much.

[mukuste]

 

if noah ever gets the new plunger in stock, I will donate one to you mukuste if you want, seems like the least I can do.  (problem is I have been waiting for 1 for 3 months

It's not an 'if', it's a 'when', and when is this week!

I'm happy to send him one for dev work. In fact, I hear he plays mostly desktop, and I have a slightly beat up PBW controller he can have, too.

 

That would be great. The plunger is meant for cab use, I guess, so I assume the PBW is what I'd want as a desktop user?

 

 

Found a bug with Physmod4. When a ball collides with a thin wall at a certain angle, it goes right through. Ends up under the playfield in this example table even:

https://docs.google....Y1VlbXpMRDV0MXM

 

The left wall in the test table is at a 1 degree angle and there things work as expected. The other wall... not so much.

 

Thanks! Will look into it.

[BuckoBundy]

Another bug. A ball that is on the playfield can pass under a wall that has a bottom height of 50, but it can not when it is on another surface and the space is still at 50. I don't think explaining it made much sense . So another test table:

https://docs.google....clhZc3VNUkk4MEk

[mukuste]

Another bug. A ball that is on the playfield can pass under a wall that has a bottom height of 50, but it can not when it is on another surface and the space is still at 50. I don't think explaining it made much sense . So another test table:

https://docs.google....clhZc3VNUkk4MEk

 

I fixed the first one, but I'm not sure this one qualifies as a bug. As soon as you are at exactly 50 units difference, you're in an area where rounding error comes into play and basically everything can happen. If you increase the clearance to 51 units, they behave the same again. Did you run into this problem on an actual table? I have no idea how you find these so fast

[Noah Fentz]

 

if noah ever gets the new plunger in stock, I will donate one to you mukuste if you want, seems like the least I can do.  (problem is I have been waiting for 1 for 3 months

It's not an 'if', it's a 'when', and when is this week!

I'm happy to send him one for dev work. In fact, I hear he plays mostly desktop, and I have a slightly beat up PBW controller he can have, too.

 
That would be great. The plunger is meant for cab use, I guess, so I assume the PBW is what I'd want as a desktop user?

It's a desktop controller with a VirtuaPin Plunger Kit installed.

[Pinbotfan]

Flipper.CurrentAngle =  

This works for me in all versions including VP9.9 but not in the physics overhauls. It's attached to a gate made out of walls that follows an invisible flipper.

[BuckoBundy]

 

Another bug. A ball that is on the playfield can pass under a wall that has a bottom height of 50, but it can not when it is on another surface and the space is still at 50. I don't think explaining it made much sense . So another test table:

https://docs.google....clhZc3VNUkk4MEk

 

I fixed the first one, but I'm not sure this one qualifies as a bug. As soon as you are at exactly 50 units difference, you're in an area where rounding error comes into play and basically everything can happen. If you increase the clearance to 51 units, they behave the same again. Did you run into this problem on an actual table? I have no idea how you find these so fast

 

Agreed that this more qualifies as 'expected behaviour' in a way. But previous versions allow the ball to move freely in both the scenarios on that test table. One would at least expect the ball to behave the same whenever the distance it has to pass under is at 50?

And I found both issues while working on an original table I am making. Just for fun though, I won't be releasing it. But that table has a wall as playfield so that the ball can actually fall into holes. It is a good way to learn.. and test as it turns out

 

Thanks for all your efforts!

[mukuste]

It's a desktop controller with a VirtuaPin Plunger Kit installed.

 

 

Right, that would be the most convenient for testing then!

 

 

Flipper.CurrentAngle =  

This works for me in all versions including VP9.9 but not in the physics overhauls. It's attached to a gate made out of walls that follows an invisible flipper.

 

I'm not sure what you mean, it's still possible to query the flipper angle. I'm attaching a test table which shows that:  FlipperCurrentAngle.vpt   128KB   8 downloads

 

 

 

 

Another bug. A ball that is on the playfield can pass under a wall that has a bottom height of 50, but it can not when it is on another surface and the space is still at 50. I don't think explaining it made much sense . So another test table:

https://docs.google....clhZc3VNUkk4MEk

 

I fixed the first one, but I'm not sure this one qualifies as a bug. As soon as you are at exactly 50 units difference, you're in an area where rounding error comes into play and basically everything can happen. If you increase the clearance to 51 units, they behave the same again. Did you run into this problem on an actual table? I have no idea how you find these so fast

 

Agreed that this more qualifies as 'expected behaviour' in a way. But previous versions allow the ball to move freely in both the scenarios on that test table. One would at least expect the ball to behave the same whenever the distance it has to pass under is at 50?

And I found both issues while working on an original table I am making. Just for fun though, I won't be releasing it. But that table has a wall as playfield so that the ball can actually fall into holes. It is a good way to learn.. and test as it turns out

 

Thanks for all your efforts!

 

My point was that at 50 distance, even the tiniest rounding error (which you always have to allow for) will put you at 49.99999 or something like this, at which point the ball won't mathematically pass anymore. Maybe I can still make it more consistent between the two cases, but in general it's not a good idea to rely on this behavior.

 

By the way the reason this used to work is that the lower edges of walls wouldn't collide with the ball at all. In physmod3 and all previous VP versions, you could easily set the clearance to 40 and the ball would still pass! These are the sorts of bugs I'm fixing all the time.

Edited by mukuste, 12 May 2014 - 01:00 AM.

[BigBoss]

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

[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

Attached Files

•  z Accelerometer Level Test FS.vpt   88KB   10 downloads

Edited by RYSr, 12 May 2014 - 02:02 AM.

[Pinbotfan]

Flipper.CurrentAngle =  

This works for me in all versions including VP9.9 but not in the physics overhauls. It's attached to a gate made out of walls that follows an invisible flipper.

 

I'm not sure what you mean, it's still possible to query the flipper angle. I'm attaching a test table which shows that:   FlipperCurrentAngle.vpt   128KB   3 downloads

 

 

Thank you.  I see the problem. I'm getting floating point to 4 places. The fix is to round up or down (it would take both.rounding up for reading down and rounding down to read the up position. all tweens are floating point as well. So you still can ask where it is, but before you could ask if it was at X.

 

So the fix would actually be to ask it if it is within a range or >

 

The break is worth it if the floating point is used. Maybe the program should give us  something like IsStart and isEnd since we can now not rotate it to 160  and use if currentangle =160. Not that >159 isn't good enough for me.

 

Thanks for the work you continue to put into this.

[mukuste]

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!

 

 

 

Flipper.CurrentAngle =  

This works for me in all versions including VP9.9 but not in the physics overhauls. It's attached to a gate made out of walls that follows an invisible flipper.

 

I'm not sure what you mean, it's still possible to query the flipper angle. I'm attaching a test table which shows that:   FlipperCurrentAngle.vpt   128KB   3 downloads

 

 

Thank you.  I see the problem. I'm getting floating point to 4 places. The fix is to round up or down (it would take both.rounding up for reading down and rounding down to read the up position. all tweens are floating point as well. So you still can ask where it is, but before you could ask if it was at X.

 

So the fix would actually be to ask it if it is within a range or >

 

The break is worth it if the floating point is used. Maybe the program should give us  something like IsStart and isEnd since we can now not rotate it to 160  and use if currentangle =160. Not that >159 isn't good enough for me.

 

Thanks for the work you continue to put into this.

 

 

Ah ok, I see now what you are trying to do. The new flipper model is much more sophisticated; in VP9, the flipper would move to its end position and just stop there. With the new physics, the flipper actually bounces off the end of its stroke a bit, like a real flipper does. So if you could check for the exact end angle, you'd actually get a sequence of on-off-on-off a few times as the flipper bounces and then comes to rest. That's probably not what you want.

 

So checking for >159 is an easy workaround that probably works fine. I can however also provide the Start and End flags that you suggested which would only be true if the flipper is at the desired position AND not moving. These are probably closer to what you want.

Edited by mukuste, 12 May 2014 - 08:19 AM.

[Pinball999]

 

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.

 

 

Hi there,

 

Having the possibility to change (increase) the ball size was a great addition in VP9.

Will this also be available in VP10?

 

Cheers.

[mukuste]

Hi there,

 

Having the possibility to change (increase) the ball size was a great addition in VP9.

Will this also be available in VP10?

 

Cheers.

 

 

I think this is done via the CreateSizedBall method of the kicker? That's still available. However, almost all real pinballs have a diameter of 1 1/16", and in order to keep the physics consistent, it's good to stick relatively close to the standard VP measurement of 50 units for the ball diameter.

 

What will also be adjustable is the ball mass -- this should be great for new TZ recreations since the powerball weighs only about 3/4ths of a standard ball. The new physics engine can take this into account.

[Pinball999]

 

Hi there,

 

Having the possibility to change (increase) the ball size was a great addition in VP9.

Will this also be available in VP10?

 

Cheers.

 

 

I think this is done via the CreateSizedBall method of the kicker? That's still available. However, almost all real pinballs have a diameter of 1 1/16", and in order to keep the physics consistent, it's good to stick relatively close to the standard VP measurement of 50 units for the ball diameter.

 

What will also be adjustable is the ball mass -- this should be great for new TZ recreations since the powerball weighs only about 3/4ths of a standard ball. The new physics engine can take this into account.

 

 

Great news for the ball mass!

 

For the size, I'm not familiar with the CreateSizedBall method. I was just using Const BallSize to adjust the ball for tables where it looked too small.

I agree that it's better to stick to 50, but it is sometimes necessary to adjust it a bit on some tables.

 

Possibles reasons for the smaller ball could be:

-Real table size was not know by the author during the table creation. In the end, the ball size do not have the correct proportion.

-POV and layback changes done by the player, making the table (black borders) and therefore the ball look smaller.

 

If I remember correclty, it was discussed to propose default table sizes depending on the manufacters or era when creating a new table. If this is considered for VP10, then the first possible reason would not be a problem anymore.

[mukuste]

I guess the vpm routines in the core.vbs read that BallSize constant, VP itself doesn't know about it, but it should have the same effect.

 

Yes, there's a stickied thread right in this forum with table dimensions, so I hope that all new tables will be sized appropriately. Anyway, changing the ball size by a few units up or down shouldn't be a big deal, at worst the gravity constant has to be tweaked a bit to reflect the changed scale.