1488 replies to this topic

[jpsalas]

I'm seeing a bug with ramps.  I first saw this on Indy 500 and thought it was weird, couldn't explain it and didn't see it anywhere else.  Well, I'm seeing another example of it. 
 
For long ramp sections, the right hand wall becomes noncollidable.  The ball can pass right through it.  See red arrow on the right.  Easiest to test this with manual ball control, sliding the ball up the right hand side of the ramp.
 
In addition, the ball won't pass under the ramp from left to right.  See red arrow on the left.  
 

 
Test table in the dropbox link attached.
 
https://www.dropbox....mptest.zip?dl=0

 

Yes, this is an old bug. I mean it is not a new one from the beta 10.6. I don't remember why it was never fixed, I think it was because of the complex physics involved with the ramps.. We simply add a few extra points to fix the issue.

[Thalamus]

We really should havea a "Known Bugs" file where these things are mentioned.

[fripounet]

at times some elements are shifted from the PF, then recover all by themselves, reloading the table.

[rothbauerw]

The ramps are a dangerous bug. I've been building in vp for a few years now and didn't know about it. Surely there's a way to address it. Even if it's determining how long is too long and throwing an error message or the engine adding points on table load?

[dramaone]

Setting the "disable lighting" to 1 disables the VPX lighting on the mesh. TAF was made before that feature was available for the playfield_mesh. So zero should be correct! The higher value must have been there because the prim import standard was set to 1 for the DL feature and the guys didn't care because it had no effect at that time.

Gesendet von meinem SM-G955F mit Tapatalk

for a noob how do you do that?

[fripounet]

this is the tunnel effect ; must thicken the walls. or less force during the collision., or use  'wall' instead of a ramp, for a wall.

 

 

beginning of explanation :

https://www.toptal.c...r-solid-objects

Edited by fripounet, 26 July 2019 - 09:31 PM.

[fripounet]

 

Setting the "disable lighting" to 1 disables the VPX lighting on the mesh. TAF was made before that feature was available for the playfield_mesh. So zero should be correct! The higher value must have been there because the prim import standard was set to 1 for the DL feature and the guys didn't care because it had no effect at that time.

Gesendet von meinem SM-G955F mit Tapatalk

for a noob how do you do that?

 

witchcraft ))) 

Edited by fripounet, 26 July 2019 - 09:28 PM.

[Schlabber34]

 

Setting the "disable lighting" to 1 disables the VPX lighting on the mesh. TAF was made before that feature was available for the playfield_mesh. So zero should be correct! The higher value must have been there because the prim import standard was set to 1 for the DL feature and the guys didn't care because it had no effect at that time.

Gesendet von meinem SM-G955F mit Tapatalk

for a noob how do you do that?

 

 

In the editor select "Edit ---> Select Element". Search for "playfield_mesh". Click on it and hit the "Select" button. Make sure that the "Options" button on the left is selected. To the right you can now see the PF mesh options. Set the "Disable Lighting" value to "0". Save the table!

[dramaone]

 

 

Setting the "disable lighting" to 1 disables the VPX lighting on the mesh. TAF was made before that feature was available for the playfield_mesh. So zero should be correct! The higher value must have been there because the prim import standard was set to 1 for the DL feature and the guys didn't care because it had no effect at that time.

Gesendet von meinem SM-G955F mit Tapatalk

for a noob how do you do that?

 

witchcraft ))) 

 

or comedy

[3rdaxis]

So I am still rock'n version 3584 and for some reason today all of a sudden I have no script window? I can task over to it but nothing is there? Even after re-boot no window. Kind of hesitant to update to the latest and if it will fix the problem. Has anyone else run into this problem?

 https://www.youtube.com/watch?v=t2F1rFmyQmY

Edited by 3rdaxis, 28 July 2019 - 05:20 PM.

[Thalamus]

That was a known problem some revisions back. Many ways of fixing it. Maybe the easiest is just delete the editor settings in registry. ( unsure ? - rename the hive )

There are very few things I change from default, so, after a delete it will work again. The issue is that you get a ridiculous high number for one of the coordinates. 

[fuzzel]

In the registry go to this section Computer\HKEY_CURRENT_USER\Software\Visual Pinball\VP10\Editor

and delete everything that starts with CodeView. Restart VPX and you have the editor back again.

[3rdaxis]

