4027 replies to this topic

[fuzzel]

The bottom bar does not display the correct position of the mouse pointer, the reading error value varies with zoom.
 
Primitives: it is not easy to change the number of Legacy/Sides, it does not have an immediate effect, after a few maneuvers it updates itself,
TransY and TransZ, any value used then becomes 100 and it is not possible to change it.

Thanks for the hint. Never thought that someone is still using the old legacy primitive

[kiwi]

When you try something, you have to tweak with all the knobs and buttons.

 
For the Dimensions Manager.
From a discussion I had at VPB,
it seems that Data East tables up to Hook, the length of the playfield is 42 inches, the tables after are 46 inches long.
Secret Service measures 107cm X 51.5cm.

 
Star Trek 25th is a little longer 42-5 / 8, with an error of +/- 1/4 of an inch.

[bord]

I have dimension manager changes, too.

 

Williams EM playfields are 20.25" x 42".

[bill777]

works with VPVR 10.06 ?

[rothbauerw]

 

The walls in the image are there to stop the ball from falling through the cut outs? Are they still set to collideable? Are they placed below the PF (-0,02)?

I tried that trick on one table that I've already reported to Fuzzel, I created a pf mesh, had the ball fall through at the plunger, created a wall that was supposed to fix that, but, didn't work either. So, this is not 10.7 only related. I don't think I ever solved it and didn't roth talk something about ball mass related to pf meshes ? Was that fixed ?

 

 

This has not been fixed.  I've been putting walls under my playfield meshes and seems to be an acceptable work around for the time being.  I do think this should be a priority though as I'm sure this is messing with proper physics behavior in a number of scenarios.

[bord]

 

 

The walls in the image are there to stop the ball from falling through the cut outs? Are they still set to collideable? Are they placed below the PF (-0,02)?

I tried that trick on one table that I've already reported to Fuzzel, I created a pf mesh, had the ball fall through at the plunger, created a wall that was supposed to fix that, but, didn't work either. So, this is not 10.7 only related. I don't think I ever solved it and didn't roth talk something about ball mass related to pf meshes ? Was that fixed ?

 

 

This has not been fixed.  I've been putting walls under my playfield meshes and seems to be an acceptable work around for the time being.  I do think this should be a priority though as I'm sure this is messing with proper physics behavior in a number of scenarios.

 

I'll second this request. I have quite a bit of confidence in the veracity of the playfield meshes in question. They have normals facing correctly, geometry is as properly supported as you'd expect it to be on a flat surface with a bunch of curved cutouts.

[jpsalas]

 

Hi,

 

maybe it is this behaviour, we had in VPX10.6 and maybe earlier too. Once You control a gate manually, the visuals are broken.

After a hard hit the gate stays visually open but is closed for the ball.

 

 

I think that's expected - the move function is intended for scripted gates.  Once you touch it, the gate relinquishes its visuals to the script.    Otherwise you'd have the script and the physics fighting with each other for what to show. 

It's even described that way in the code comments:

STDMETHODIMP Gate::Move(int dir, float speed, float angle) //move non-collidable gate, for graphic effects only

I think altering this behavior is dangerous now as it would affect backward compatibility.   But perhaps a new function could be added to reset 

  m_phitgate->m_gateMover.m_forcedMove = true;
 

back to false, resuming regular VP-controlled movement...

 

-- Rob 

 

 

But it was not like this on older VP versions. Even in VP995 it works as entended. I don't know when it started to get stuck, but it must be bug.

[sliderpoint]

Talking about gates...  can we break the visual link between length and height on these.  When you make a wide gate (ie: length 200) the gate also gets taller (visually) so it hangs down into the playfield.  Spinners do this too.

 

Thanks for your hard work.

-Mike

[fuzzel]

 

 

The walls in the image are there to stop the ball from falling through the cut outs? Are they still set to collideable? Are they placed below the PF (-0,02)?

I tried that trick on one table that I've already reported to Fuzzel, I created a pf mesh, had the ball fall through at the plunger, created a wall that was supposed to fix that, but, didn't work either. So, this is not 10.7 only related. I don't think I ever solved it and didn't roth talk something about ball mass related to pf meshes ? Was that fixed ?

 

 

This has not been fixed.  I've been putting walls under my playfield meshes and seems to be an acceptable work around for the time being.  I do think this should be a priority though as I'm sure this is messing with proper physics behavior in a number of scenarios.

 

Do you have a simple example table to play around with? I mean really a simple one because loading and interacting with a full featured table is really annoying under debugger conditions.

Talking about gates...  can we break the visual link between length and height on these.  When you make a wide gate (ie: length 200) the gate also gets taller (visually) so it hangs down into the playfield.  Spinners do this too.

 

Thanks for your hard work.

-Mike

Yeah I know. The point is that if you scale a spinner/gate with separate scale values it breaks the aspect ratio and won't behave correctly anymore. I think about something like in FP where you can use special designed primitives for pinball elements but that stuff isn't compatible to the current VP behaviour so it must wait until VP11.

