I've been working on some improvements to the VP plunger object that I'm ready to share with the community. This is skunkworks stuff outside of the official VP development group, but I've been in touch with Toxie, and he seems okay with what I have in mind. If all goes well with the testing, and people generally think this is an improvement worth keeping, I think we can get it absorbed into the official VP code base.
Testing versions are now available for VP 9.9.1, Physmod 5, and VP 10.0 beta.
Here's a download link. This is a ZIP file with the modified VP executables (ALL VERSIONS), documentation, and a bunch of graphics resources as examples and starting points for your own custom work. It also includes the modified VP source code (all versions) in case you want to compile your own from scratch. (Just pull a snapshot of the appropriate branch from sourceforge and substitute the modified source files from the zip below.)
https://www.dropbox....-14-15.zip?dl=0
Read on for details of what this is all about. I'd like to invite anyone who's interested to test it out and see what you think. Feedback is welcome, in terms of general opinions on the new features as well as specific bug reports.
Goals of the project
My primary goal was to make the built-in plunger object look good enough and act realistically enough that I could use it to replace the scripted "fake" plungers in all of the tables on my cabinet where the analog plunger input doesn't work.
Analog plunger support has been one of the ongoing headaches with my cab. The majority of tables don't work out of the box with it. Some are relatively easy to get working, others are quite difficult, but even the easy ones take a fair amount of time to deal with.
When I set out on this project, my original thinking was that I'd just come up with the One True Script Hack for plungers. I was going to analyze the various hacks that people have used over the years, find the best one, and come up with a recipe to apply it to all of my tables. But after a bit of study, I realized that this was the wrong approach. For one thing, I don't think there really is a single best hack; there seem to be trade-offs, which is probably why everyone doesn't already use the same approach. But more importantly, coming up with a better hack would just be treating the symptom. The real problem here is that the built-in plunger isn't good enough for table designers to use. The real solution would be to fix the plunger.
Summary of the changes
The new code addresses the two areas where I've heard complaints about the existing plunger, and had complaints myself: the visual appearance, and the physics. For the visuals, I added two new style options, and a bunch of new properties that go with them. I think the new styles are flexible enough for table authors to get exactly the appearance they want out of the plunger, with much less work than the comparable scripting approaches. For the physics, I basically rewrote everything, and added some new tweakability there as well.
Visual changes
The big change is that I added two new drawing styles for the plunger. The first is a "Flat" style, which renders an image (which can have alpha transparency) onto a flat, rectangular surface. More interestingly, it can render a series of animation cells onto the surface. I think this can serve as a drop-in replacement for all of the animation tricks that most of the scripted plungers use - with vastly less work, since everything happens automatically without any scripts or timers. The second new style, which I think is even better, is the "Custom" type. This is a 3D model along the lines of the existing "Modern" type, but it has two things Modern doesn't. It lets you customize the size and shape of all of its parts. And it has a fully 3D modeled, animated spring that expands and contracts as you move the plunger.
Here are a couple of examples of the Custom plunger. These are just taken from VP screen shots.
Those are basically identical plungers in that they use the default settings that you get when you use the Custom type; the only difference is the texture maps. Those texture maps and several others are included in the Zip file above. The texture is hardly all you can change, though: you can change the entire shape of the tip, the geometry of the E-ring, the width of the shaft, the gauge of the spring wire, the diameter of the spring windings, the density of the spring coils, and the number of those little tight end loops at the top of the spring.
Also, keep in mind that these are 3D models, so the perspective adjusts automatically to your layback and other camera settings.
Physics changes
I didn't set out to do this, but I ended up rewriting most of the plunger physics. This isn't like the Physmod5 or even VP10 physics rewrites, though, in that you shouldn't have to rejigger existing tables to deal with the changes. What I tried to do was to keep things working the way they were supposed to work all along, but without all the weird non-linearities and bad behavior.
Here are the main problems that should be fixed in the new code:
- If you set "mech enabled" on the old plunger, and tried to use it from the keyboard interface, short pulls produced release speeds that were much too high. Part of the reason is that the plunger tip would do a full-speed dash all the way from the rest position to the fully forward position, even for the tiniest tap on the Return key. That's fixed. Short pulls now produce proportional release speeds whether or not "mech enabled" is set. The "bounce" in the firing motion is now proportional to the strength.
- There used to be a big discontinuity in the release speed-vs-pull length curve. There was a dividing line somewhere along the pull distance where you'd get a big jump in release speed - pull back just slightly less than that line and you get a really weak shot, pull back just slightly more and you get a really strong shot. This created a zone of strengths you just couldn't access. Terrible for sensitive skill shots. This was caused by the "break over velocity" algorithm. Does anyone even know what "break over velocity" did? I do now, but only because I spent quite a while deciphering the source code that applies it, and I don't think its real purpose was ever documented. I've removed it and replaced it with a different approach that doesn't require a mysterious parameter like this, and which doesn't have any of the non-linearities of the old system.
- With analog plungers, the release speed was way too inconsistent for a given pull length. On a real machine, there's certainly some variation due to the vagaries of friction and so forth, but nothing like the randomness we used to see with VP. The new code fixes this. In the course of developing the Pinscape Controller, I studied what was going on here in some depth, and I came up with a solution that I implemented in the controller firmware. Now I've applied a similar approach on the VP side. This should improve the analog launch behavior for any plunger controller with any sensor technology.
- Release strength was too variable in general, whether through the keyboard or analog interface. The root cause was that the strength was (indirectly) a function of the physics loop timing; this introduced what amounted to sizable random term in every calculation. The new code factors this out.
I also added a few nice little enhancements:
- There's a new "momentum transfer" property that lets you tweak the release strength without any effect on the animation. One of the complaints I heard about the old plunger is that the only way to reduce the strength was to reduce the Release Speed property, which also slows down the visual animation of the release motion. It wasn't always possible to get the right strength without making the animation look wrong. The new momentum transfer property addresses this by giving you an independent knob that only affects the strength. This is a factor that's just multiplied into the regular speed-based calculation. The default is 1, which obviously has no effect in a multiplication. If you want to make the release twice as strong, set it to 2. If you want to make it half as strong, set it to 0.5.
- The old plunger had some code that attempted to let you use a mech plunger to control an Auto Plunger in the simulation. I'm not sure if anyone ever used this code or if it even worked; from what I can piece together from the code, there was some cooperation required by the table scripts that I don't think is documented anywhere. But just in case, I carried the code forward, and I also removed the hoops that scripts had to jump through - it's now automatic and transparent to scripts. This is described more completely in the documentation, but here's the executive summary: when you pull back the mech plunger and let go, if the software plunger has the Auto Plunger property set, VP will generate a synthetic Return key press. So firing the analog plunger translates into a Launch Ball button press, even if you don't have a Launch Ball button on your cab. This is all done without the script even knowing about it; the script just sees a Return key event.
- There's now two-way momentum transfer between ball and plunger. If a moving ball strikes a stationary plunger, the plunger will get a little bump that you can see in the animation. (Sorry, it doesn't move your analog plunger knob yet. 
) The strength of the bump is proportional to the strike speed. Along the same lines, when the moving plunger hits a stationary ball, it saps some of the momentum out of the plunger. If you've ever closely observed a real machine, you might have noticed this effect in reality - a plunger that strikes a ball transfers most of its momentum to the ball and so doesn't rebound much off the barrel spring. A plunger fired without a ball present bounces around quite a bit because its momentum all goes into the spring rebound. This stuff is all just special effects with no functional benefit, but I think it subtly contributes to the realism even if you don't consciously notice it.
Try it out and post your feedback!
I think that about covers it. I'm pretty excited about the new plunger features - I've already used it to fix a few of the most recalcitrant tables I have on my cab (the ones where I just couldn't figure out how to make their scripts work property with the analog device), so if nothing else it accomplishes my original goals. But I'm really hoping that table designers will like the new plunger options well enough that they'll happily use them for future tables instead of scripting tricks, so that cab builders with analog plungers will eventually be able to assume that a newly downloaded table will just work.
Edited by mjr, 14 April 2015 - 06:58 PM.
Top
Thank you very much!
thanks for the time you put in this!
). So if you port your code to the VP10 code please remove the type also.
are all trademarks of VPFORUMS.