1002 replies to this topic

[Sunskift]

I finally found the currage to test physmod4 with melons cftbl. It is GREAT !!!!

This update of VP is better than I ever could have expected, even if I have followed the development closely.

 

I however run in to a snag that I can't resolve. Probably I missed something that I should have done, but I can't find it in this thread or any other.

 

In the outer loop, when the ball is about to come back in to the left side it gets stuck.

 

 

When I nudge, the ball moves but it falls back in the stuck position.

 

I have not seen this reported before, but it maybe is a known issue.....

 

 

Anyway, I can't wait until VP10 gets released - I have, so to say, got the flavor of that's to come !

 

Thans !

 

[BigBoss]

Drop back to physmod2 and the stuck ball should be ok.

[jim5six]

Does anyone else have the same problem as i have? The ball gets stuck in the top left corner lower loop. I see in the script that the Ball Const is commented out. If I uncomment it and adjust the ball to a ridiculously small size it doesn't get stuck. I have made some adjustments to the table parts to try to resolve this but have not been able to figure it out (I have no real expertise in this area). Any help would be appreciated.

Thanks, Jim 

 

This should be a treat, Melon's CFTBL in an extensively tuned physics mod version by UncleWilly. He says

 

This is close to the real table of my friend. The ramp and the whirlpool bowl behave extremely close to the real thing with these settings.

 

I haven't had the time to try it, but I trust it's great. Thanks to both Melon and UW for their work on this!

Sorry,  I see I am not the first with this issue.Thanks BigBoss for the reply.

 

-Jim 

[speedboatz]

This is awsome!!! cftbl never played as accurate as this.

[mukuste]

Drop back to physmod2 and the stuck ball should be ok.

 

I know it's tempting to take the easy way out but I need to say that if everyone just sticks to some old version and doesn't test the latest releases, then this whole thread becomes kind of pointless. Without proper testing, we'll have a buggy VP10 release.

[BigBoss]

Drop back to physmod2 and the stuck ball should be ok.

 
I know it's tempting to take the easy way out but I need to say that if everyone just sticks to some old version and doesn't test the latest releases, then this whole thread becomes kind of pointless. Without proper testing, we'll have a buggy VP10 release.

This is a very good point. The problem is that with the latest collision changes, only about 25% of the tables that worked on physmod2 work in physmod4. Almost every game with a ramp has some problems now. The only way to really report this is to make a test table to reproduce. But I can't ever reproduce that way. On some tables I've analyzed, the ball seems to hit nothing and reacts to it. Like I right click in the area it reacts and zoom and there's nothing collideable there. Unless you're interested in links to converted tables with a ramp number and some instruction, I'm not sure how I can help on some of these. I figured its going to require some table authors to sort out some of these problems.

[unclewilly]

I've almost completed fire!
Once I'm finished with it I'll convert it to use the new physics and put some time into testing.
I have a 2 year old and 2 jobs, so my time is rather limited.

[mukuste]

 

 

Drop back to physmod2 and the stuck ball should be ok.

 
I know it's tempting to take the easy way out but I need to say that if everyone just sticks to some old version and doesn't test the latest releases, then this whole thread becomes kind of pointless. Without proper testing, we'll have a buggy VP10 release.

This is a very good point. The problem is that with the latest collision changes, only about 25% of the tables that worked on physmod2 work in physmod4. Almost every game with a ramp has some problems now. The only way to really report this is to make a test table to reproduce. But I can't ever reproduce that way. On some tables I've analyzed, the ball seems to hit nothing and reacts to it. Like I right click in the area it reacts and zoom and there's nothing collideable there. Unless you're interested in links to converted tables with a ramp number and some instruction, I'm not sure how I can help on some of these. I figured its going to require some table authors to sort out some of these problems.

 

 

Some pointers to help in debugging tables:

If you can't outright copy and paste the offending geometry into a new table, set up an automatic kicker in the relevant area so that you can test very quickly without having to start the game and hit the relevant spot every time.

Once you can reproduce the issue in this way, you can start removing individual elements (or disabling their Collidable flag).

This way you should be able to narrow down where the problems actually occur.

 

I don't think the ball should ever get caught in an empty area, but if it does, it's certainly a major bug and I'd be interested in the tables where this happens.

 

 

I've almost completed fire!
Once I'm finished with it I'll convert it to use the new physics and put some time into testing.
I have a 2 year old and 2 jobs, so my time is rather limited.

 

Awesome! No worries, the amount and quality of the stuff you put out is impressive, especially with the other duties you have.

So much of my own time is being taken up with commuting right now, this will get better once I have a decent place to move into...

[boiydiego]

 

Drop back to physmod2 and the stuck ball should be ok.

 

I know it's tempting to take the easy way out but I need to say that if everyone just sticks to some old version and doesn't test the latest releases, then this whole thread becomes kind of pointless. Without proper testing, we'll have a buggy VP10 release.

 

before reading the message of you muskuste to the post , i was think in exact the same way , it is realy pointless to do that you wont help muskuste in his work he is doing he must have feedback .. and i done that sending him a pm

Edited by boiydiego, 16 May 2014 - 07:12 PM.

[BigBoss]

So Mukuste, if I take an existing table, not a test table, and stick a kicker in so you can plunge and see the problematic area immediately, you'll be ok with that? I've already disabled everything collideable. There's just nothing there that I can see. It would be helpful if we could enter debug mode and get data on the ball such as its current size and height by clicking on it. On this one table. The ball should be rolling on the pf but it magically hits nothing. The only object in that area is a non-collidable object about 200 units in the air.

[mukuste]

Sure, let me see that.

[Nemo]

Unclewilly wrote:

 