The bottom bar does not display the correct position of the mouse pointer, the reading error value varies with zoom.

 
Primitives: it is not easy to change the number of Legacy/Sides, it does not have an immediate effect, after a few maneuvers it updates itself,
TransY and TransZ, any value used then becomes 100 and it is not possible to change it.

The issue with legacy primitives will be fixed in the next version. But can you give a bit more details about the mouse position? What do you mean with error value varies with zoom?
 

[Pin-Pete]

Ooooh yeah! Freak out! Thank you so much for your hard work. Patiently waiting, what's coming around the corner. 

[rothbauerw]

 

 

 

The walls in the image are there to stop the ball from falling through the cut outs? Are they still set to collideable? Are they placed below the PF (-0,02)?

I tried that trick on one table that I've already reported to Fuzzel, I created a pf mesh, had the ball fall through at the plunger, created a wall that was supposed to fix that, but, didn't work either. So, this is not 10.7 only related. I don't think I ever solved it and didn't roth talk something about ball mass related to pf meshes ? Was that fixed ?

 

 

This has not been fixed.  I've been putting walls under my playfield meshes and seems to be an acceptable work around for the time being.  I do think this should be a priority though as I'm sure this is messing with proper physics behavior in a number of scenarios.

 

Do you have a simple example table to play around with? I mean really a simple one because loading and interacting with a full featured table is really annoying under debugger conditions.

 

 

Here you go.  Just cradle the ball on one of the flippers and you'll see it start to fall into the playfield.

 

https://www.dropbox....tTable.vpx?dl=0

[fuzzel]

 

 

The walls in the image are there to stop the ball from falling through the cut outs? Are they still set to collideable? Are they placed below the PF (-0,02)?

I tried that trick on one table that I've already reported to Fuzzel, I created a pf mesh, had the ball fall through at the plunger, created a wall that was supposed to fix that, but, didn't work either. So, this is not 10.7 only related. I don't think I ever solved it and didn't roth talk something about ball mass related to pf meshes ? Was that fixed ?

 

 

This has not been fixed.  I've been putting walls under my playfield meshes and seems to be an acceptable work around for the time being.  I do think this should be a priority though as I'm sure this is messing with proper physics behavior in a number of scenarios.

 

I tried the TZ Skitso mod playfield_mesh. I copied the mesh to the example table but I can't see that the ball is falling through the playfield. However if I set the factor to 1 for reducing the poly count (in the physics tab) I can see this immeadately. The collision code for a playfield mesh is the same as for every other collidable primitive. But when you reduce the details of a mesh with that option in the physics tab of the primitive properties you will get this issue soon or later even with a factor of 0.1.

So I think it's a precision thing when you reduce the polys because the hitmesh is also reduced by this option.

[fuzzel]

 

 

 

 

The walls in the image are there to stop the ball from falling through the cut outs? Are they still set to collideable? Are they placed below the PF (-0,02)?

I tried that trick on one table that I've already reported to Fuzzel, I created a pf mesh, had the ball fall through at the plunger, created a wall that was supposed to fix that, but, didn't work either. So, this is not 10.7 only related. I don't think I ever solved it and didn't roth talk something about ball mass related to pf meshes ? Was that fixed ?

 

 

This has not been fixed.  I've been putting walls under my playfield meshes and seems to be an acceptable work around for the time being.  I do think this should be a priority though as I'm sure this is messing with proper physics behavior in a number of scenarios.

 

Do you have a simple example table to play around with? I mean really a simple one because loading and interacting with a full featured table is really annoying under debugger conditions.

 

 

Here you go.  Just cradle the ball on one of the flippers and you'll see it start to fall into the playfield.

 

https://www.dropbox....tTable.vpx?dl=0

 

I don't get it...I can see any problems here. I cradle the ball with one of the flippers and the balls stays totally still and won't fall into the playfield. I tested with the latest build.

[rothbauerw]

 

 

This has not been fixed.  I've been putting walls under my playfield meshes and seems to be an acceptable work around for the time being.  I do think this should be a priority though as I'm sure this is messing with proper physics behavior in a number of scenarios.

 

 

I tried the TZ Skitso mod playfield_mesh. I copied the mesh to the example table but I can't see that the ball is falling through the playfield. However if I set the factor to 1 for reducing the poly count (in the physics tab) I can see this immeadately. The collision code for a playfield mesh is the same as for every other collidable primitive. But when you reduce the details of a mesh with that option in the physics tab of the primitive properties you will get this issue soon or later even with a factor of 0.1.

So I think it's a precision thing when you reduce the polys because the hitmesh is also reduced by this option.

 

 

It happened on TZ with the Powerball, which had a mass of 0.8.  It also happens with a ball of mass 1, but you can't see it visually.  If you cradle the ball and post the z position in the debug window, you can see it starts to sink slightly into the playfield.  If I recall correctly, it was something like 0.3 vp units.  Different conditions can cause it to fall deeper and sometimes completely through the playfield.

 

 

