4027 replies to this topic

[toxie]

Hmmm.. It boils down to 'On Error Resume Next', so this call just hides another problem.. :/

[fuzzel]

@jp: the cause of the crash based on the call stack you posted will be fixed in the next version. It was a follow up error of the flasher image mode bug you reported

[jpsalas]

There must be some variable that is set up during the vpmInit me call, that it is not set when you don't add it to the script, but I can't see anything in the that sub.

I remember when first vpmInit was added was to create the table's subs _pause, _unpause, and _exit to pause and exit vpinmame. Later was used to check if vpinmame could use or not the UseModSol. Now it even doesn't init the fastflips, since it is done in a timer. 

I have checked the new core.vbs and the old one, and I see that, apart from the removed comments, most of the changes handle about  VPBuildVersion being replaced by vpmVPVer.

 

I'm afraid I can't be of much help. I can read the core.vbs but I don't understand everything in it.

Hmmm.. It boils down to 'On Error Resume Next', so this call just hides another problem.. :/

 

I see what you mean, the "on error resume next" in vpminit must ignore a variable error later in the core.vbs.

[wrd1972]

Toxie, Fuzzle,

It is possible to have a new parameter for lights?

 

I have a case where I am using lights under the playfield with transmit, but the transmit is reaching my plastics (prims) and causing nasty hotspots:

 

This is happening when my plastics are set to dynamic render only. If I set them to static render then issue is gone, but I do not want this. I must have a dynamic render for my flasher effects to look correct.

 

My question.

Might it be possible to have a "Transmit Max. Height" setting" for the lights? So if a light were at 0 units high, and the Transmit Max height setting were set to 10 units high. Then the lights transmit effect would only show up to 10 units high, and not beyond? I have run into plenty of occasions in the past where this feature would have resolved a minor problem. But now I have hit a big roadblock, and something like this would easily resolve it. Plus this would make fine tuning the lighting much better for the occasions where you do use transmit to shine through objects.

 

Hoping you guys can pull a rabbit out of the hat on this one.

Edited by wrd1972, 19 July 2020 - 12:30 AM.

[bord]

This is a great idea. Would love to see it implemented but heck I'd also just love to skip straight to the eventual graphic engine overhaul. Curse my impatience. Thanks for all the work, guys.

[toxie]

No, similar to the SSR, this is too simple/fast of an effect to be tweaked for height, sorry.  :/

[toxie]

Hmmm.. It boils down to 'On Error Resume Next', so this call just hides another problem.. :/

 

I see what you mean, the "on error resume next" in vpminit must ignore a variable error later in the core.vbs.

Got it. Its actually a bug in the controller.vbs that was just revealed by the changes. Fix will be in next update.

[rothbauerw]

I think the drop target issue can be solved in a much easier way than what's been proposed previously here.  As I see it, the issue is that drop targets are handled the same as walls.  The ball can't currently pass through the point of contact, it immediately rebounds.  In reality, the ball should only have a small force imparted on it on contact.  Just enough to overcome the force of friction allowing the drop target to drop.  In most cases, the ball will continue along it's original path (or very similar path) with slightly less momentum and either hit the wall/rubber behind it or an adjacent target.  Here is a good video showing how a drop target works.  You can also see in the video that the ball passes through the drop target after contact.

 

https://www.youtube....h?v=0DNPlxCv2V8

[fuzzel]

The problem isn't that the balls doesn't move too much into a drop target. It's an issue how were detect hit events at all. The physics engine checks for each ball if it hits an element and then it calculates the rebound and hit events for that element. Once a single it was detected it stops for checking other potential hits of near by elements and that's what happens for target banks. The ball hits a target and that's it. Even if the ball would hit two targets at the same time just one of the targets is used for further calculation.
Changing the engine to support multiple hit detection would be a big change and could have an impact on backward compatibility.

[rothbauerw]

