Flipper Big Issue for trajectory, error and weird

JLou5641

Pinball Hall of Famer
Joined
Jan 10, 2020
Messages
597
Reaction score
308
Points
69
Favorite Pinball Machine
Stargate
Hi all,

By working on BAM rotationSpeedChart, i discover a big problem. There is a big bug issue, a point on flipper, around which the trajectory changes completely with only 1 Frame / 0.03ms ( if fps physics is at 296 ) of different timing... A big big difference of trajectory... This "Bug" make everyone's job completely wrong. Is there anyone who ever discover this?

I made test on all table, also on a blank table, it's the same problem for all.

See the video below from my post on "BAM rotationSpeedChart" Topic. We need to find and resolve this issue. The "turning point" is between frame 149 and 150 in this video.
PS: @ravarcade , maybe you know why?
Greating, JLou
i discover something wired with fin physics... There is a step... where with only a gap of 1 frame on flipper testing, trajectory is completly different... Shit!!!
View attachment 21809
 
Last edited:
@JLou5641
I can ask you a few questions about this?
 
Ok......to understand this bug....
1) when you worked on your "mods" in mega, didn't you notice this problem?
2) this hypothetical bug is: in Fp or Bam? in your opinion
3) did you change many things on my xml? or have you completely replaced it?

about the charts
4) for to try modify the charts as in points5, in a new or empty table, you need to insert a DF?
5) I opened my table, I say mine because we work on this table,where is your DF, of course,look at these pics
Future Pinball 2021-09-14 21-36-22-10.jpgFuture Pinball 2021-09-14 21-36-42-53.jpg
what are these green lines? or rather what it represents? can these curves be modified? and how? and the points?

6)I tried these frames, they can reach up to 1000 see photos(ops...forgotten), how are they used? and what are they for?
Future Pinball 2021-09-15 00-06-24-96.jpg

7) this value in (xxxxx) how is it generated?
rotationSpeedChart="{0.0,1.0},{1.95,3.8},{4.75,9.0},{7.75,15.6},{9.8,22.0},{12.3,31.5},{13.15,39.3},{14.0,50.0},{14.55,62.0},{14.75,75.0},{15.0,100.0},{15.05,160.0}[0.0,0.0],[10.25,1.0],[27.65,14.5],[45.0,50.0],[50.0,100.0]"


This "Bug" make everyone's job completely wrong. Is there anyone who ever discover this?
I don't know if the guys,that have devised the original DF's, worked with these charts too, so they may know .... ? instead if nobody has worked with these charts, until now, that is since you started them, then nobody can know about this bug.

forgive me this question, it's not to belittle your work, and just to understand.......now if this bug makes everyone's job wrong, a question arises spontaneously: the current DF+Charts can't work right?or does it only work up to frame 150? again....how do your mods work ?, this question is related to the first point.

PS:the call alone, perhaps not enough for Rav.
 