Thank you brother. 

[Slydog43]

your welcome

[toxie]

I'm seeing a bug with ramps.  I first saw this on Indy 500 and thought it was weird, couldn't explain it and didn't see it anywhere else.  Well, I'm seeing another example of it. 
 
For long ramp sections, the right hand wall becomes noncollidable.  The ball can pass right through it.  See red arrow on the right.  Easiest to test this with manual ball control, sliding the ball up the right hand side of the ramp.
 
In addition, the ball won't pass under the ramp from left to right.  See red arrow on the left.  

 

Ramps are still a special beast :/

They use an approximation for the internal collision calculations since the very day they were introduced.

This makes them much faster to handle than comparable primitives, for example, but also feature the issue that above and below the ramp are some wall-parts that reach higher/lower than the actual ramp. This is usually not an issue, and i introduced a workaround/heuristic in 10.5 that adresses most real-world use-cases, but for some rather steep ramps, this can still be an issue, so the only thing that helps (at the moment) is to use the mentioned "use-much-more-control-points-for-these".

 

(The non-collidable part is a bug though for sure)

About analog nudging and simulated bob.

 

There's this long discussion mostly between me and Thalamus about an extra nudge I was experiencing every time the sim bob triggers.

https://www.vpforums...ic=33287&page=3

 

Several times I thought I've found a fix but then soon noticed it's still there. I had no issues with real bob or sending tilt with Mechanical Tilt key [T] so it was really frustrating as I found no other discussion about the topic except for something similar mentioned in VR thread and therefore obviously thought it was something in my setup.

I then finally took a look in source and found that in pininput.cpp (line 827 in r3746) it was sending 'eCenterTiltKey' when the bob triggers which seemed strange. I replaced it with 'eMechanicalTilt' and it seemes to have fixed the issue.

 

Here's a video showing what I mean. First a test with r3746. ~0:20 you can see this extra nudge bouncing the ball all over. Later in the video another few tries with the mentioned mod and the ball stays cool.

https://youtu.be/_RujVX3-N_I

 

P.S.

Thanks Rob for helping me out. Had some trouble getting the source to build and started messing with cmake which Rob told was deprecated and told it should build fine directly in VS.
I was trying to build latest r3750 but it crashed everytime during table launch. Then thought to try with r3746 which worked without issues.
I used DX SDK 2009 (Aug). Not sure if it makes any different whether I use that or 2010 (Jul)?

 

try to contact mjr, he knows most likely most about the nudge code.

I had the problem with the new Time Warp (Bord) that the playfield looked much too dark. Because I was on an older beta rev I updated to 3746.

Ok the problem for Time Warp was solved, but e.g. for TAF (g5k) I had the opposit, playfield much too bright (see image)

I guess I could solve it for TAF by disable lighting for the playfield mesh. What would you suggest? Change it for all tables affected? Or consider it a bug and wait until VPX in this point is again backwards compatible? (yes, suggestive question)

 

The others already perfectly explained the issue here, so some older tables simply have to be adapted, as we did not think about this back then and adding this backward compatibility now would be also sub-optimal.  :/

 

In addition to this issue, there can be a small to medium difference in lighting/brightness of tables with 10.6 (compared to 10.5) due to the improved texture filtering and especially due to a fixed bug in the lighting computations (mainly visible on the actual playfield usually).

We really should havea a "Known Bugs" file where these things are mentioned.

 

Somebody up to start a document on that? or any other up-to-date documentation?

That would be much appreciated.

Edited by toxie, 30 July 2019 - 03:56 PM.

[Umpa]

Been quiet in here. Must mean the latest 10.6 beta is about ready for prime time!

Sent from my SAMSUNG-SM-G935A using Tapatalk

[jpsalas]

Been quiet in here. Must mean the latest 10.6 beta is about ready for prime time!

Sent from my SAMSUNG-SM-G935A using Tapatalk

 

I think they are simply enjoying the summer holidays

[Thalamus]

I hope they are. Because they so deserve it !

[GInsonic]

So true, Thalamus 😀!

[Ben Logan]

Just want to say that the Z-axis (ball hop) functionality on recent tables adds so much realism. Thanks to all involved for taking ball physics next-level in this regard. We have six real pins in the garage and get air-balls all the time. Part of the “ball is wild” aspect of pinball. Love it!