1002 replies to this topic

[mukuste]

BuckoBundy: I just tried your ball_through_pf.vpt table. In physmod2, I get the bug, in physmod3, everything seems fine. Was that the expected outcome?

[BuckoBundy]

Hmm. Seems physmod3 indeed fixed this particular bug. I made and posted that table when physmod2 was the latest version. Perhaps it gave some clue as to why, I guess. Sorry for not checking this.

 

Oh well. Another bug bites the dust

[xzotic]

Just a couple of observations - sorry not too specific as I'm short on time right now but feedback none the less...

 

The ball cradling issue where the ball infinitely jumps around I experienced in either Black Knight or Black Knight 2000. I was testing my magna save buttons at the time so it was one or the other. The issue happens when the ball is cradled by the left flipper.

 

I had a ball disappear in Fish Tables after a shot up the left ramp of the centre boat. It seemed like it had shot straight off the table but it 'seemed' that way because it was a fast shot. It may have 'disappeared' behind the table/dropped through. Sounds like it may be table specific in terms of that ramp setup. If anyone can confirm this same experience that would be good. I didn't over test myself and can do so but not right now.

 

STTNG has the ball stuck on the middle top wire ramp as the ball attempts to come down from the top of the table and pass under the end of the ramp. It just gets stuck. Sounds like I can just delete the end of the ramp and that should solve the issue.

 

Still loving the physics though and for the sake of a few issues its totally worth having some tables that are playable. I'm finding myself playing the same table over and over again. It's like I feel I have a chance now to better my score through skill instead of random luck with the flippers. It really has propelled pinball simulation to the next level well beyond anything else that's currently out there. Keep up the amazing work.

[BuckoBundy]

STTNG uses a bigger ball so it collides with the ramp it needs to pass under.

Either change the line "Const BallSize = 54" to 52 or set the Top Height of Ramp946 to 54.

[unclewilly]

I guess I'm late to testing this.

The flippers are a lot better as far as accuracy ...

The thing I'm noticing at least on the one table I'm starting to mod mb update.

It seems to me that when I have a kick out hole. El. The center kick out hole. I have a z value applied to the kicker so the ball has some air when it comes out of the hole and then hits the table. I see a very obvious slow down on the ball once it hits the table. Also noticing a very obvious slowdown when the ball goes up any of the ramps. It doesn't fly through the ramps like on a real table.

Maybe this has to do with the friction.

All my ramps currently have a friction of .0015.
Also on the table I have the playfield as a surface 55 units above the actual playfield so the ball will really fall into a kicker hole or the center eject. If you'd like I can provide the update table to look at.

Table slope is set in the script.

[ckovanda]

anyone have any idea how to fix Melon's Getaway remake supercharger ramp?  I can't get the ball to go up the ramp further than and inch or so.  it jhust slows down and bounces back out.  I don't really understand how to edit the ramps very well, I tried lowering the next portion of the ramp a bit, which all owed the ball to go up about 5 inches or so, but then the ball would fall through the ramp and back out on to the table.

[BuckoBundy]

Maybe somebody should start a separate thread for modding tables to work with the physmod versions?

Anyway..

 

anyone have any idea how to fix Melon's Getaway remake supercharger ramp?  I can't get the ball to go up the ramp further than and inch or so.  it jhust slows down and bounces back out.  I don't really understand how to edit the ramps very well, I tried lowering the next portion of the ramp a bit, which all owed the ball to go up about 5 inches or so, but then the ball would fall through the ramp and back out on to the table.

 

Change ramp368: Bottom Height = 0

Then shorten Ramp770 a bit like in this picture:

http://monosnap.com/...fzPPivXZyZroaD#

[Gemini000]

So I have a question for the devs: You want some help getting the nudging physics fixed up? ;)

 

I recently started getting back into pinball after an exceedingly long time of not playing, and as such, I've been playing a bunch of VP8 and VP9 table recreations, particularly machines I'll be playing in real life as competitions come up in the league I joined.

 

However, I was very confused about the discrepancies between the VP8 and VP9 nudging mechanics once I figured out they were behaving very differently. I made a post elsewhere on the forums here (possibly a little rude of a post as I was really tired and flabbergasted when I found out that VP9 was the inaccurate one and that it has spent years not being fixed) and I also took a look through the VP9 codebase up on SourceForge to see how complicated the nudging mechanics were. (Answer: Not very.)

 