Last edited:
1) when you worked on your "mods" in mega, didn't you notice this problem?
I never noticed it before because, i prefer to set charts by playing myself in realtime. By doing this, it take account of possible input lag
2) this hypothetical bug is: in Fp or Bam? in your opinion
3) did you change many things on my xml? or have you completely replaced it?
-It's on Both.
-I use my xml. But as I say, Xml doesn't affect this bug.. With or witthout xml it's same
4) for to try modify the charts as in points5, in a new or empty table, you need to insert a DF?
5) I opened my table, I say mine because we work on this table,where is your DF, of course,look at these pics
-As I ever say, if you don't need Tip pass ( or making post pass easier ), DF script is not needed.
-DF is a Prehit calculation script that override Omega you set in BAM by Omega set in this script along the fin. In this case, you can change Omega in relation with contact point. ( Meanwhile Rotation Charts change omega in relation with time.. like in real )
what are these green lines? or rather what it represents? can these curves be modified? and how? and the points?
Those lines are the Rotation Charts. You can change each point ( idx1.. idx2.. idx3 etc etc ) for flipper UP and flipper release, in time and percentage from the Omega you set. It show you the acceleration. Change IDx with your keyboard, then change time and percentage, you will see the curve changing.
6)I tried these frames, they can reach up to 1000 see photos(ops...forgotten), how are they used? and what are they for?
"Frames" is the delay for making flipper up after the ball is dropped like if you push your flipper button... By defaut, physics fps is at 296.. So 1 frame mean 0.003s.. Is you set 1000 frames, flipper will up automaticaly 3.37s ( 0.003x1000 ) after the ball is dropped.
7) this value in (xxxxx) how is it generated?
rotationSpeedChart="{0.0,1.0},{1.95,3.8},{4.75,9.0},{7.75,15.6},{9.8,22.0},{12.3,31.5},{13.15,39.3},{14.0,50.0},{14.55,62.0},{14.75,75.0},{15.0,100.0},{15.05,160.0}[0.0,0.0],[10.25,1.0],[27.65,14.5],[45.0,50.0],[50.0,100.0]"
It's generate by Rotation Charts we are talking on 5)
forgive me this question, it's not to belittle your work, and just to understand.......now if this bug makes everyone's job wrong, a question arises spontaneously: the current DF+Charts can't work right?or does it only work up to frame 150? again....how do your mods work ?, this question is related to the first point.

PS:the call alone, perhaps not enough for Rav.
I mean that some trajectory are impossible to aim due to this bug, so we can't make what we want correctly. It's a huge issue.
That doesn't mean DF+Charts can't work right... They work right.. But result is corrupt due to this huge issue
For the "frame 150", it's not due to this frame.. I say "frame 150", because in my ex, frame 150 corresponding at the timing where we can see this issue when flipper up after the ball drop in testing, which means, flipper UP 0.45s after ball drop.
 
Last edited:
To give a "picture" of what is this issue, trajectory are like if Flipper has this shape, as if the face in contact with the ball had a vertex, and therefore more open trajectories/aim shot to the left of the vertex, and more closed trajectories/aim shot to the right of the vertex, and impossible trajectories / aim shot on the vertex... Finally, like if flipper has 2 faces for 2 shooting angles
image_2021-09-15_112758.png
 
Last edited:
Got it.

By the way, are you using rotational charts or mix of rotationcharts and _prehit code?

did you try using just one or the other? still happens? Just trying to help troubleshooting.
@AnonTet , I answer in this topic.
Without Prehit Code, it's worse.. Trajectory difference is bigger, but at approximately point 0.9, not between 0.8 and 0.9
 
I overlooked it. I have an good excuse though; I had a motorcycle accident this weekend and still not very aware :D (seriously, I did crash)

Out of curiosity, did you try another flipper length? does it still happen at 0.8-0.9 contact point?
 
oh.. shit.. hope you are fine..

Nope, i test different model of flipper, but not with different lenght... good suggestion. I will test as soon as i can.. I'm back to work now
 
Last edited:
Ok, @JLou5641 your answers above I have to study it for good .... but I read the discussion between you and @AnonTet
I understand that anontet, explains and thinks is a bug (if in reality it is, and that I only think RAV, can say) of the physical engine of FP, yet the matter is serious, instead if it is a bug as you explain you jlou , it could be solved ....I think

you say you also got it on an empty "new" table, so I assume that it is not because of the flippers(fin,bats), my table, because that is a modified flipperl ..... I'll explain
I wonder if the mask could be the cause, what is the mask???? The collision of the Flippers.....this in pink
Cattura7777.JPG
 
Yes, i have the same Idea.. i will test it
 
I'm fine thanks. Well enough to be here :D

I really hope it is something as simple as the collision masks on the objects, in this case is the flipper but might affect others although not as important as far as i'm concerned.

I just thought of one more thing, does it happen just on the left flipper or both? I ask because I remember that the left flipper gets negative values in some calculations which is why in _prehit there they are multiplied by 1 or inside abs() to make them positive. Should not interfere with ContactPoint but who knows... we're talking about FP :D
 