Here you go.  Just cradle the ball on one of the flippers and you'll see it start to fall into the playfield.

 

https://www.dropbox....tTable.vpx?dl=0

 

I don't get it...I can see any problems here. I cradle the ball with one of the flippers and the balls stays totally still and won't fall into the playfield. I tested with the latest build.

 

 

Confirmed.  I'm not seeing it on the latest build either.  I know we were fiddling with the physics in previous builds, but I thought everything got pulled out.  It's definitely behaving differently than 10.6 final.  I'll do some more testing when I have a little time to see if it's resolved.

[Slydog43]

I want to give back, any devs live near NJ (I have some extra bartop cabs I have build during lockdown) I think toxie and fuzzel are both german?  anyone in need in NJ?

[kiwi]

The mouse pointer is not printed in the screenshot, but I can guarantee that the tip is in the center of the highlighted primitive (more or less),

the position indicated in the bar is 16-17 units of difference compared to the real position, this difference decreases if you zoom in more.

 
The elements pointer also does not put objects where it indicates the +.

 

 

Thanks.

Edited by kiwi, 03 May 2020 - 10:01 AM.

[fuzzel]

The mouse pointer is not printed in the screenshot, but I can guarantee that the tip is in the center of the highlighted primitive (more or less),
the position indicated in the bar is 6-7 units of difference compared to the real position, this difference decreases if you zoom in more.
 
The elements pointer also does not put objects where it indicates the +.
 

 
Thanks.

That's a known behavior and is the same in every version of VPX. The mouse pointer has a higher precision than the drawings in the editor. If you place a wall with a corner point at 0/0 and zoom into that point you will see that the coordinates of the mouse pointer is somewhat near to 0/0 but not 100% 0/0. This behavior wasn't changed I 10.7 at all.

I want to give back, any devs live near NJ (I have some extra bartop cabs I have build during lockdown) I think toxie and fuzzel are both german?  anyone in need in NJ?

German we are yes my young padawan

Edited by fuzzel, 03 May 2020 - 09:23 AM.

[kiwi]

 

The mouse pointer is not printed in the screenshot, but I can guarantee that the tip is in the center of the highlighted primitive (more or less),
the position indicated in the bar is 6-7 units of difference compared to the real position, this difference decreases if you zoom in more.
 
The elements pointer also does not put objects where it indicates the +.
 

 
Thanks.

That's a known behavior and is the same in every version of VPX. The mouse pointer has a higher precision than the drawings in the editor. If you place a wall with a corner point at 0/0 and zoom into that point you will see that the coordinates of the mouse pointer is somewhat near to 0/0 but not 100% 0/0. This behavior wasn't changed I 10.7 at all.

I want to give back, any devs live near NJ (I have some extra bartop cabs I have build during lockdown) I think toxie and fuzzel are both german?  anyone in need in NJ?

German we are yes my young padawan

 

I only wrote 6-7-units, but in reality they are 16-17 units.
In previous VP versions the position of the pointer is correct, also the pointer of the elements,

with the exception of the elements that were added later, such as primitives, flashers and rubbers.

[toxie]

it seems that Data East tables up to Hook, the length of the playfield is 42 inches, the tables after are 46 inches long.

Secret Service measures 107cm X 51.5cm.

 
Star Trek 25th is a little longer 42-5 / 8, with an error of +/- 1/4 of an inch.

Where is this info from? Did you measure yourself? Cause there is so much conflicting info out there for all those playfields..  :/  Thanks!

I have dimension manager changes, too.

 

Williams EM playfields are 20.25" x 42".

Same question here. 

[toxie]

 

 

 

The walls in the image are there to stop the ball from falling through the cut outs? Are they still set to collideable? Are they placed below the PF (-0,02)?

I tried that trick on one table that I've already reported to Fuzzel, I created a pf mesh, had the ball fall through at the plunger, created a wall that was supposed to fix that, but, didn't work either. So, this is not 10.7 only related. I don't think I ever solved it and didn't roth talk something about ball mass related to pf meshes ? Was that fixed ?

 

 

This has not been fixed.  I've been putting walls under my playfield meshes and seems to be an acceptable work around for the time being.  I do think this should be a priority though as I'm sure this is messing with proper physics behavior in a number of scenarios.

 

I tried the TZ Skitso mod playfield_mesh. I copied the mesh to the example table but I can't see that the ball is falling through the playfield. However if I set the factor to 1 for reducing the poly count (in the physics tab) I can see this immeadately. The collision code for a playfield mesh is the same as for every other collidable primitive. But when you reduce the details of a mesh with that option in the physics tab of the primitive properties you will get this issue soon or later even with a factor of 0.1.

So I think it's a precision thing when you reduce the polys because the hitmesh is also reduced by this option.

 

Good catch! The polygon reduction algorithm is NOT optimized to keep silhouettes constant, so things like holes can degenerate pretty quickly (i.e. also grow larger than expected). I think i will force playfield meshes to always run at full hit mesh precision then? Or should i still leave it to the authors??