157 replies to this topic

[3rdaxis]

Thanks Dan, Yep you have it exactly right. I have raised the physical glass primitive higher then usual to sort of exaggerate the Z movement to make it a bit more noticeable. 

 

The velocity of the z applied could also reflect the velocity of the incoming impact and be applied to the appropriate "GlassHit" sound being softer or louder instead of random. 

 

There are so many ways to do randomness and a lot of variables to adjust for sure. Feedback from the community will most likely steer me to include an option to adjust the frequency of hits. 

 

Feel free to make any changes to the table and send it over, I'd be more then happy to check it out. 

Edited by 3rdaxis, 09 January 2019 - 02:19 PM.

[bord]

 

Feedback from the community will most likely steer me to include an option to adjust the frequency of hits. 

 

 

Yes, please. Increased probability of a glass hit based on velocity would be my vote. Would love to see this implemented.

[3rdaxis]

But who oh who will test it?

[bord]

But who oh who will test it?

 

If I were the kind of person that really liked pinball and really like my virtual pinball playing like real pinball I would volunteer. But alas...

 

Just kidding. PM me if you need some hands on this thing. My son and I love to test games on weekends.

[The Loafer]

@theloafer : I can relate. But, about lighting. This table was released pre the latest beta that you say you are running. I think you really should try a few different betas back to see if it maybe doesn't fit you better. Especially the latest release changed the lighting on this table - for me, significantly. I think it looked better before.

 

The only lighting comment I meant was for the 3 bonus lights (10/30/50K).  The overall lighting looks great on my setup and on 10.5 and the first 10.6 beta that I had installed.  I can't complain on the general lighting, I think it looks fantastic

3rdAxis: I'm unfortunately VERY AVAILABLE the next two weeks so if you need someone I can assist.  In saying that, I doubt you can do better than Bord so if he's on the job, you've found your guy with him as he's evil in all the right ways when it comes to pinball design and development (virtual but I suspect would be the same with a real world pin design).  I say unfortunately because I was supposed to step onto a cruise liner Friday morning but heath issue is keeping me at home so... I'm available to test! LOL

 

*grumble grumble* cruise isn't cancelled for others though *grumble grumble*

[3rdaxis]

*grumble grumble* cruise isn't cancelled for others though *grumble grumble*  

[The Loafer]

3rdaxis:  I noticed you've set the Z scale different than the normal 1.0 we usually see (you have it set to 0.912001).  Usually we see this set to 1 and everyone is told "don't change it as it can mess with the physics".  My brain can't quite get around why a camera position would affect physics but whatever that's not really my comment  lol.   earlier in the thread another member (Aubrel) provided a different camera view however the z scale was set to 1, so different than your own.  I would be concerned from past forum posts that this could then mess the physics in your table.  So finally my question:  do you know since you've worked on this table so much if a change of zscale may affect the playability of the table?  Even though it's a generic VPX question, in essence your use of something other than 1.0, and everyone's ability to change the camera position means that many may inadvertently change this delicate setting and then mess how it plays.  That would be a shame.

 

@Toxie and @Fuzzel:  your opinion would be welcome.  I think I asked this on another forum but don't recall seeing a response so...:  why the heck is this z scale setting just not lockable if it messes with the tables physics, as everyone believes?  Why does a camera setting affect physics?  Also, why can't I have more money to spread cheer throughout the world, and buy me more man toys?

[Thalamus]

I might be wrong on this one. But, what I believe for the z-scale is that it changes elements in some way. Call it a bug or whatever. If you make a table and from the beginning set z-scale to 0.5 or whatever. You will not get into troubles since you can adjust the elemnts to fit that scale. But, after, that is when it gets hairy ?! If you look at some of the FFS tables. z-scale is changed from the original. So, yeah, I agree. It would be beneficial to understand when and why we should not change it. I just know from experience that it can become a problem.

[fuzzel]

Well the z scale effects the hit shape and the height of hit targets, kickers, walls, rubbers and ramps. So it's not a simple scale factor only for the 3D meshes. The physics engine must know at which height the balls currently is to check with other hit shapes on the table. In the early stages when I added that scale factor I missed to apply the scaling to ramps and the result was that the ball intersects the ramp because the ball height was wrong.