I'm fine thanks. Well enough to be here :D

I really hope it is something as simple as the collision masks on the objects, in this case is the flipper but might affect others although not as important as far as i'm concerned.

I just thought of one more thing, does it happen just on the left flipper or both? I ask because I remember that the left flipper gets negative values in some calculations which is why in _prehit there they are multiplied by 1 or inside abs() to make them positive. Should not interfere with ContactPoint but who knows... we're talking about FP :D
interesting... i find this and make my test only with right flipper... not left
 
@GeorgeH , I answer you here:
Everything Rav did on this change is pretty much over my head. You might want to read Rav's discussion here:

http://gopinball.com/forum/viewtopic.php?f=86&t=6676&p=86688&hilit=geometry#p86688 (GoPinball.com • View topic - BAM Dynamic Flipper Breakthrough !!)

If fact, you may want to read everything Rav posted on the whole thread I saved above. You would probably understand it better than I do.

Be sure to delete the bounce control code when you delete all of the DF code on the test I suggest above.

You might try changing to the T5 flipper model and see if that makes a difference. The T5 is quite different from the other flipper models.
Thank you! This is completly what I find. Without DF it's completly eratic, and with DF, i Have 2 contact points like Rav said in his post on Gopinball and eratic trajectory for the TIP.
So i repost it here...

... and another FP error fixed. For me, it was one of most annoying bug: broken flipper geometry and stupid ball direction after some hits.

See this image, at red line:
Image

When ball is hit near flipper tip sometimes it fly, like top surface was not flat but concave.

There are 2 different sources of problem:
1. shape of flipper:
Image

At image some dimmension are not realistic, but this way problem is more visibly.
Flipper physic-sim-model have 3 parts: 2 cylinders (red and green circles) and space between point P0 & P1.
FP by default uses black points on image and surface in pink color is part of flipper.
You can see, that white surface from flipper is "missing".

In new BAM i use "white" P0 and P1 points instead "black". Result: Top flipper surface is flat, not concaved.

... but it was not only problem ...
2. When ball hit flipper in place near tip, physics engine reports 2 contacts with flipper: one with line between P0 and P1, second with green cylinder.... and for some reason ball is bounced always like from cylinder.
So, even if we have "flat" top surface, that surface is ignored and ball is bounced only by green-cylinder.
Stupind newton physics engine.
I have found way to force on physics engine to ignore in some cases "green-cylinder". Fix is complicated and require calculations when is real ball-flipper-contact-point and prediction of collisions. I can guess, that my fix will not remove all errors, but i hope it will be almost all.

Bad thing about fix for that second case is: It require in Flipper_prehit subroutine (even empty one).
So, all table with "dynamic flipper" will work instantly, old table may still require some script modification. Here is example of required code:
Code:
Dim RightFlipperExt, LeftFlipperExt
Sub BAM_Init()
Set RightFlipperExt = xBAM.Flipper("RightFlipper")
Set LeftFlipperExt = xBAM.Flipper("LeftFlipper")
End Sub
Sub LeftFlipper_prehit()
End Sub
Sub RightFlipper_prehit()
End Sub

_________________
http://www.ravarcade.pl
Better Arcade Mode
current BAM version: v1.5-289, released: May 10, 2020
 
So after read Rav post. You're right @GeorgeH , it might there is still a little geometrie error for the tip on geometry DF calculation
 
I presume the black dotted lines in the picture below represent the trajectory of the ball after it hits the flippers. I noticed the trajectory changes at the green arrow. It appears to be at about the point where you identified the problem that you discussed above.

Image.jpg
 
It's exactly that.
So, without if @ravarcade find how to correct this perfectly, i don't know how to prevent this for now.
 
This is completly what I find. Without DF it's completly eratic
what does it mean eratic?if I put this it makes sense to me erratic

in other words, if I understand correctly, the problem could be how the model (flippers) is structured, in FP, there are different models of flippers, so you have to create and have someone in particular? that is, built in a particular way?


