Flight model / Overspeed issue
-
How many fps do you have when happening ?
It can come from two things
-
the RK4 algorythm needs more cycles at high speed for proper convergence (which can be a problem if your fps are too low )
-
the torque coefficients are coming from nasa wind tunnel testing at Mach 0.6 while the FLCS is the real one. THis is normally not a problem since the FLCS rules the pitch roll yaw before the aerodynamics . HOwever There is a possibility that the real flcs gains could need modification to take care of that at very high end of the flight envelope
I think (1) is more probable
-
-
How many fps do you have when happening ?
It can come from two things
-
the RK4 algorythm needs more cycles at high speed for proper convergence (which can be a problem if your fps are too low )
-
the torque coefficients are coming from nasa wind tunnel testing at Mach 0.6 while the FLCS is the real one. THis is normally not a problem since the FLCS rules the pitch roll yaw before the aerodynamics . HOwever There is a possibility that the real flcs gains could need modification to take care of that at very high end of the flight envelope
I think (1) is more probable
I have locked my frames via Nvidia Inspector at 60 and I’ve got V-Sync activated. Just tested it again - constantly 60 FPS.
-
-
How many fps do you have when happening ?
It can come from two things
-
the RK4 algorythm needs more cycles at high speed for proper convergence (which can be a problem if your fps are too low )
-
the torque coefficients are coming from nasa wind tunnel testing at Mach 0.6 while the FLCS is the real one. THis is normally not a problem since the FLCS rules the pitch roll yaw before the aerodynamics . HOwever There is a possibility that the real flcs gains could need modification to take care of that at very high end of the flight envelope
I think (1) is more probable
Post #44. I disproved it being simply low FPS over 3 years ago. My testing showed that the worst situation for me getting that uncommanded roll was between 50 and 110 FPS.
-
-
I get it without v sync at like 90 fps, since U1 at least and I think 4.32 as well.
-
Okay, thanks for the information… Don’t forget to switch to third person, when the jet starts to wiggle.
Question has to be - you’re in a training mission, learning to fly the jet. You’ve exceeded Vne, and you are experiencing a less than happy jet giving you feedback, to which you have to react and correct your error. Why would you want to switch to a third person view? You’re here to fly and fight, not look at the pretty views!
Bugs like these don’t bug me (see what I did there?) in the slightest. If it were up to me, I’d disable all external viewpoints once airborne, period. I am happy to concede they have their uses during a ramp start, etc. but after that…
-
Question has to be - you’re in a training mission, learning to fly the jet. You’ve exceeded Vne, and you are experiencing a less than happy jet giving you feedback, to which you have to react and correct your error. Why would you want to switch to a third person view? You’re here to fly and fight, not look at the pretty views!
Bugs like these don’t bug me (see what I did there?) in the slightest. If it were up to me, I’d disable all external viewpoints once airborne, period. I am happy to concede they have their uses during a ramp start, etc. but after that…
Yeah, you are right. But switching to third person is not just for the view It magically fixes a FLCS problem that occures in 3D-Cockpit only. I assume, that the rudder of a real F-16 would not go cazy when Vne is achieved.
-
Yeah, you are right. But switching to third person is not just for the view It magically fixes a FLCS problem that occures in 3D-Cockpit only. I assume, that the rudder of a real F-16 would not go cazy when Vne is achieved.
So that means it’s fps related as I said before , though a combination of both could be possible
Reducing rudder gains at very high speed would solve it for sure.
Do I want to alter the real FLCS ? Not sure about that
-
I assume, that the rudder of a real F-16 would not go cazy when Vne is achieved.
You certainly have no idea about that. Very bad things can happen above Vne , there is a reason this is called Vne !
-
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.