868 replies to this topic

[Shockman]

It would be a very hard job to evaluate the potential of the experimental build. Impossible running tables. At least my mmpac, it's like a totally different physics set, like I went through and randomly adjusted settings. It did seem more mundane though, but without any tweaking to the experiment. 

 

I really like the physics of the releases though. I like the graphics too. My only problem is with performance.

 

The adjustable bumper ring mech. is not appearing in my dreams as much as it use to.

 

You guys did and are doing great. Thanks

Edited by Shockman, 27 May 2016 - 05:25 AM.

[toxie]

Is it really behaving that substantially different? Cause then its definetly a no-go for the 10.1 release.

Any more comments?

[hauntfreaks]

using the experimental exe .... it seems everything is amplified .... plunger, slings, bumpers.... 

it would take readjusting all previous table builds...

 

in my rig its playing just as smooth as the latest beta build.... I've used the beta builds in True Full Screen (with the PBX hack) 

and it's playing better than ever, I would have to go as far as to say its playing AMAZING in true-FS  <---- if you guys solve the couple hiccups in this mode I don't think you will hear much from people comparing vp9* to VPX ever again...IMO.

 

 

 

if you guys solve the couple 

Edited by hauntfreaks, 27 May 2016 - 08:31 AM.

[nFozzy]

Did a little testing throwing balls into bumpers, slings, etc and while the physics do shake out a bit differently between the versions, I didn't find any significant differences.

 

Only conclusion I could come to was that the old physics had more consistent results. The experimental physics may be a little more "wild" without any object scatter.

Edited by nFozzy, 27 May 2016 - 10:02 AM.

[toxie]

interesting. thanks so far! but any more comments are still more than welcome.

 

as for the bug in congos lower playfield: no clue yet why this does not work anymore..  :/

[tttttwii]

I tested the experimental build versus the latest beta on following tables:

 

AFM (Groni):
- ball with less weight
- ball is more fluffy and jumps on the rubber

 

Monster Bash (Randr):
- Ball is not leaving shooter lane in the experimental build. No test possible.

 

Medieval Madness (Dozer):
- less artificial spin for slower ball movements close to the flipper fingers

- right ramp can hardly be shot (looses speed)

- same observation as in AFM

 

Embryon (ICPJuggla)

- ball under same settings more difficult to control

- ball with less weight

 

The physics in the tables need to be slightly adjusted to match the new physics. The physics are different but not better or worse. With minor physic adjustments in the tables, everything should be playable.

[Ben Logan]

How's the ball spin with the new experimental physics? I'm finding myself lowering gravity and table friction and raising slope on most tables to compensate for (in my humble opinion) too much ball spin / too many curveballs. Don't get me wrong - I love ball spin (It's totally missing from TPA, for example), but I'm hoping it gets dailed down a bit.

[jimmyfingers]

How's the ball spin with the new experimental physics? I'm finding myself lowering gravity and table friction and raising slope on most tables to compensate for (in my humble opinion) too much ball spin / too many curveballs. Don't get me wrong - I love ball spin (It's totally missing from TPA, for example), but I'm hoping it gets dailed down a bit.

Ben to confirm with what you are saying above.  You are asking about ball spin with the experimental build vs. commenting on your experiences actually testing the experimental build?  Your comments about too much ball spin from your VPX experiences seem to be from a historical point and, to clarify, your'e not saying the experimental build has too much ball spin, right?

 

I'll say it again, too much ball spin is not VPX's "fault" at a general level, it's table's with colllidable objects having too low / neglected set friction levels and tends to happen more with conversions from VP 9 / physmod (locked friction settings) where these values didn't exist / weren't entered.  The perception of too much ball spin is erroneous in blaming VPX itself.  It's is not that it doesn't occur too much on some tables and those weird arcs that everyone can experience on some tables are too frequent / unnatural, but that it can and should be tuned out but unfortunately takes a lot of time and patience to do so with everywhere a ball can collide on a table and how much simply missing one element can still influence experiencing several "strange" events per game.  I have tested with a good base of PF and collidable objects friction / elasticity settings and get a great balance of real life comparable play for spin events.  

 