I then searched the house for some small round objects and a nice, solid, flat surface I could use for testing some physics principles out (ended up being marbles and a coffee table) and noticed the key flaw between the physics currently in place for nudging in VP9 and the way it should work: Presently in VP9, when you nudge a table, the ball is being accelerated. With the keyboard, this results in a permanent change of trajectory. With a virtual cabinet or joystick axis, the rebound following counters out the initial acceleration factor, which gets you the proper end result if the ball doesn't hit anything, but not in the right way.

 

The way it's supposed to work is that it's not the ball gaining acceleration from the nudge, rather it's the table sliding beneath the ball! I imagine the ball does gain some acceleration in the process, but that acceleration matches the motion of the table beneath it because as the table slows down and prepares to rebound, so does the ball. With an acceleration-based approach, this doesn't happen because at the apex of the nudge, the ball is STILL accelerated, where in real life, it would simply be shifted from its initial position since the acceleration of the initial strike would be cancelled out BEFORE the rebound.

 

The other consideration is that during a nudge, the entire table acts as a moving object upon contact with the ball, imparting the full force of the impact should a playfield wall or object strike the ball in the process.

 

Given the present code base, these are the things which need to happen for nudging to be fixed in VP:

 

1. Instead of altering acceleration, the analog tilt axis values should adjust ball POSITION. In fact, the simplest thing to do would be for each ball's present position to be calculated as its desired position + tilt axises.

 

2. The difference in previous and present axis positions needs to be tracked for each analog axis for every physics frame so that when the ball makes contact with a part of the playfield, if there's been any change in table position for that frame it can be properly applied to the ball as the table itself having velocity upon impact.

 

3. Rather than maintaining two different nudging systems for analog devices (cabinet/joystick) and digital devices (keyboard), the keyboard system should simply feign an analog nudge by keeping its own axis values and adding them to the joystick axises. When a keyboard nudge is induced it simply swings its own virtual axis in one direction via an instant burst of acceleration, then it rebounds and rapidly damps that motion down to 0, just like with an actual cabinet nudge. The end result would be a ball that's shifted very slightly off-centre from where it was with no extra acceleration, unless it strikes something during the nudge, in which case it would deflect off from the #2 changes above.

 

If you'd like the extra help, I'd be willing to pitch in and code this myself, however, I'm extremely busy with my own projects and have never worked on an open source project before. As such, I have no experience with the SourceForge system and it would take me a day or two just getting learned up enough to even attempt to commit a change to the VP source, and that's once I can find the time. If the ideas I've presented above are satisfactory enough, then I'll simply leave you guys to it and hope to see proper nudging support in newer versions of VP soon. :B

 

...until then though, since I'm gonna be playing on real machines soon, I'm gonna stick with VP8 for learning basic strategies for the time being. :P

Edited by Gemini000, 29 April 2014 - 05:19 PM.

[lio]

Finally I've had the chance to spend a little more time with the new physics :-)

It's immediately apparent that a lot more more goes on there that influences the ball behavior - nice!

 

So far I get the impression that the variance in elasticity depending on hit speed is too strong - especially noticeable on the flipper rubbers.

A slow ball that bounces into the flippers (especially when in their "end of stroke position") will often receive a real boost in energy and bounce off way more than expected - almost as if it had hit some sort of slingshot.

 

On my current test table I like these flipper settings:

Mass: 2

Strength: 3000

Elasticity: 0,4

Friction: 0,85

Return Strength: 0,2

Coil Ramp Up: 5

 

(I'm using my 10+ years old recreation of BK2K because I spent a lot of time getting the measurements correct on all parts so I know it's as accurate as it can be in that department)

 

Also gravity seems to pull down the ball a bit too strong in my opinion - to simulate a table that should in reality be at 6,5° I use a table slope of 5,5° and a gravity constant of 0,9.

 

Playfield friction also seems very strong so I ended up putting it at 0,01.

 

All of these current values have lots of room for improvement but it plays fairly close to what I'd expect on that particular table.

Edited by lio, 29 April 2014 - 06:51 PM.

[mukuste]

So I have a question for the devs: You want some help getting the nudging physics fixed up?

 

I recently started getting back into pinball after an exceedingly long time of not playing, and as such, I've been playing a bunch of VP8 and VP9 table recreations, particularly machines I'll be playing in real life as competitions come up in the league I joined.

 

However, I was very confused about the discrepancies between the VP8 and VP9 nudging mechanics once I figured out they were behaving very differently. I made a post elsewhere on the forums here (possibly a little rude of a post as I was really tired and flabbergasted when I found out that VP9 was the inaccurate one and that it has spent years not being fixed) and I also took a look through the VP9 codebase up on SourceForge to see how complicated the nudging mechanics were. (Answer: Not very.)

 

