76 replies to this topic

[mjr]

Okay, looks like the physmod5 merge will be fairly easy - the plunger code in the pm5 snapshot I have is almost unchanged from the base 9.9.1 code.

 

But before I get going on that, I want to make sure I have the latest physmod5 to base it on, and I can't remember where I got that code in the first place.  Is there a public repos out there with pm5 somewhere?  If so I can't find it.  If anyone has a pointer, I'd appreciate it. 

[Trinity]

http://www.vpforums....=32#entry266075

 

Is this what you need?

[Slydog43]

wow, mjr can't wait to try it out.  This is what makes VP and opensource stuff so awesome.  These changes have turned VP into such an incredible project.  Thanks VP team and all other contributers

[sliderpoint]

Looking good!.  I just tested on the default table.  Is there a reason the length of the rod and springs don't match the animation?  Meaning when the plunger is pulled back, the spring gets to the point that it's fully compressed and then the whole object keeps moving back further.  I would think that the end of stroke would be when the spring is fully compressed.

 

-Mike

[CaptainNeo]

i'm going to give this a try.  Maybe it will fix my crashing issue as well.  Since i'm having problems with VP right now in general.

[mjr]

Looking good!.  I just tested on the default table.  Is there a reason the length of the rod and springs don't match the animation?  Meaning when the plunger is pulled back, the spring gets to the point that it's fully compressed and then the whole object keeps moving back further.  I would think that the end of stroke would be when the spring is fully compressed.

 

Yeah, I should probably fix that up a bit, although it's a bit tricky to do.  It's an artifact of the way the Modern plunger was set up - I followed the same calculations to keep the meanings of the properties identical.  The Stroke Length setting is the length of the on-screen drawing area and also the distance the tip travels end-to-end.  What really should be happening is that everything should disappear as it goes behind the starting line, but only the rod disappears.  The thing is that the rod doesn't really disappear; it just gets drawn at 0 length.  The tip and spring and ring continue to be shown at full size because just reducing their lengths would change their shape (which isn't the case with the rod because it's a straight cylinder).  Chopping the ends off the spring and ring should be easy enough, but the tip might take a little figuring out.

 

I don't think this will be much of a practical problem on a real table, because the plunger is usually only partially visible through the little window in the apron.  The part where it goes wonky at the starting line can just be hidden behind the apron.  But it would be nice to fix it even so.

http://www.vpforums....=32#entry266075

 

Is this what you need?

 

Thanks - I did find that, but the zip linked there is the executable only.  There's a link to a git, but it's not clear to me exactly what's in there - the git is titled "Fork of Visual Pinball containing the DirectX 9 port and the physics overhaul", and it was last updated in May 2014.  Is that in fact the most recent physmod5 source?  (Assuming there's only one physmod5 out there.  It's hard to keep track of all of the modified versions.  I know I'm just making the problem worse myself. )

Edited by mjr, 30 March 2015 - 05:11 AM.

[ClarkKent]

 

http://www.vpforums....=32#entry266075

 

Is this what you need?

 

Thanks - I did find that, but the zip linked there is the executable only.  There's a link to a git, but it's not clear to me exactly what's in there - the git is titled "Fork of Visual Pinball containing the DirectX 9 port and the physics overhaul", and it was last updated in May 2014.  Is that in fact the most recent physmod5 source?  (Assuming there's only one physmod5 out there.  It's hard to keep track of all of the modified versions.  I know I'm just making the problem worse myself. )

 

As the last version of PM was on about 18th may this could be it! If there is nothing else, no version later than may, just use it and we will try it!

[mjr]

A couple questions..

Why not just add the custom type option, why would one want to use the flat type, what's the difference, benefits of each?

 

Good question.  We might even end up with a consensus that we don't need both after people have had a chance to use this more, but right now I think there are reasons to keep both.

 

My initial plan was just to implement the flat type.  Most of the scripted plunger schemes that I've seen use something to approximate the way the flat type works - they use an alpha ramp or something like that to create a flat rendering surface, and then draw one or more plunger images on top of it (if more than one, it's for animation to show the spring compression).  I figured that a built-in mechanism to accomplish what all the scripts already do would make it relatively easy to convert the visuals in a table with one of these scripted plungers to a script-less setup based on the regular plunger object.  And that works - the flat type does just that.

 

Once I got the flat type working, though, I realized it has the big drawback that it doesn't adapt to perspective changes.  That means you need separate plunger images for a desktop table vs a full-screen table, and even for full-screen you might need new images if you change the layback settings more than a tiny bit, to adjust to the new camera angle.  The Custom plunger does, since it's rendered from a 3D model.  The Custom plunger is also just less work to set up, mostly because it populates all of the animation frames for you - no need to hand-draw all of the intermediate frames showing different plunger compression distances.

 