The latest builds have actually taken away from good / proper ball spin physics and to still incorrectly cite VPX as the cause vs. the tables could dangerously lead us down a path where VPX regresses in it's simulation qualities and gets backwards closer to VP9.  Physmod seemed better to the masses on the major aspect of it having locked friction at a value of .3, so no tuning mistakes could be made (only the flippers could be adjusted).  I can tell you from personal experience and personal compiles of Physmodv5 with the friction being unlocked, that you get the same issues if you do not carefully and painstakingly set all of the friction on ALL collidable objects accordingly even in Phsymodv5 but when opening the coding for friction being definable on objects besides the flippers.  First time I played my custom friction unlocked Physmodv5 compile with a regular Physmod table, it was squirly as hell, and a huge eye opener for what impact the friction settings (or lack thereof) had on the ball trajectory.   Soon as I set a couple walls that were to be rubbers (before rubber objects were created) with a friction of about .8 (especially on the slings) then watched a ball with spin crawl up slightly like in real life, it became total Eureka moment. 

[Ben Logan]

Thanks, Jimmy. You're right -- I should have clarified: My comment about ball spin was NOT based on my experience with the experimental build. I believe you that perceived excessive ball spin isn't the engine's "fault," and that it can be tamed with careful tuning. I'll continue to experiment with tuning in the editor. Thanks for your comments, as always.

[jimmyfingers]

I'll continue to experiment with tuning in the editor.

In the editor it is not really either the main fields for slope / physics (although you still are best with table friction around .07 give or take a bit).  The editor work comes from the total tedious clicking and / or grouping of every rubber, metal, wood, plastics, pin, raised PF, ramp, etc. that the ball touches.  The amount of work in the editor to tune things (amount of objects x amount of fiddling / revisions) is fundamentally responsible for why it gets passed over to the extent it can and does.  Most end users / non-authors will spend all the time "tuning" the main / global settings but that really isn't the area that requires the work. 

 

You have to be prepared to put your glasses on and clear your schedule for the day when you start tuning the actual table objects friction (and elasticity for that matter) and likely that will be only for one table's worth.  One thing that is quite beneficial is, while doing the initial work / personal customization (mods), to make groups of objects - if not already created or extensive enough - then use the groups to tune the similar objects all together and this will make revisiting the items settings much easier.  Doing each collidable object individually is not conducive to fine tuning as going around the whole table again to adjust the initial adjustment again can reasonably demonstrate why this aspect is forgone by a lot of people while wanting to "tune" the physics of any given table.  And adjusting the initial adjustment is also part of making a table play closer to the real things as some areas can take lot's of time around combinations of objects. 

[Ben Logan]

Thanks for the advice, Jimmy. Spending an afternoon tuning a table I love is a great time. Much appreciated.

[toxie]

Some comments: for 10.1 we will not include the new changes (at JF specifically: everything except for the very first minor change, to fix the jumping balls, will be reverted for now).

Then you guys can retest this new build, and this will be it then.

 

For 10.2 we could think about going forward and having the option to switch to the 'less whacky' physics. There, btw, i disagree with JF:

- the changes i did (e.g. kicking out most of the ball-teleportation-hacks) automatically fixed whacky ball spin, and making it void to use any artificial ball spin reduction at all. So in that aspect i would say that it is VPX's fault

- going forward we should get rid of as many weird code and old heuristics as possible, as some stuff is still there from VP9.0.7 or even VP8 times, and replace it with more robust code. This is will avoid that funny stuff happens, like when i replaced some of the collision detection code, and all of a sudden the collision handling reacted differently on some tables

- we will get the same 'correct' ball behavior back as before, i'm sure, but it will be some work, same as when PM5 was made and after that when retweaked for VP10, but this shouldn't hold us back

- some table elements like primitives and walls and the playfield itself featured different collision detection and handling code, although they should be absolutely similar (its all 'planes' after all). This is a no-go as it will confuse people when tuning physics parameters, as different elements will react differently with same parameters

[jimmyfingers]

Some comments: for 10.1 we will not include the new changes (at JF specifically: everything except for the very first minor change, to fix the jumping balls, will be reverted for now).

Then you guys can retest this new build, and this will be it then.

 

For 10.2 we could think about going forward and having the option to switch to the 'less whacky' physics. There, btw, i disagree with JF:

- the changes i did (e.g. kicking out most of the ball-teleportation-hacks) automatically fixed whacky ball spin, and making it void to use any artificial ball spin reduction at all. So in that aspect i would say that it is VPX's fault

...