honestly, since using the DF, I have always noticed that sometimes the ball goes in another direction than the one I try to give, but I never wanted to open a discussion, because I thought that somehow physics also has to do with it (xml) but since i started understanding physics in xml,I think as I have said on other occasions, the physical engine of FP , it's obsolete (with respect speaking),so it can be the cause of a lot of negative things in FP, I always talk about physics and gameplay

now, I don't want say obscenities, but when the DF (Rav, George, Gimli,and maybe other guys ) was created, I think this DF, is penalized by the physics engine of fp, which doesn't handle some situations very well, like this one for example, al point to create a conflict between the fp fins and the DF itself, because the DF forces the original conditions of the physics engine in some way.
I am wrong?

It's exactly that.
So, without if @ravarcade find how to correct this perfectly, i don't know how to prevent this for now.

I can be wrong, but I believe that Rav knows about this problem, maybe on some occasion he even talked about it, I doubt that this fact (discovered in one of my tables) could have escaped him, if instead I'm wrong (I hope so) I trust that he can solve it, but in my opinion you have to send an imail directly to him, detailed obviously ......
 
Last edited:
what does it mean eratic?if I put this it makes sense to me erratic

in other words, if I understand correctly, the problem could be how the model (flippers) is structured, in FP, there are different models of flippers, so you have to create and have someone in particular? that is, built in a particular way?


honestly, since using the DF, I have always noticed that sometimes the ball goes in another direction than the one I try to give, but I never wanted to open a discussion, because I thought that somehow physics also has to do with it (xml) but since i started understanding physics in xml,I think as I have said on other occasions, the physical engine of FP , it's obsolete (with respect speaking),so it can be the cause of a lot of negative things in FP, I always talk about physics and gameplay

now, I don't whant say obscenities, but when the DF (Rav, George, Gimli,and maybe other guys ) was created, I think this DF, is penalized by the physics engine of fp, which doesn't handle some situations very well, like this one for example, al point to create a conflict between the fp fins and the DF itself, because the DF forces the original conditions of the physics engine in some way.
I am wrong?
It's correct @Paolo . But the problem, it's not really a shape problem, but a how FP calculate contact point between base circle, tip circle, and tangent surface between them of fin. Ravarcade DF overide this to calculate it better, but not perfectly, maybe there is a little error in his matematical formula... But it's still better meanwhile Without DF, it's catastrophic. In my opinion FP physics is not bad as everybody think. If we can have this issue resolved, it will be a big big step foward. I will search if i can compensate it.
Also, we are in 2021, we have powerfull PC, it's a nonsense in my opinion to let Engine FPS at 296.. I push it to maximum... and for over 600 fps issues.. even at 1000fps, i never see Issues with my XML :rolleyes:

I can be wrong, but I believe that Rav knows about this problem, maybe on some occasion he even talked about it, I doubt that this fact (discovered in one of my tables) could have escaped him, if instead I'm wrong (I hope so) I trust that he can solve it, but in my opinion you have to send an imail directly to him, detailed obviously ..
For sure he know... because it's him who discovered his problem and developed the DF to compensate it ;)
 
but a how FP calculate
When you talk about FP, meaning of the physical engine,right?
contact point between base circle, tip circle, and tangent surface between them of fin.
yes, I think I understand, it's very clear.

But it's still better meanwhile Without DF, it's catastrophic.
I believe it well, I also always said lately , that for years before the DF, we have played (actually, in my opinion) to soccer not to a pinball.
some tables that play "well"without DF, it is also thanks to how you arrange and place objects on the table especially ramps, some of my tables without DF, is so.