My feeling right now is that I'd be perfectly happy with just the Custom plunger for all of the tables I know about, since it looks pretty photo-realistic and is so easy to adapt to the exact proportions and perspective you want.  But I have to stop short of claiming it's the right solution for all tables period, because I know I haven't seen all the tables out there.  Pinball has a long history full of imaginative gimmicks, so I wouldn't be the least bit surprised to the occasional weird plunger that can't be shoe-horned into the Custom style's constraints.  I think Flat is a good fallback to have, just to know that you can fairly easily get any appearance you can cook up in Photoshop.

When I tried the flat type the motion jumped four notches at a time after the first 2 or 3 notches that worked smoothly..

 

Thanks - I'll take a look and see if I can reproduce that.

PS: the only remaining problem I see with the accelerometer physics is that when you nudge your cab up to make the ball bounce off of a post like the center bottom post it seems to soften the bounce instead of strengthening it. If I use a flat table test, the balls roll the right way when I tilt the cab so I know my mounting settings are correct. Perhaps you can look into this for your next project?

 

Interesting - I'll have to take a look at that.  It seems like that sort of interaction was working properly for me back when I was doing the Pinscape accelerometer work (and was working separately from anything I was doing), but I'll have to look at it again.  I actually do have a little more accelerometer tweaking that I'll probably get to shortly.  There's a nagging problem that's always been there with missed updates, which slightly reduces the quality of the simulation effect from accelerometer input, and I think I've finally come up with a solution that I want to try out.  I'll try to take a look at the bouncy behavior while I'm at it.

[toxie]

great stuff, mjr!

[RYSr]

mjr,

 

When you add the plunge mod changes to the VP PM5 version,please also add the alternate registry settings again. Otherwise the x and y gain settings have to be changed when switching between 9.9 and PM5 tables.

 

Thanks again,

Rich

 

PS: The testing I did in my previous post was with the desktop Nanoteck analog controller using my desktop PC with a swivel monitor mount.

       I still have to check it out with my Cab and it's Virtuapin V2 controller to see if I get the same response on the plunger movement.

Edited by RYSr, 31 March 2015 - 01:33 AM.

[gtxjoe]

Thanks for the work on the plunger.  

 

I was just responding to a nudge controller topic and that had me thinking is there anything that can be done to support tilt due to analog nudge?  Sorry for the off-topic but maybe improvements could be done here as well...

[RYSr]

PS: the only remaining problem I see with the accelerometer physics is that when you nudge your cab up to make the ball bounce off of a post like the center bottom post it seems to soften the bounce instead of strengthening it. If I use a flat table test, the balls roll the right way when I tilt the cab so I know my mounting settings are correct. Perhaps you can look into this for your next project?

 

Interesting - I'll have to take a look at that.  It seems like that sort of interaction was working properly for me back when I was doing the Pinscape accelerometer work (and was working separately from anything I was doing), but I'll have to look at it again.  I actually do have a little more accelerometer tweaking that I'll probably get to shortly.  There's a nagging problem that's always been there with missed updates, which slightly reduces the quality of the simulation effect from accelerometer input, and I think I've finally come up with a solution that I want to try out.  I'll try to take a look at the bouncy behavior while I'm at it.

 

 

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

 I don't want to sideline this thread, but just wanted to add to this that I added a post to a ball drop test table to simplify testing of the vertical nudge bounce problem.

 

I seems clear now that I must nudge the table up when the ball is a half to almost a full ball size away from the post to get a good bounce. If you wait till the ball is just in front of the post it will not bounce or slow the bounce down.

 

My guess since VP doesn't move the table it moves the ball, that the ball needs some time to accelerate to provide the same effect as moving the post (table). I've read many threads that whether the table moves or the ball moves there's no difference, but this seems to show that it does make a difference. It seems consistent will all versions of vp9 that support accelerometers.

 

Here's the test table I used give it a try when you get a chance.

 

https://www.dropbox....est FS.vpt?dl=0

 

Thanks

Rich

Edited by RYSr, 31 March 2015 - 11:40 PM.

[mjr]

PS: The testing I did in my previous post was with the desktop Nanoteck analog controller using my desktop PC with a swivel monitor mount.

       I still have to check it out with my Cab and it's Virtuapin V2 controller to see if I get the same response on the plunger movement.

 

Are you talking about the problem you mentioned with the jumpy first two frames of the "Flat" style?

 

If so, are you certain that it's not the analog plunger device?  Some of the commercial ones just have jumpy behavior natively.  If the analog device is sending jumpy reports, you'll see jumpy animation in VP.  You can test this by firing up the Windows joystick control panel and watching the Z axis as you move the plunger.

 

You can also check if you're seeing the same thing via the keyboard interface.  You can set the Pull Speed to something really slow (like 0.1) to view the animation in slo-mo via the keyboard interface.  

 

