Flight model / Overspeed issue
-
You certainly have no idea about that. Very bad things can happen above Vne , there is a reason this is called Vne !
I am aware of what can happen beyond Vne, but I did not mean talking about damage or turbolences. I am talking about the ingame Fly-By-Wire code itself. I am pretty confident that there is no code that says: “Oh, you’re past Vne? Lets shake dat rudder!” The rudder could get damaged due to overspeed, sure. But why would it fix itself when switching views and is functioning perfectly fine at lower speeds? If the FLCS were to counter turbolences, then why would it stop doing that in third person? I think, that this behavior in BMS is a bug (obviously) and as you said, it can be fixed. I agree, messing with the FLCS may not be in everyone’s favour.
-
Very easy fix … disable the external views key mapping.
-
You would think the point taken would be that there could be a bug with the way the flight controls work, given the obvious disconnect between two different views. Especially seeing as how changing the view should not affect the aircraft controls whatsoever.
It is not in keeping with the benchmark attitude to suggest just not looking at a bug, rather than contemplate fixing it.
-
Oh here we go again
Jp didnt say he wouldn’t look at it he just needs to be sure it is not a fps issue and from his testing he knows what is more likely is all he said
-
With All Respect Ninja, I was responding to DJ.
-
[EDIT] I completely misread the post above and consequently answered inconsistently with what was posted.
My apologies to Blu3wolf. [/EDIT]
-
Really? This is what you gather about the Benchmark Sims attitude?
What is wrong with ppl?? Blu3Wolf was simply responding to DJ’s post:
Very easy fix … disable the external views key mapping.
Just like he said:
With All Respect Ninja, I was responding to DJ.
And now people are assuming/accusing him of something he was NOT inferring!?!??!?!?! WTH :rolleyes:
C9
-
@Cloud:
And now people are assuming/accusing him of something he was NOT inferring!?!??!?!?! WTH :rolleyes:
Same can be said on the other side as well. Just because DJ replied in a joking half serious manner, does not imply that the mindset of BMS is to ignore the situation. However the back and forth ends. Get back on topic, or I will hand out vacations and close the thread.
-
You would think the point taken would be that there could be a bug with the way the flight controls work, given the obvious disconnect between two different views. Especially seeing as how changing the view should not affect the aircraft controls whatsoever.
It is not in keeping with the benchmark attitude to suggest just not looking at a bug, rather than contemplate fixing it.
Obvious disconnect ???
You clearly know nothing John snow !!The fact that fps changes between cockpit and external make the time step of the RK4 algorythm change , which can play a significant role in convergence at the edge of the model
The fact that the phenomenon happens in a certain view and not another is just a consequence of this time step change .
I already explained it , no need to debate years
I am the only one that can fix it and I said I will look at it tough if it requires to alter the FLCS I am not sure I will since is don’t like to change the FLCS built in because this is 100% the real one
End of discussion
-
ok and now the fun begins :
I just tested it on my rig, same mission, same conditions
=> UNABLE TO REPRO
Which clearly indicated , as i said in my first post : this IS FPS related.
not saying this is because of too low FPS, but just the fps gives a timestep wich makes the RK4 hard to be precise at those speeds….
The bad news now
if i can not reproduce it on my rig, i can not fix it
just in case you ask : hereunder is the part of the code that already takes care of that kind of convergence issue , so YES i was aware of that kind of precision issues …
//JP 160415 in case high speed, make the AFM double precision
if (neweom->vt*FTPSEC_TO_KNOTS>500.0f)
{r = 2;
timestep = timestep / 2.0f;
}
else
{
r = 1; //JP 160415 we dont change time step then
}as you can see, the time steps are half the normal when speed is over 500 kts to help precision of the algorythm …
i can triple the loops above 700 , that should help …but that will eat some fps (not that much , RK4 is light)
-
… @Blu3 and Cloud9
Most of the time, we joke, we laugh, sometimes we sigh … then just after, we launch the soft to try to repro and report it on the Dev forum. What happens next … just look last Jp post.
I do not say that we are wizards … but in most cases, we take a look and see what can be done. Sometimes it is fixable … sometime it takes a lonnnnng time. Sometimes it is more problematic or just impossible.Remember … this is “Falcon4.0” … it could have been named “Compromises40”.
Let’s enjoy the “Funcky Chiken” and wing flex in cockpit view … some times ago, it wasn’t there. … meanwhile, hope for more. But let’s try to stay reasonable.
-
@Cloud:
What is wrong with ppl?? Blu3Wolf was simply responding to DJ’s post:
You are correct. I misread his post. My post has since been edited and I again apologize to Blu3Wolf.
-
ok and now the fun begins :
Which clearly indicated , as i said in my first post : this IS FPS related.
not saying this is because of too low FPS, but just the fps gives a timestep wich makes the RK4 hard to be precise at those speeds….
The bad news now
if i can not reproduce it on my rig, i can not fix it
Oky guys, so now, since it is FPS related, if you want Jp to be able to repro and fix it … you will have to give him a donation to purchase a “new” kicking ass computer.
Go figure.
-
@ Mav-JP
I am still getting the “jetwash bug” … or to be more precise
if i fly maximum speeds (or close to > 700kts) at low altitudes (300feet-1000feet) … my nose starts “vibrating” to left and rigth (like a “rudder flattering”).
For test i made the deadzone of rudders maximum to ensure, that it is not caused by false minute inputs, because this “flattering” can be induced by rapid rudder input changes (or maybe “spiking” stick inputs too?!?) …still same.
My FPS is over 100 and i dont change views.THE PROBLEM IS… this is very random, so i can not reproduce it either sometimes, meaning i have to find (create) more speficic regimes in order to reproduce it.
Another phenomena is, that if i pull high Gs and pass from sub- to super-sonic regimes (and vise versa) while under G-load, i can feel a tiny little “bump” in the pitch of the craft. This does not concern me much and feels quiete logical in fact.
-
Regarding the timestep issue, when I’m doing researches on flight controls, I recreated the F-16 FLCS according to a General Dynamics’ F-16 control block diagrams in another platform some time before. At that time I used 0.006 seconds for timestep and I found that the whole plane behaves laggy and have pitch oscillation above 700kts.
I know that the F-16 FLCS has a ton of filter and I’ve also modeled them line by line, but that’s too laggy compared to any F-16 HUD video. Then I adjusted the timestep to 0.009 seconds, and the pitch becomes more crispy, the aircraft no longer oscillates > 700kts.
-
Interesting.
-
Oky guys, so now, since it is FPS related, if you want Jp to be able to repro and fix it … you will have to give him a donation to purchase a “new” kicking ass computer.
Go figure.
If it is low FPS related, that can be tested for with his existing one I suspect. Just start running prime95 in the background.
@A.S:
Another phenomena is, that if i pull high Gs and pass from sub- to super-sonic regimes (and vise versa) while under G-load, i can feel a tiny little “bump” in the pitch of the craft. This does not concern me much and feels quiete logical in fact.
Other than how regular it feels, it seems not unusual to have that kind of kick in the transonic regime.
-
@A.S:
@ Mav-JP
I am still getting the “jetwash bug” … or to be more precise
if i fly maximum speeds (or close to > 700kts) at low altitudes (300feet-1000feet) … my nose starts “vibrating” to left and rigth (like a “rudder flattering”).
For test i made the deadzone of rudders maximum to ensure, that it is not caused by false minute inputs, because this “flattering” can be induced by rapid rudder input changes (or maybe “spiking” stick inputs too?!?) …still same.
My FPS is over 100 and i dont change views.THE PROBLEM IS… this is very random, so i can not reproduce it either sometimes, meaning i have to find (create) more speficic regimes in order to reproduce it.
Do you Guys even read what I wrote ?
-
Regarding the timestep issue, when I’m doing researches on flight controls, I recreated the F-16 FLCS according to a General Dynamics’ F-16 control block diagrams in another platform some time before. At that time I used 0.006 seconds for timestep and I found that the whole plane behaves laggy and have pitch oscillation above 700kts.
I know that the F-16 FLCS has a ton of filter and I’ve also modeled them line by line, but that’s too laggy compared to any F-16 HUD video. Then I adjusted the timestep to 0.009 seconds, and the pitch becomes more crispy, the aircraft no longer oscillates > 700kts.
It is hard to make time step in f4 fixed which makes things more tricky
But as you can see the FM is very smooth
-
@A.S:
Another phenomena is, that if i pull high Gs and pass from sub- to super-sonic regimes (and vise versa) while under G-load, i can feel a tiny little “bump” in the pitch of the craft. This does not concern me much and feels quiete logical in fact.
Look in your EM charts , between 0.9 and 1.0 Mach ,the lift is very discontinuous .
This is the bump you feel