Higher gravity, with higher friction, and lower slope seemed to help keep some downward acceleration while improving some lateral travel but was best paired with some table editing to increase to some rubber and other object elasticity values. But it seemed, in my experience, that I was always going to sacrifice at least one element of upward table momentum or lateral distance at the cost of slow or somewhat floaty downward acceleration even when the ball was heading straight down and had a good distance to run (somewhat most noticeable in open expanses).
After spending a lot of time over the last year trying to find the optimal physics settings, based on watching tons of video of targeted tables and going to see several pinball machines in person, I was seeing some improvement but realized, and with all due respect, that there were just simply limits to what VP could simulate. But, because of the great customizability and scripting engine provided, as well as lot's of examples of brilliant coding from other author's, I decided to work on creating / evaluating a potential system / routine that would alter the ball speed in real-time to provide both a means to help the ball travel up table longer while simultaneously improving it's acceleration downward and travel from side to side. Effectively, it was to simulate an improved momentum and revolves around adjustments at the speeds at which the ball is slowing down (in the case of down table, speeding up).
So, it is with much satisfaction that I report that I have successfully created a Ball Momentum Physics Routine (BMPR) that enhances VP's physics and allows for subtle but noticeable improvement and uses internally documented individual adjustable parameters for enhancing ball speeds for up table, down table, and lateral. All are independent of each other so you literally can stretch out how much longer a ball hangs while travelling up while also increasing the speed at which it travels down once it is actually travelling down.
It requires the ball collision tracking routines that PinballKen and Steely created for ball collision sounds as it uses this for tracking each individual ball in order to apply the required functions and to work with multi-ball. I also got the idea of how to implement a tracking for multiple balls from rascal’s ball rolling sounds script – so some credit out to them
The demo table is oriented as a full overhead view to better evaluate how the ball is rolling without any persepective (angle or FOV) aspects. Here is a video I’ve posted on youtube showing the table and the contrast between the BMPR system when active and disabled (normal mode) - NOTE: the jitter is from the capture and video processing aspect and not the table / routine:
Their is quite possibly too much to try and explain about the workings of routine but it is actually very easy to implement as long as the ball collision script has been successfully added to a table. You would just need to copy a timer, the routine code section code, and potentially modify the arrays / interval speed for the number of balls possible at once if the table in question could have more than 4 - the default that I've created it with and good for anything from 4 down to 1).
In the demo table I use a set of lights to help demonstrate when the routine is active / applying change to the ball in the direction indicated. I will likely release a sample of the code / table without the lights but I've found in the tables I've implemented it in that I prefer to have the lights present and visible while at least adding, testing, and changing parameters. I normally keep the light objects / base / coding for them and when finished I would just move it to the side and off the screen and, by doing so, have it ready on hand when / if I want to tweak some more, move back on the table, and be able to see again the real-time feedback and confirmation that things are working as expected.
Mostly, what this routine and it's parameters have allowed for is to now be able increase the friction of a table to make the ball look heavier while, via the BMPR coding, maintaining good momentum / travel distance. In addition to the friction increase, it also has simultaneously allowed for decreasing slope for better lateral travel and more gradual up to down transitions without having a unrealistically sluggish downward acceleration.
In the test table use the "M" key to toggle the enabled state of the momentum routine, the "S" key to toggle an up and to the side kick for the lateral demonstration, and the "D" key to toggle the upper 2nd level drain for clearing the ball. You can also use your plunger launch key to kick additional balls out up to a configured maximum of 4. You may also need to nudge a little to the left or right if the balls have finished moving and are at rest on the upper platform.
The table is set at 1.675 gravity, 4 slope (min and max) with .2 Global Difficulty for some slight Scatter angle, and .0035 friction. The objects are at an elasticity of .75. In general, this routine and it's current parameters work best with around these settings as well as manipulating table objects for slightly higher elasticity (for example .6-.8 for rubbers). However, I have applied it to tables from all generations with great results and later generations tables would be more towards a 5 slope with some tweaking on the routines parameters. The key is keeping the friction higher and around the .0035 as well as the gravity at 1.675 or there about. In all the tables I've tested I've not once changed the gravity from this value. That being said I have changed the friction on some tables as low as .003 and as high as .00375. These will still be personal taste settings and simply the more friction the more BMPR effect you may have to add.
I have not noticed any real performance issues from implementing this script and it is extremely fluid to the point you would not know that anything is being “manually” manipulated regarding the ball speed. If you change the values to unrealistic levels it will still be pretty fluid but maybe just a bit crazy like the ball speed constantly increasing while going UP table.
There is more to discuss regarding how to use it for authors / modders but for now I’ll wrap up and can continue more in this thread with details as needed. The parameters have some documentation in the script itself but the gist of it is that there is a threshold in which the process kicks in for the particular direction (side to side, up, or down), a cut-off or max at which it no longer manipulates the ball speed and a level value that is used in calculations for the effect. Sticking generally around the “level” and threshold values in this demo would be a good base for the system from all the testing I’ve done. However, the deeper idea behind creating this demo table and the parameters the way I have is so that people can play around with them (for those who want to check out the scripting vs. just check out the effects with the toggle keys).
People are very welcome to use this code with the caveats that I mention in the remarks of the script. I'm going to contact a couple authors whose tables I've personally modded for this routine and the changes in the resulting physics to complement it. I hope I can release one of these as mostly, after all this, you really have to play a table with this routine to "feel" the difference.
Hope this BMPR system can add a little to the world of VP and helps others enjoy the tables at a different level for which I've been able to since creating it.
JF
Attached Files
Edited by jimmyfingers, 01 June 2012 - 02:00 AM.





Top






Contributor












are all trademarks of VPFORUMS.