If that doesn't shed any light, please send me a test table and the exact step-by-step instructions to reproduce what you're seeing - I want to make sure I'm looking at the same thing.

 I don't want to sideline this thread, but just wanted to add to this that I added a post to a ball drop test table to simplify testing of the vertical nudge bounce problem.

Here's the test table I used give it a try when you get a chance.

 

It might be better to start a new thread on this - why don't you do that and send me a pointer.

I was just responding to a nudge controller topic and that had me thinking is there anything that can be done to support tilt due to analog nudge?  Sorry for the off-topic but maybe improvements could be done here as well...

 

I do have some thoughts on that, but it might be better to take that to another thread, too.

[sliderpoint]

I took a bit more time to check this out.  I like it a lot!  it works well. You are able to get that "pull back a little, ball only goes a little" now.  The release speed/mech strength being the same/close is nice.  Visually the options are a huge improvement and very flexible.

 

One thing that I would be curious if you could help with is the visual representation of the plunger in the editor.  One of the difficult parts is getting the plunger in the correct spot.  I gathered that if the park position is 0 then the plunger will not move forward (pushing on an analog device or spring bounce, etc) however visually you know in the editor that is where the top of the "box" is.  A silhouette of a plunger tip inside the box that moved away from the top of the box based on the park position would be a huge help I think.  Not sure how complicated that kind of a thing would be. 

 

Another item that I'm not sure is on or off topic is that I tried a couple ball launcher  tables (MM, AFM, champ pub) and with this modified exe, the push forward on my pinscape doesn't work to launch the ball.  However they do work on the standard 991,pm5 etc. Am I supposed to do something to get that to work?  The Keyboard press does work.

 

Excellent work as always!

 

-Mike

[blashyrk]

Thanks for the work on the plunger.  
 
I was just responding to a nudge controller topic and that had me thinking is there anything that can be done to support tilt due to analog nudge?  Sorry for the off-topic but maybe improvements could be done here as well...

You can tilt the table using analog nudging, just set the sensitivity to 900 and work your way up from there. Just remember to quit and reload vp after each adjustment.

[mjr]

One thing that I would be curious if you could help with is the visual representation of the plunger in the editor.  One of the difficult parts is getting the plunger in the correct spot.  I gathered that if the park position is 0 then the plunger will not move forward (pushing on an analog device or spring bounce, etc) however visually you know in the editor that is where the top of the "box" is.  A silhouette of a plunger tip inside the box that moved away from the top of the box based on the park position would be a huge help I think. 

 

Good idea.  I think at the least a line showing where the park position is would be fairly easy to implement and would make things a lot easier in the editor.

 

 

Another item that I'm not sure is on or off topic is that I tried a couple ball launcher  tables (MM, AFM, champ pub) and with this modified exe, the push forward on my pinscape doesn't work to launch the ball.  However they do work on the standard 991,pm5 etc. Am I supposed to do something to get that to work?  The Keyboard press does work.

 

First thing I'd check is if your keyboard options show up correctly in the modified version - go into the Keys dialog and check to make sure the plunger key is still showing Joystick button #24 (or wherever you assigned it if you customized the Pinscape firmware).  I didn't change the registry key in the mod'ed version, so it *should* just be picking up your 9.9.1 settings, but check to make sure.

 

You could also try updating to the latest version of the Pinscape firmware if you haven't already.  I made a change there specifically for the new auto plunger code.  (The new firmware should be universally compatible - you can run the new firmware with all VP versions, original or modified.)  The change is that the firmware doesn't send any analog plunger movement to VP when the "ZB Launch Ball" signal is active, to ensure that there's no interference between the VP-side Launch key press and the Pinscape-side Launch key press.  I don't think that will actually make any difference for the mode where you push on the plunger, though - it's just to handle the case where you pull back the plunger and let it go, since VP will now generate its own Launch button press when it sees that motion.  Even so, it could be worth trying the latest version just to make sure we're both talking about the same thing.

[sliderpoint]

Just a follow-up.  The ball launch problem was the mapping not being there for button 24.

 

This seems really good so far.  I'd like to see this get merged into the VPX beta soon.  What do we think needs to be done for that to happen?

 

-Mike

[mjr]

New version posted!  Please see the first post in this thread for the updated link to the download.

 

The release now includes all versions of VP in current circulation:

 

  VP 9.9.1

  Physmod 5

  VP 10.0 beta

 

Executables, source, documentation, and resources are included as with the original version.

 

The new release has some improvements and bug fixes to the original 9.9.1 version, and carries over all of the changes to Physmod 5 and VP 10.

 

Re the physmod 5 version: Yes, it includes my accelerometer filtering mods; and Yes, it uses its own separate registry key.

[blashyrk]

fantastic thank you very much mjr.

[sliderpoint]

Dotted line for plunger location!!! You Rock!

 

-Mike