I have a 2 year old and 2 jobs, so my time is rather limited. 

 

Man, and you keep on building all those great tables, do you EVER sleep ? 

 

Kudos to you !

Edited by Nemo, 17 May 2014 - 04:12 PM.

[JavaJack]

Here's a skeleton table that might be useful for debugging collisions in physmod:

http://wookilar.com/vp/x-men.zip

 

Sometimes the ball falls through the table and disappears when it reaches the bottom of the left habitrail. I also had a LOT of difficulty plunging the ball until I removed the walls on the ramp in the shooter lane. The ball would also act weird around where the Cyclops lane dumps into the Phoenix lane, like it was penetrating some of the thin walls.

 

I put this table skeleton together to test physmod simply because there are several good YouTube videos of gameplay, such as , and because there's an X-Men machine in a neighborhood wing joint not too far from my house, so I could have a real basis of comparison. I have no intention of doing any further work on it. It's just meant for physmod testers out there to play with physics settings while watching the videos to figure out some realistic values. One caveat is there was no simple way to cut the giant rectangular hole for the Blackbird scoop. Hopefully someone will find it useful.

[BigBoss]

Ok after a ton of playtime with the physmod stuff, I'm pretty impressed. But some areas where it can improve when comparing to real pinballs. When analyzing this, I'm purely analyzing flippers right now.

Flippers feel slightly lagged. Not a lot. But if you play a real game then go back to VP, there's a super small adjustment. I am wondering what the latency is with VPM. A single frame is 16.67ms. When the flippers are hit, a switch closure is sent to vpinmame and the flipper moves in the callback of the solenoid. If there are a couple timer cycles for this, perhaps some of that can explain some of the lag. I might modify a table so that the flipper buttons are directly controlled without pinmame and compare.

Second, flipper backhands from a stopped ball on the flipper have a lot more strength on a real pin. There are several tables where you can easily backhand ramps but its very hard in VP. It helps if you increase the flipper angles a bit. But then you get into a situation where its super easy to capture the ball on the flipper by just holding it up. I'm not sure what properties of real flippers would allow for easier backhanding.

I'd like to get VP compiling again on my system so I could maybe tweak some of these values and test and report back what values seem to work the best.

Mukeste: I have modified this judge dredd table to show the physmod4 problem that didn't exist in physmod2. I moved the ball release up into the right orbit so it releases the ball down. It's very easy to see. Just hit start, and the ball immediately is in play. If you let it drain the ball saver will immediately kick out another and repeat. As the ball comes down, it hits a wall and bounces outward. When you shoot the ball using the left flipper into the loop the other way, it travels very smoothly. The ball travels smoothly in physmod2 (you can use both to compare). In physmod4, it bounces.

I have looked into it a lot more and Ramp658 is the cause. But I think there's a height but somewhere. The ball is on the surface of the playfield. The ramp height is 0.5 bottom to 105 top, and it is near the very top where the problem occurs. It should be way above 50 at that point. The ramp only has two points. Does adding more points modify the height spread algorithm? Shortening this ramp a tiny bit and lengthening ramp924 to compensate solves the problem, but it feels like it shouldn't have to be done.

The table is here to examine: http://pinballbulbs....edreddbouce.zip

Edit: simply right clicking on Ramp658 and selecting "add point" solves the problem. That creates another segment in the ramp and must do something to recalc the height values internally. This really feels like a bug.

Edited by BigBoss, 18 May 2014 - 03:24 AM.

[mukuste]

Here's a skeleton table that might be useful for debugging collisions in physmod:

http://wookilar.com/vp/x-men.zip

 

Thanks! This was very useful, it has already allowed me to track down and fix the longstanding "ball through playfield" bug when exiting ramps. I'll look into the other issues too when I have time; which one is the Cyclops lane?

[mukuste]

BB: Thanks. I took 10 minutes to trim out all the fat, I could reduce it to just the wall and the ramp:  Judge Dredd-physmod-bug.vpt   2.72MB   9 downloads

 

Now to look into what's actually happening.

[BigBoss]

I'll take a look at the stripped down table and see what you did. Maybe it'll help me do the same in the future.

Here's a skeleton table that might be useful for debugging collisions in physmod:
http://wookilar.com/vp/x-men.zip

 
Thanks! This was very useful, it has already allowed me to track down and fix the longstanding "ball through playfield" bug when exiting ramps. I'll look into the other issues too when I have time; which one is the Cyclops lane?

From the right side of the play field it goes right orbit, right ramp, cyclops lane.

Edited by BigBoss, 18 May 2014 - 10:21 AM.

[mukuste]

BB: Thanks. I took 10 minutes to trim out all the fat, I could reduce it to just the wall and the ramp: Judge Dredd-physmod-bug.vpt

 

Now to look into what's actually happening.

 

It's fixed -- I messed up the height calculation of the start/end posts on the ramps.

I'll take a look at the stripped down table and see what you did. Maybe it'll help me do the same in the future.

 

 

Basically, generous use of the rectangle tool and the Delete key Also clear out the script and just leave in the stuff to create a ball in the kicker. And I removed all the textures in the Image Manager to reduce the file size.

Edited by mukuste, 18 May 2014 - 11:06 AM.

[BigBoss]

It's fixed -- I messed up the height calculation of the start/end posts on the ramps.

Very awesome Think you could do a quick physmod5 compile? I'd like to start running it through the big mess of tables I have and see how it does.

Edited by BigBoss, 18 May 2014 - 11:09 AM.

[mukuste]

Sure, why not. I don't think it will fix all your problems since this was a new bug in phymod4 and you already had many problems in physmod3, but let's see how it shakes out.