1031 replies to this topic

[fuzzel]

How about using -1 for the flipper strength in the global setting to signal not to overwrite the individual value?

[wrd1972]

How about using -1 for the flipper strength in the global setting to signal not to overwrite the individual value?

Perfect.

COuld this feature apply to all other settings in global as well...IE...1= ignore?

 

If you dont mind, let me re-ask the question on backdrop "inclination, FOV and layback and rotation". Are you certain these would effect PF dimensions?  I use the exact same BD settings for every 200+ different tables on my cab but I do tweak all of the other backdrop settings per table. If ONLYU the above 3 settings were globally configured, it would help me and others that use a very common backdrop "inclination, FOV , rotation and layback".

...just added in backdrop rotating setting too above. That might really help the folks that get twisted on tables that are released with rotation 0.

Edited by wrd1972, 01 March 2018 - 01:03 PM.

[fuzzel]

I have to check the code if we can use -1 for all settings not certain about this atm.
Regarding the pov settings yes it depends on the dimension of the patients and view much other elements are placed around the actual table.
VP tries to place the camera in the middle out the playfield by calculating a big bounding box that includes all table elements. If you place elements around the table our the dimensions are a bit of the you have to adjust the camera with the camera offset setting. Changing the inclination,fov and/or layback you might have to adjust the offset/scaling settings again.
If every table would have been built with the correct dimensions then this wouldn't be a problem.

[wrd1972]

Understood. Thanks

[toxie]

I think for some settings in the physics, negative values already will use an internal global default instead. I don't know though if any tables actually use that, because most likely the majority of these global values are nonsense or not-so-awesome by nowadays standards.

[chepas]

Nobody else have that issue of ball not going under a ramp?

[toxie]

Haven't looked at it yet. Do you have a simplified table that you could attach here, please?

[kiwi]

Nobody else have that issue of ball not going under a ramp?

Did you try to add a control point on the ramp, just before where the ball passes?
So you can also check the actual height of the ramp at that point.

[gtxjoe]

With the latest VPX beta, I just tried a single ramp with Top Height = 200 and Bottom Height = 0  running across the entire width of the table.  Ball will not pass under any point of the ramp.

[cyberpez]

Does it work if you add the control point like kiwi mentioned?  I ran into this with Haunted House and that was the "fix"  I was told it was a bug that's been present way longer than I've been around.

[ClarkKent]

Would it be possible to use higher values for friction than 1? After adjusting so many tables I still have the feeling that the ball does not slow down as much as it should on walls and rubbers.

[toxie]

With the latest VPX beta, I just tried a single ramp with Top Height = 200 and Bottom Height = 0  running across the entire width of the table.  Ball will not pass under any point of the ramp.

 

Indeed. WTF? And even more weird if TH=0 and BH=200, then it works! Never heard before of that issue.

 

EDIT: actually seems like the very first segment of a ramp only shows this issue, i.e. as soon as the ramp is not perfectly straight or after the first control point for a straight ramp, everythings fine.

 

Will look into it if i see something.

Edited by toxie, 01 March 2018 - 09:11 PM.

[Drybonz]

Hey guys... there was some brief discussion today regarding 2 screen support in VPX... this was in the Banzai Run thread, discussing what was needed to achieve that with 2 screen b2s.  I hadn't heard any mention of 2 screen support for a while and just wanted to throw this out there to see if it 1) was still on the list  2) was relevant to getting Banzai Run what it needed to move from fss to fs.

 

Thanks!

[chepas]

Cheers guys, had never come across that before, I thought it maybe was something new that had crept in recent builds.

 

The ramp in question was only 2 points, top and bottom, just straight up.

Edited by chepas, 02 March 2018 - 08:51 AM.

[kiwi]

I have noticed something different in the behavior of the ramp entry / exit walls,

the ball when it hits the entry / exit corners tends to stop more frequently than the VPX 10.4.

 
Ok, it's an intersection of 4 ramps, not even connected well, so I'm sure to improve it.

 
Eventually I will attach a test table, if it were to serve.

 

Thanks

[fuzzel]

We can't do much at the moment. Sourceforge is down for service and Github had some trouble with a DDoS attack 

[toxie]

I have noticed something different in the behavior of the ramp entry / exit walls,

the ball when it hits the entry / exit corners tends to stop more frequently than the VPX 10.4.

 
Ok, it's an intersection of 4 ramps, not even connected well, so I'm sure to improve it.

 
Eventually I will attach a test table, if it were to serve.

 

Thanks

 

Simple test table is always good..

[toxie]

 

With the latest VPX beta, I just tried a single ramp with Top Height = 200 and Bottom Height = 0  running across the entire width of the table.  Ball will not pass under any point of the ramp.

 

Indeed. WTF? And even more weird if TH=0 and BH=200, then it works! Never heard before of that issue.

 

EDIT: actually seems like the very first segment of a ramp only shows this issue, i.e. as soon as the ramp is not perfectly straight or after the first control point for a straight ramp, everythings fine.

 

Will look into it if i see something.

 

 

Oh my, already forgot about this one. This is one of the old legacies of VP, ramps -always- feature walls, and these walls are only approximate, e.g. inbetween two regions of a ramp the wall will reach below and above the ramp itself. How large that region is (i.e. how much the wall will also reach below and above the ramp) depends on the curvature of the ramp, e.g. the more control points and/or the more curved it is, the less this approximation is showing.

[toxie]

I will commit a fix for this, hopefully no tables rely on this odd behavior.. Otherwise, table authors, please speak up!

[jpsalas]

I will commit a fix for this, hopefully no tables rely on this odd behavior.. Otherwise, table authors, please speak up!

 

I guess we all have learned to add control points , since this behaviour have been in VP for ages