Wasn't all of the whacky ball spin correction / reduction / previous coding soley or at least largely focused on the ball spinning issues from when balls were at rest, on top of one another, or close to stopped in there X / Y vector motion but still spinning while resting on an object?  I thought the whole element that started the ball "spin" hacks was not about general gameplay and ball actual trajectory related / affecting ball spin at all, which is what most people are referring to here when talking about ball spin "issues" with VPX.  From everything I understood in the coding and routines to date, it was only for when the ball would unrealistically spin while stopped or was close to stopped, ideally only for when it was in a position resting on something else and trying to fix it's previously noticable spin that should not be in these scenarios (mostly the endless spin in these scenarios that was obviously not accurate / realistic).  The concerns I had was that the artificial reduction techniques / changes (recent ones mainly) was going / is affecting the moving / colliding ball spin characteristics, which to my knowledge had been in general avoided previously as the focus on the "hacks" being for the spin issues for the ball at rest (tied with the static ball detection aspects so as to not affect spin for balls that were considered dynamic or colliding).  Isn't it fair to say that all the spin reduction code that was previously focused on was for the general concept of static balls and not ones in motion?  And hence that whatever whacky spin is being discussed is in this more specific vs. general game play realm?

 

I think some clarification of exactly what the whacky ball spin / control hacks pertained to would be useful so people don't get the wrong idea still of what is / was VPX's coding and what still comes from table tuning.

 

I think it makes good sense and is a better plan for sue to let 10.1 be unaltered in these larger (yet ultimately potentially beneficial) physics areas and resume them in another beta cycle and arguably closer to the start of one before lot's of bug fixes and features have been added (as I mentioned in our PMs).  Seems we agree on that part mostly  From what I've see of the intermediary test builds there looks like there will still be undesirable overkill or issues that will need to be worked out and testing in some of these realms is very hard for a variety of reasons.  However, it does sound promising to continue to improve collision handling / consistency and physics where possible. Just a bit of a can of worms right at this "close to 10.1 release" stage.  Also, it seems that your choice of words (italics) with option means that with VPX versions going forward and with other bug fixes and features that we could still choose to keep the original physics to date for those of us that liked it or don't want to add new variables to the game play tuning?  That would be great if you can do it that way so we can potentially progress with other software features and have the choice to still play it with the physics some of us have got used to but also while being able toggle / try-out / beta test the new improvements to the physics code (especially with goals of replacing elements from very old versions as you mention and the problematic collision code issues you have told me about previously, for at least ball to ball collisions).  

Edited by jimmyfingers, 28 May 2016 - 06:57 AM.

[fuzzel]

rev2644 is up:

 

- controller.vbs updated (by arngrim)

- experimental physics are disabled again

- bugfixes found by static code analyzer Coverity

[DonRobby]

After more then 4 months of clowining around it really is time to make an official release of VP 10.1. 
I have said it before, when tables are being made for this version it should become a priority to make the release official.

But here we are, months later and still no official release.

Just think about the generic player who downloads VPX just to find out the newer games aren t even compatible with it and the only way to find 10.1 is by digging out a forum.

A forum that 50% of the users doesn t even use

So either the game developers need to stop releasing games for the beta  and just keep those updates on ice until the release is official or the software developers need to follow the game developers.

[gtxjoe]

Yes, I agree also. I highly recommend for VP 10.2 that there should be no beta releases.  All 200 beta releases should simply be released as official SW releases, all 200 versions.  

 

That way, when the game developer releases a table, he can simply specify what version of 10.2 to use.  The end user can download the table and also the correct version of 10.2 to use, and everyone is happy

 

 

EDIT:  Time for breakfast.  Pancakes, anyone?

Edited by gtxjoe, 28 May 2016 - 12:50 PM.

[randr]

I'm not a pro at vp so I'm sure my builds have issues but for most part play ok. That being said any changes needed I'm more then happy to make! I need some time to actually make these changes but this all looks like great stuff! Thanks devs for the great work! I will try to be more precise on my builds in future

[Slydog43]

I love playing with each beta build and can't believe how fast things get fixed up and features added (if only other paid products could be 1/2 as good).  Thanks devs, you guys are truely amazing.  Happy holiday weekend to all those in the USA.

[BorgDog]

Yes, I agree also. I highly recommend for VP 10.2 that there should be no beta releases.  All 200 beta releases should simply be released as official SW releases, all 200 versions.  

 

That way, when the game developer releases a table, he can simply specify what version of 10.2 to use.  The end user can download the table and also the correct version of 10.2 to use, and everyone is happy

 

 

EDIT:  Time for breakfast.  Pancakes, anyone?

 

I'm more of a french toast guy myself, and of course everything is better with a fried egg on it ooh, and don't forget the bacon.. do you deliver?

[hauntfreaks]

long ranty post "Deleted" 

just going to bite my tongue instead