The problem isn't that the balls doesn't move too much into a drop target. It's an issue how were detect hit events at all. The physics engine checks for each ball if it hits an element and then it calculates the rebound and hit events for that element. Once a single it was detected it stops for checking other potential hits of near by elements and that's what happens for target banks. The ball hits a target and that's it. Even if the ball would hit two targets at the same time just one of the targets is used for further calculation.
Changing the engine to support multiple hit detection would be a big change and could have an impact on backward compatibility.

 

Actually this is precisely the issue ... that ball doesn't continue to move through the target.  The odds of the ball hitting both targets simultaneously are infinitesimal.  It will hit one first, continue to move along it's path, then hit the second.  It may appear as though it's hitting them simultaneously, but it's not.  There are micro or milliseconds between collisions.  If VP is treating a target as rigid and the ball is not allowed to continue to move along it's original path, it will never hit the second target.  I guarantee that if you change the collision calculation of the drop target to only reduce the momentum of the ball and not completely invert it, it will resolve this issue and we'll get the behavior we're looking for.  

[freezy]

@rothbauerw The problem is that then the ball goes right through the target if there's not another collider behind. Technically like VPX calculates collisions it's a pretty major change as well, since the ball collides with the nearest collider, which would probably be the same collider again, because while in the real world the target that was hit would move a little, colliders in VPX are static, so it wouldn't move and trigger the collision again (as opposed to the target next to it, which is would be the goal).

[rothbauerw]

Here's a sample table.  I took my Big Shot table and converted the nfozzy rubber dampeners to have a negative coefficient for the drop targets, so this is effectively an inverted elasticity.  It will reduce the momentum of the ball, but allow it to continue to along it's original path.  This would be a little more realistic if the drop targets didn't register hits to the sides of the target.  But you should be able to get the concept.

 

https://www.dropbox....T Demo.vpx?dl=0

Edited by rothbauerw, 19 July 2020 - 10:03 PM.

[rothbauerw]

@rothbauerw The problem is that then the ball goes right through the target if there's not another collider behind. Technically like VPX calculates collisions it's a pretty major change as well, since the ball collides with the nearest collider, which would probably be the same collider again, because while in the real world the target that was hit would move a little, colliders in VPX are static, so it wouldn't move and trigger the collision again (as opposed to the target next to it, which is would be the goal).

 

I don't see this as a problem.  This is what would happen in the real world ... the ball passing through the drop target and hitting whatever's behind it.  Once the original collision occurs, the drop target is dropping out of the way, so there shouldn't be a second collision with the target.  In my sample above, the target becomes non-collidable/drops out of the way.

 

Granted, in a high velocity collision, it may be possible that the drop target could "bind" and act as a more rigid body, not allowing the ball to pass through.  But I see that as a boundary case.

[rothbauerw]

Here is an updated version with a more accurate implementation.  I added a second drop target object for each drop target to simulate appropriate physics on side hits to the target.  These are slightly wider than the original object and prevent the target from dropping on side hits and use the existing collision calculations for drop targets. 

 

The drop targets on this table now have very realistic behavior.  It's much more difficult, but still possible to drop multiple targets.  From what I've seen in my testing, multiple targets drop only in scenarios I would expect them to on the real table.

 

https://www.dropbox....Demo 2.vpx?dl=0

[fuzzel]

Roth what about to chim in and tweak the physics code in VPX ?

This physics stuff is above my head...

[rothbauerw]

Roth what about to chim in and tweak the physics code in VPX ?

This physics stuff is above my head...

 

What's the best way to help?  I don't think I'd be to do the actual coding.  Would psuedo code or specifications be sufficient?  

[jpsalas]

Another small bug: the Export Mesh button doesn't work. (the save window doesn't pop up)

[Segovia11]

Dear

[fourbanks]

this latest update 10. 7_beta_rev4224 update has messed up the table cyclone so have uninstalled it. 

[Thalamus]

@fourbanks : This is beta. It is meant to break things. It is ok for you to report issues related to it. But, the way you express it, it sounds like your not fully grasping that this is not meant for regular game play. Sure, maybe Cyclone needs an update for some bug that has been fixed, OR, the devs need to figure out the issue. But, please, change the tone of the report. We don't need the extra info about you being unhappy and have uninstalled it. You clearly should not be running 10.7beta in the first place.