I then searched the house for some small round objects and a nice, solid, flat surface I could use for testing some physics principles out (ended up being marbles and a coffee table) and noticed the key flaw between the physics currently in place for nudging in VP9 and the way it should work: Presently in VP9, when you nudge a table, the ball is being accelerated. With the keyboard, this results in a permanent change of trajectory. With a virtual cabinet or joystick axis, the rebound following counters out the initial acceleration factor, which gets you the proper end result if the ball doesn't hit anything, but not in the right way.

 

The way it's supposed to work is that it's not the ball gaining acceleration from the nudge, rather it's the table sliding beneath the ball! I imagine the ball does gain some acceleration in the process, but that acceleration matches the motion of the table beneath it because as the table slows down and prepares to rebound, so does the ball. With an acceleration-based approach, this doesn't happen because at the apex of the nudge, the ball is STILL accelerated, where in real life, it would simply be shifted from its initial position since the acceleration of the initial strike would be cancelled out BEFORE the rebound.

 

The other consideration is that during a nudge, the entire table acts as a moving object upon contact with the ball, imparting the full force of the impact should a playfield wall or object strike the ball in the process.

 

Given the present code base, these are the things which need to happen for nudging to be fixed in VP:

 

1. Instead of altering acceleration, the analog tilt axis values should adjust ball POSITION. In fact, the simplest thing to do would be for each ball's present position to be calculated as its desired position + tilt axises.

 

2. The difference in previous and present axis positions needs to be tracked for each analog axis for every physics frame so that when the ball makes contact with a part of the playfield, if there's been any change in table position for that frame it can be properly applied to the ball as the table itself having velocity upon impact.

 

3. Rather than maintaining two different nudging systems for analog devices (cabinet/joystick) and digital devices (keyboard), the keyboard system should simply feign an analog nudge by keeping its own axis values and adding them to the joystick axises. When a keyboard nudge is induced it simply swings its own virtual axis in one direction via an instant burst of acceleration, then it rebounds and rapidly damps that motion down to 0, just like with an actual cabinet nudge. The end result would be a ball that's shifted very slightly off-centre from where it was with no extra acceleration, unless it strikes something during the nudge, in which case it would deflect off from the #2 changes above.

 

If you'd like the extra help, I'd be willing to pitch in and code this myself, however, I'm extremely busy with my own projects and have never worked on an open source project before. As such, I have no experience with the SourceForge system and it would take me a day or two just getting learned up enough to even attempt to commit a change to the VP source, and that's once I can find the time. If the ideas I've presented above are satisfactory enough, then I'll simply leave you guys to it and hope to see proper nudging support in newer versions of VP soon. :B

 

...until then though, since I'm gonna be playing on real machines soon, I'm gonna stick with VP8 for learning basic strategies for the time being.

 

I agree with your assessment that keyboard nudging is way off, but I disagree with your proposal how to fix it.

 

Nothing should ever directly affect position, it's completely unphysical and will not properly update the ball velocity for collisions during nudging.

 

Let's assume that a nudge, from the player point of view, consists of a short impulse transmitted to the table, so that the table picks up some lateral velocity. The table will then act as a stiff spring-damper system, vibrate shortly and come to a rest again.

 

So, we don't need to model a displacement of the table relative to the ball, we need to model a velocity of the table relative to the ball, which naturally leads to the proper displacements. This seems a bit tricky at first because the table was never intended to move in VP, until you realize that the table moving relative to the ball is the same as the ball moving relative to the table -- so we can simply add the reversed table velocity to the ball and everything will work out fine.

 

That's all that needs to be done -- collisions with table objects will then happen completely naturally due to the velocity of the ball, and also the friction of the playfield will have a (minor) effect on the trajectory of the ball, which mostly gets corrected as soon as the table swings back to its original position. This is very easy to implement and should be quite realistic.

 

I am shocked though that you consider VP8 physics more realistic than this update, nudging notwithstanding.

[mukuste]

Finally I've had the chance to spend a little more time with the new physics :-)

It's immediately apparent that a lot more more goes on there that influences the ball behavior - nice!

 

So far I get the impression that the variance in elasticity depending on hit speed is too strong - especially noticeable on the flipper rubbers.

A slow ball that bounces into the flippers (especially when in their "end of stroke position") will often receive a real boost in energy and bounce off way more than expected - almost as if it had hit some sort of slingshot.

 

On my current test table I like these flipper settings:

Mass: 2

Strength: 3000

Elasticity: 0,4