Do you have an example table that shows issues when you use the z-scaling? Maybe we can fix that but I was not aware of a problem here. The only thing I could think of is if you raise the z-scale factor too much (over 2.0 or so).

[Thalamus]

No. I personally don't since I leave that scaling alone. I've seen quite a lot of "support" cases out there where the resolution was to download the table again - changing what you liked except the z-scale. So, I haven't tested it in ages to be honest. If z-scale changes is really an option I could get what I would describe as a much better 3d view than what I use today.

 

Guess I have to re-visit and try again.

[The Loafer]

Thanks for the reply fuzzel, I now understand why. Although I can't think of a specific example, it has come up numerous times in the past as Thalamus indicated, where balls get stuck, etc and the fix was "don't mess with zscale dude!" . Next time it comes up, we will send you the link

[rothbauerw]

Z scale is most noticeable on rubber physics. I had z scale set to 1.4 on my first table I built (Star Trek Bally) and when I changed it, the game play completely changed. I don't know if it's less of a problem now that rubbers have a hit height setting?

Question, did the bug that causes only half of fire and power to light up get identified yet?

[The Loafer]

Z scale is most noticeable on rubber physics. I had z scale set to 1.4 on my first table I built (Star Trek Bally) and when I changed it, the game play completely changed. I don't know if it's less of a problem now that rubbers have a hit height setting?

Question, did the bug that causes only half of fire and power to light up get identified yet?

 

yes ensure "reflect dynamic elements on playfield" is enabled in video preferences

 

thanks for the zscale comment, that helps surely

Edited by The Loafer, 11 January 2019 - 04:20 AM.

[rothbauerw]

 

yes ensure "reflect dynamic elements on playfield" is enabled in video preferences

 

thanks for the zscale comment, that helps surely

 

 

I have this checked in video preferences.  I still only see half of fire and power.  If I enable playfield reflections, I see the entire light, but then I get stutter.

[3rdaxis]

 

 

yes ensure "reflect dynamic elements on playfield" is enabled in video preferences

 

thanks for the zscale comment, that helps surely

 

 

I have this checked in video preferences.  I still only see half of fire and power.  If I enable playfield reflections, I see the entire light, but then I get stutter.

 

Do you have In-game AO turned on or any sort of anti-aliasing?

 

[rothbauerw]

yes ensure "reflect dynamic elements on playfield" is enabled in video preferences
 
thanks for the zscale comment, that helps surely

 
I have this checked in video preferences.  I still only see half of fire and power.  If I enable playfield reflections, I see the entire light, but then I get stutter.
 
Do you have In-game AO turned on or any sort of anti-aliasing?

In-game AO is off. 4xBrute Force enabled. No other anti-aliasing.

[3rdaxis]

Turn 4xBrute Force off. There's the issue. You can use standard FXAA in video options and keep 4xAA (SSAA) set to "Default" under table/user customization, nothing more is necessary. I'm running a 14 year old 660TI GPU and it runs solid as a rock. 

Edited by 3rdaxis, 15 January 2019 - 06:15 PM.

[rothbauerw]

Yes, I could turn off Brute Force, but I will lose some quality.  Generally speaking, I prefer the quality I get with Brute Force at the expense of playfield reflections.  It's also not clear to me why disabling playfield reflections should impact insert lighting.  I could be wrong, but that seems like a "bug" to me.

 

@Toxie or @fuzzel 

 

Would be interested in your thoughts on this one.

[3rdaxis]

Yea your not going to get the performance with brute force turned on regardless of reflection status I believe, it's just too much. At least that's what I can tell on my end. As far as it impacting the inserts, what beta version are you running? This was built and made to run in Beta 10.6 rev. 3541, Until the next upcoming revision that will be Beta 10.6 rev. 3590. Anything else will most likely result in some artifacts. 

Edited by 3rdaxis, 15 January 2019 - 07:30 PM.

[rothbauerw]

I get absolutely no stutter on any of my tables as long as playfield reflections are off.  I'm not complaining in any way about the table, just seems like something VP should be able to handle and was curious if toxie or fuzzel were aware, and if so, if it's something that can be fixed.