616 replies to this topic

[cyberpez]

Yeah you can use primitive spinners just like a gate. We used one in BoP and I've also got one in BH..

[Shockman]

It seems to be all good, stable, and running well.

 

There is some weird things with the user interface, and I was hoping the triggers (analog buttons) could become assignable as to set a set of flippers to flip at any pull and another triggered at half press, but also to make it more like the other pinball simulations I play.

 

Someone should take a shot at having a setting option that would adjust the visible nudge to the physical nudge. The same kind of factor you just added for the flipper would work nicely if someone wanted an unrealistic visual response to a set nudge. I remind you that VP has always had this in the past (before 9).

 

The global visual response settings really makes no sense at all without some kind of simulated response as an option. The table can be made to move off screen visually, with barely a physical response, and it can be made to have a big physical response and show nothing. At least if it is not already possible, and I am missing it, please have that global visible shake that is in the global UI be settable for the table.vpx so nudging could be simulated in this simulation without the trial and error that is probably nothing but a quest for a realistic response by all trying to set it. You can save moving only the table and not, or not nearly as much, the backdrop, for 10.4 or future devs.

Edited by Shockman, 26 May 2017 - 01:55 AM.

[toxie]

What is still broken, the mouse cursor not showing up thing?

 

Nope.. In the UI dialog for the keys,etc, (at least) the enable nudge & enable mouse & disable B2S checkboxes cannot be changed (e.g. if you close and re-open it's still the same state)..

And as you did the win32++ conversion i hope you can spot the error more easily. For the first two there was already a typo, but apart from that i don't see why these 3 (or more??) should not work..  :/

[hanzoverfist]

Thx Toxie / Fuzzel for the great work you have both done on this release.

[playcade]

It is just an idea...I know nothing about coding. It would be great that when we get darker the playfield in the vpx editor to get the night mode, the b2s get darker too...wouldn´t it? ...In night mode , the backglasses are so different! look this picture: http://i.imgur.com/Y4IFMor.jpg

[toxie]

yup, but this would have to be done in the B2S component, and there nobody took over development so far.. :/

[nFozzy]

If you have time for a few more hacks Fuzzel. I've been working a lot on elasticity over the last couple of weeks and came up with some ideas for improvements.

 

There were 3 things I was after. I had most of them prototyped out in script to make sure the concepts did what I wanted them too. I wanted to experiment with the code more, but couldn't get it to compile in Visual Studio 14, and kind of gave up after that. Here they are:

 

1: Elasticity Falloff Threshold

 

I was pretty surprised to see how simple the elasticity falloff code was, It's one line of code that multiplies elasticity based on the speed of the ball. If elasticity falloff is just going to be an elasticity envelope like this I would like to have more control over how it goes about doing that. Having a threshold that offsets the falloff curve to the right is the simplest improvement I could think of. I made a quick script version of this kind of falloff, results were good, but it would work a lot better in code. JimmyFingers posted a similar suggestion awhile ago I think, I can't find the post atm.

 

2. Elasticity Falloff for wall objects

 

Tuning Elast. falloff on rubbers has mostly just lead to frustration for me, but I gained a new respect for it on low-elasticity objects, such as metals and targets, which are a bit too sticky at low ball speeds otherwise. Falloff on walls would be a good addition.

 

3. Flipper Elasticity modifier when at rest

 

From what I can tell from the code, Flippers are treated as static for the purposes of collision when they're in their downward position. This means the floppiness of the flipper is just a visual effect, and not abstracted in the physics.

 

There are two really common types of drains off of flipper rubber: #1: Flipper up, ball hits the flipper and bounces directly into the outlane #2: Flipper down, the ball flops not-cleanly across to the other flipper, sending it into danger. Both of these drains are capable of happening on the same machine, so the difference in elasticity needs to be pretty significant.

 

I've found you can actually update Elasticity Falloff in the script (but only for flippers) which is awesome for this, but the bounces would be better if the change was in elasticity and not elasticity falloff.

 

...

 

Let me know what you think. I may have misunderstood the code in some places. Now that physics materials makes importing and exporting physics values much easier now, it's worth a bit of extra complication to get these bounces perfect. Should be a pretty realistic goal, compared to the task of getting lagless flippers on laggy displays (yikes!).

[Thalamus]

Interesting stuff. But, to me it sounds like changes that can't be made on the edge of a release. Both Toxie and Fuzzel asked for time off for real life stuff. Well, I'm not the right guy to answer this, but, I would be very surprised if this is added in the close window for 10.3.

[fuzzel]

If you have time for a few more hacks Fuzzel. I've been working a lot on elasticity over the last couple of weeks and came up with some ideas for improvements.
 
There were 3 things I was after. I had most of them prototyped out in script to make sure the concepts did what I wanted them too. I wanted to experiment with the code more, but couldn't get it to compile in Visual Studio 14, and kind of gave up after that. Here they are:
 
1: Elasticity Falloff Threshold
 
I was pretty surprised to see how simple the elasticity falloff code was, It's one line of code that multiplies elasticity based on the speed of the ball. If elasticity falloff is just going to be an elasticity envelope like this I would like to have more control over how it goes about doing that. Having a threshold that offsets the falloff curve to the right is the simplest improvement I could think of. I made a quick script version of this kind of falloff, results were good, but it would work a lot better in code. JimmyFingers posted a similar suggestion awhile ago I think, I can't find the post atm.
 
2. Elasticity Falloff for wall objects
 
Tuning Elast. falloff on rubbers has mostly just lead to frustration for me, but I gained a new respect for it on low-elasticity objects, such as metals and targets, which are a bit too sticky at low ball speeds otherwise. Falloff on walls would be a good addition.
 
3. Flipper Elasticity modifier when at rest
 
From what I can tell from the code, Flippers are treated as static for the purposes of collision when they're in their downward position. This means the floppiness of the flipper is just a visual effect, and not abstracted in the physics.
 
There are two really common types of drains off of flipper rubber: #1: Flipper up, ball hits the flipper and bounces directly into the outlane #2: Flipper down, the ball flops not-cleanly across to the other flipper, sending it into danger. Both of these drains are capable of happening on the same machine, so the difference in elasticity needs to be pretty significant.
 
I've found you can actually update Elasticity Falloff in the script (but only for flippers) which is awesome for this, but the bounces would be better if the change was in elasticity and not elasticity falloff.
 
...
 
Let me know what you think. I may have misunderstood the code in some places. Now that physics materials makes importing and exporting physics values much easier now, it's worth a bit of extra complication to get these bounces perfect. Should be a pretty realistic goal, compared to the task of getting lagless flippers on laggy displays (yikes!).

Sorry but these changed aren't easy and we can break more than fixing or improve it. Toxie has already tweaked the physics here and there but it's not active at the moment because of some problems. So all these changes need more time you evaluate and time is really short at the moment.

[ClarkKent]

adding a flipper speed factor is a really nice thing! Nevertheless setting higher values than 1.0 also seems to influence other values and not only the rotation speed of the flipper. Rubbers become less bouncy, it seems to influence the EOStorque, etc. Center shots are really better now but hitting the ball with the thicker end of the flipper finger still seems to apply less strength than set.

[fuzzel]

Toxie changed some areas in the code I missed when adding the factor. Maybe the next update fixes this.

[fuzzel]

rev3088 is up:

 

- fix "Enable Mouse during Play", "Enable Nudge Filter" and "Disable B2S" checkbox in the keys preferences
- add the two missing spots where anglespeed is updated with the new SpeedFactor for flippers
 

[toxie]

Cool! So any other regressions in 10.3 that we need to fix before the final release can happen?

[rothbauerw]

Thanks for the updates.  

 

Speedfactor is still imparting additional momentum to the ball.  

 

I'm not going to pretend I fully understand the code, however, I see a couple of things in hitflipper.cpp that I think need to be changed.  From what I can see,

• SpeedFactor is used to calculate m_anglespeed for the flipper
• Looking further down the file, anglespeed is set to m_anglespeed for the flipper
• anglespeed is then used to in the calculation to determine the delta in velocity of ball to the face of the flipper

const Vertex2D dv(
      ballvx - coll.hitvel.x *anglespeed*distance,
      ballvy - coll.hitvel.y *anglespeed*distance); //delta velocity ball to face

I'm assuming this difference in velocity is used to calculate the change in velocity of the ball.  If so, in order to achieve the desired behavior, we'll need to divide anglespeed by the speedfactor for the flipper.  There are a couple of instances where this calculation is made.

 

There are other instances of anglespeed that my also have this impact, I'm just not able to fully follow the code.  If one of the devs would like to walk through it with me, please PM me.

[Ben Logan]

Thanks for all the work going into the new speed factor setting. Much appreciated!

[fuzzel]

Thanks for the updates.  
 
Speedfactor is still imparting additional momentum to the ball.  
 
I'm not going to pretend I fully understand the code, however, I see a couple of things in hitflipper.cpp that I think need to be changed.  From what I can see,

• SpeedFactor is used to calculate m_anglespeed for the flipper
• Looking further down the file, anglespeed is set to m_anglespeed for the flipper
• anglespeed is then used to in the calculation to determine the delta in velocity of ball to the face of the flipper

const Vertex2D dv(
      ballvx - coll.hitvel.x *anglespeed*distance,
      ballvy - coll.hitvel.y *anglespeed*distance); //delta velocity ball to face

I'm assuming this difference in velocity is used to calculate the change in velocity of the ball.  If so, in order to achieve the desired behavior, we'll need to divide anglespeed by the speedfactor for the flipper.  There are a couple of instances where this calculation is made.
 
There are other instances of anglespeed that my also have this impact, I'm just not able to fully follow the code.  If one of the devs would like to walk through it with me, please PM me.

PM sent

[Rajo Joey]

I don't know, if there is a posting; I can't find it.

In the cameramode, I don't see the values, because they are to small.

Can I change the font and make it bigger and is it possible to rotate the settings?

 

 pf.jpg   262.83KB   23 downloads

[fuzzel]

Sorry that's not possible at the moment

[tttttwii]

With the latest beta I had unintended breakdowns with Champions League and Attack from Mars. The beta version before worked without any errors. After 10 Minutes of playing I observed random stutter. My cab runs in full screen mode.

[toxie]

Thanks for the updates.  

 

Speedfactor is still imparting additional momentum to the ball.  

 

I'm not going to pretend I fully understand the code, however, I see a couple of things in hitflipper.cpp that I think need to be changed.  From what I can see,

• SpeedFactor is used to calculate m_anglespeed for the flipper
• Looking further down the file, anglespeed is set to m_anglespeed for the flipper
• anglespeed is then used to in the calculation to determine the delta in velocity of ball to the face of the flipper

const Vertex2D dv(
      ballvx - coll.hitvel.x *anglespeed*distance,
      ballvy - coll.hitvel.y *anglespeed*distance); //delta velocity ball to face

I'm assuming this difference in velocity is used to calculate the change in velocity of the ball.  If so, in order to achieve the desired behavior, we'll need to divide anglespeed by the speedfactor for the flipper.  There are a couple of instances where this calculation is made.

 

There are other instances of anglespeed that my also have this impact, I'm just not able to fully follow the code.  If one of the devs would like to walk through it with me, please PM me.

 

The thing is that all these parameters have to be in sync, otherwise the physics engine cannot properly handle the collisions, e.g. balls can drop into/intersect elements if different parts of the engine use different variants of the 'same' parameters.