Friction: 0,85

Return Strength: 0,2

Coil Ramp Up: 5

 

(I'm using my 10+ years old recreation of BK2K because I spent a lot of time getting the measurements correct on all parts so I know it's as accurate as it can be in that department)

 

Also gravity seems to pull down the ball a bit too strong in my opinion - to simulate a table that should in reality be at 6,5° I use a table slope of 5,5° and a gravity constant of 0,9.

 

Playfield friction also seems very strong so I ended up putting it at 0,01.

 

All of these current values have lots of room for improvement but it plays fairly close to what I'd expect on that particular table.

 

I think what you interpret as too high elasticity is probably another effect -- it's the ball pushing down the flipper slightly on a hit, which then accelerates upwards and gives the ball a kick back up. This should only happen with moderately fast moving balls though, not with very slow ones. There are still options to improve the flipper response in such situations and I want to run some simulations at some point; the physics are surprisingly complicated. Elasticity 0.4 sounds very low though, can't you basically catch the ball simply by holding up the flipper with that setting?

 

The reason you find gravity too strong is precisely because you set the friction so low. 0.01 is way too low, at that setting a ball placed on the playfield will slide at first before it begins to roll (you can easily test that if you press F11 to see the ball spin and then throw in a ball from the debug menu). I don't think this is realistic, in my opinion a ball placed on the playfield should enter a natural roll immediately.

 

A sliding ball will always be faster than a rolling ball, and that's probably why you find the gravity too strong. The parameters in the new physics code are chosen according to the real world and I believe that, with gravity at 1 and reasonable friction, a rolling ball will have the proper acceleration it would have in reality. The only factor not simulated is rolling friction, which I expect to be very low on a well-maintained playfield. I'd love, however, to hear numbers from actual measurements, e.g., how long does the ball need to roll 1 m on a real playfield with a slope of 6°? If anyone wants to make this kind of experiment I think we could really get an idea of how close we are.

 

There is however another aspect which is not captured in the situation of a rolling ball -- static and dynamic friction may be quite different in reality, and this is not modeled currently. So this might be the reason why you set the friction so low in the first place. Which effects exactly do you mean when you say you find the friction very strong?

[ClarkKent]

STTNG uses a bigger ball so it collides with the ramp it needs to pass under.

Either change the line "Const BallSize = 54" to 52 or set the Top Height of Ramp946 to 54.

Do you also have a solution for the White Water plunger ramp? Could need some help here...

[mukuste]

 

STTNG uses a bigger ball so it collides with the ramp it needs to pass under.

Either change the line "Const BallSize = 54" to 52 or set the Top Height of Ramp946 to 54.

Do you also have a solution for the White Water plunger ramp? Could need some help here...

 

 

I think for me all that was needed was to select Ramp4 and increase the Upper Height to 250. This way the ball (diameter 50) fits between the UpperPf (height 196) and the ramp.

Edited by mukuste, 29 April 2014 - 09:07 PM.

[BigBoss]

STTNG uses a bigger ball so it collides with the ramp it needs to pass under.

Either change the line "Const BallSize = 54" to 52 or set the Top Height of Ramp946 to 54.

Do you also have a solution for the White Water plunger ramp? Could need some help here...

i tested my white water and it never plunged down the middle. I was always able to hit the ball without a nudge. Is very much like my real white water.

As for the nudging discussion, part of the nudging in accuracy is our ability to sense the nudge properly. Even the accelerometer controllers are not very accurate. The sidewinder freestyle is about the best I've tested so far. But the problem is the joystick axis is limited but a real jolt can actually be much more. Then you have to add dead zone or the ball moves sort of crazily. As it stands now, nudging isn't accurate but it gets the job done. I was going to look at this myself now that I got my cabinet back in house.

[ClarkKent]

 

 

STTNG uses a bigger ball so it collides with the ramp it needs to pass under.

Either change the line "Const BallSize = 54" to 52 or set the Top Height of Ramp946 to 54.

Do you also have a solution for the White Water plunger ramp? Could need some help here...

 

 

I think for me all that was needed was to select Ramp4 and increase the Upper Height to 250. This way the ball (diameter 50) fits between the UpperPf (height 196) and the ramp.

 

OK. It seems that I didn't increase the height enough, I set it to 246 and thought this should be enough. Thanx for the fix!

[Gemini000]

I am shocked though that you consider VP8 physics more realistic than this update, nudging notwithstanding.

 

I never said that. ;D

 