In my opinion FP physics is not bad as everybody think.
If you talk about that standard, that is, (according to my understanding), of the physical engine, without XML, is not the best,
the fact, I believe, does not depend if bad or well, but only because to play better (everyone thinks so,you too) on a table in fp, you have to have XML ...... mass, gravity, etc etc. ... then, a DF + charts now ...... and who the more nor has, the more nor puts, how do we define the physics of fp?
If we can have this issue resolved, it will be a big big step foward. I will search if i can compensate it.
I hope so my friend!
Also, we are in 2021, we have powerfull PC, it's a nonsense in my opinion to let Engine FPS at 296.. I push it to maximum... and for over 600 fps issues.. even at 1000fps, i never see Issues with my XML
Ehhhhhh.....I'm one of those who don't have it, but don't think about me, so go ahead!
 
Last edited:
of course i talk about BAM physics with XML.

What's your PC spec @Paolo ?
 
Last edited:
I presume the black dotted lines in the picture below represent the trajectory of the ball after it hits the flippers. I noticed the trajectory changes at the green arrow. It appears to be at about the point where you identified the problem that you discussed above.

View attachment 21848
First about that green arrow.
You can see 3-10 lines almost paraller and next 3-10 lines paraller too, but at slight different direction.
This exist, because physics simulation is "discrete".
When ball roll over flipper, it gains speed. If press flipper button after 140, 141, 142, 143, ... frame in each frame ball move little faster, have little different contact point. Until now it is like in real world physics and what you expect.
Now comes "diskrete" part.
When flipper is rotating, it pushesh ball, but time how long ball is in contact with flipper is not linear but is diskrete.
For example if you activate flipper after 140 .. 145 frame ball will be in contact for 8 frames -> so you see 6 paraller lines, but if flipper activation occurs after 146 .. 148 ball will be in contact for 9 frame -> so, you see another 3 paraller lines but at little different direction.
Thats is reason why you see that gap.
In reall world ball will be in contact with flipper like this:
Flipper activate in 140 =>8 frames (or 8/296)
Flipper activate in 141 => 8.3 frame (or 8.3/296)
Flipper activate in 142 => 8.6 frame (or 8.6/296)
Flipper activate in 145 => 8.9 frame (or 8.9/296)
Flipper activate in 146 => 9.2 frame (or 9.2/296)

Conclusion: there is no fix for this. You may only increase FPS (700 is max)... but with different FPS you have completly different physics.

Now that single red line.
If it is single line (like on picture above), this may be just Newton physics engine "artifacts".
As you know for physics engine flipper is 2 cylinders and 2 flat surfaces.
Physics engine should determine if ball contact point is on cylider (tip) or flat surface correctly.
I got impression (not 100% sure) that sometimes Physics engine selects "cylinder" sometimes when it should select flat surface.
So, that one single red line case may be result of hit with cylinder at flipper tip and flat-top-surface is not present.

Before you start complain about FP physics engine keep in mind, that solution for that problem is not trivial. Ball is in motion. Change of object states between 2 frames not alway gives good info what was happend.

Second thing: Keep in mind, that when you do tests with BAM build in tool, you can reproduce problem over and over.
But if you do small change, like move ball 0.01 mm left/right or gives ball littlebit different starting speed, you will end with completly different results.

Artifacts presented here maybe impossible to reproduce in real gameplay.
 
Thanks @ravarcade , i just find how to minimize it.. You describe exactly what i find, and like you say, by pushing FPS to 600, and fine tune my Rotation Charts, it work very well. and issues is very very minimize. I update my Bride Of Pinbot version, and Williams Flush for @Paolo . Did you want my Version? Now i use homogen Omega along the flipper due to Rotation Chart.. Also, last out of subjet question, Rotation Chart is a crazy tool, did you implant it in VPE ?
 
Thanks, but i don't have time to play.
VP (and VPE) have flipper rotation base on force not constant omega. So, VP/VPE don't need "rotation chart" that much as FP.
For last year i have almost zero free time for FP/VPE.
 
Forum activity
Help Users
You can interact with the ChatGPT Bot in any Chat Room and there is a dedicated room. The command is /ai followed by a space and then your ? or inquiry.
ie: /ai What is a EM Pinball Machine?
  • No one is chatting at the moment.
      Chat Bot Mibs Chat Bot Mibs: MMITG is our newest member. Welcome!
      Back
      Top