I agree that the flipper mechanics and most everything is quite a bit more accurate in VP9 than VP8... but nudging has always been my primary deficiency in real play, so learning when and how to incorporate nudges without immediate access to actual machines requires that I be playing a simulation with good nudging mechanics, and to that end, I need to stick with VP8 for now over VP9. :P

 

You definitely have a better idea of how the nudging physics are supposed to work than I do though, given that I understood what you said and it makes sense and I can see how it all fits in with my own observations... as though my own observations were incomplete and more generalized.

 

In any case, I'm looking forward to better nudging in the future! :)

[Pinbotfan]

This seems a bit tricky at first because the table was never intended to move in VP,

 

Actually the table was always intended to move in VP. The backdrop moved as well, which was kind of funky, but the ball did not. 

 

 

until you realize that the table moving relative to the ball is the same as the ball moving relative to the table -- 

 If you are the ball or the table, that may be true, but as the observer, the player, there is a big difference between the table moving or the ball moving. As big a difference as nudging the table, or taking the glass off, reaching in and nudging the ball.

 

 

so we can simply add the reversed table velocity to the ball and everything will work out fine.

 

Agreed. Ball or table. Which ever you decide are the physics you want to model. nudging the ball or the table.

[mukuste]

Pinbotfan: what you are talking about is only the visual effect of the table shaking, which has absolutely nothing to do with the physics. In the DX7 versions, this was simply implemented as offsetting the whole screen by a few pixels (which is why the backdrop was moving as well). Believe me, there is absolutely no provision in the source code for shaking the table as far as the physics are concerned.

[The Loafer]

Real world has gotten pretty busy the past couple of days but I hope I can continue some tests tomorrow. For now, some questions.

Disclaimer: All following questions are based partially on my own ignorance and none are meant to offend, so please keep this in mind . A lot more tests need to be done at my end and part of my ignorance is I am uncertain of the relationships between global physics and physics saved within a table.

- as mentioned by Lio, this is something I have spoken to another member about several days ago, as for me as well, the ball seems to go down a little too fast, like its picking too much speed. My first thought since no one had mentioned it yet is that perhaps something is affecting the physics on my cab. So question here: is it possible my nudging board is affecting the physics?

- if I download a table that has physics saved, is there any previous physics setup at my end that can affect this? Ie: I had tried importing physics from white water when I tried that abracadabra conversion. Last two days have been murder with my return to work from sick leave so I am I sure but do I need to enable that option that I think says "import global physics" when I try a downloaded table? Now let's say I am trying another table that has different physics saved within it, do any previous settings affect this? This thought was brought to mind because of how several people have said "full plunge on white water goes straight down the middle" ... Which happens to me, while other people have said this does not happen to them. This to me doesn't make sense, unless the new vp physics are a little like the FP physics, not meant in accuracy but rather that the pc performance can affect the vp physics accuracy from pc to pc (yes for those who don't know, this is true for FP and why some have better physics with FP on one pc compared to another). For the record, my pincab pc is an i7 running at 3.5-3.9ghz with a nvidia 570, so I have power to spare.

- apologies if this was discussed, I am old and memory is bad but is wax taken into affect with the new physics and if not, will it? The reason for asking is obvious: play a game on my firepower, even if set to the same level as one owned by an old friend will play TOTALLY different depending on the wax used and how much. Now, not suggesting this needs to be done but this does need to be factored in when comparing how the physics are accurate for the majority of people out there. Ie: my own present observation of the ball seemingly being too fast could be more of a result of not playing enough real pinball on optimally set up machines. That's another thing I was thinking of, a lot of the videos you have seen are from PAPA vids right Mukuste? Those pins are usually set up for tournament conditions and therefore are set up as "hard". This is perfectly ok, settings are meant to be adjusted. but this may explain why for some, assuming no "global settings" issues are involved, that it may or may not play as they expect, as so many of us are used to playing on beat up pieces of crap.

Tomorrow night I should be able to do more testing so I will be a little less ignorant, but thought that the questions asked in this post can provide good conversation for now.

Appreciate again what you have done for us, along with all the other recent additions by you and the rest of the vp dev team.

Rob

[Slydog43]

I love the new physics so much, but my limited ability to mod tables is stopping me from getting Laser War 1.0.3 FS from working right.  The ball gets plunged way too hard.  I have moved the impulse plunger off to the side and added a new modern flipper, but the ball also plunges waaaaaay to fast.  Maybe friction of the ramps?  Any1 have any ideas.  (one problem of the new physics is that its hard to play the old VP9.2.1 now after seeing how much better it can be.   Many table edits are on the horizon.  Thanks mukuste for all your incredible work!