About stallliftscalar

Hello Sylvain, could you give us some insights about how this variable in
flightmodel works? Just having it in the flightmodel and set to 0 the overall
drag force is reduced during a turn but don’t counteract lift force. I
understand that at low speeds this is fine because it allows me to achieve
higher than normal angles of attack while still being maneuverable. In some
tests done in tight turns I see that my lift force can be perfectly 318000lbs
when the drag is 38000lbs. if this variable were not here, the drag value
would be equal to or greater than this lift force when the critical angle was
reached, so i end losing the control of the airplane. However, this causes a
problem at higher speeds. If we take your FA18 as a reference and define
elevator_maxangle_scalar =1.5 and a elasticity table like the following
elevator_elasticity_table = 0:1, 400:1.0, 800:0.85, 1200:0.5, 2000:20, occurs
the following: If I reach for example 600knots and make a tight turn, the lift
force generates so much force (more than a million pounds), that it makes the
plane start accelerating even at idle. There is no induced drag or parasitic
drag that can counteract that. this force becomes even greater if the value of
the scalar is 1. I don’t know if I explained it well, but this is happening
and I can show it to you with a video. The question is, is there a way to use
this variable so that it works as desired at low speeds, but not cause this
problem at high speed? Thanks.

Hello @CodenameJack447 Just to clarify,
are you talking about the lift_scalar and drag_scalar from the
FLIGHT_TUNING section? Regards, Sylvain

No, we talk about stallliftscalar and stallpitchscalar in the flight_tunning
section. In FA18 they are set to 0 for lift and 1 for pitch.

Ok, my bad. These parameters are being documented as we speak. I’ll forward
your questions and will come back to you as soon as I have enough information
for a proper answer. Regards, Sylvain

@CodenameJack447 I got the final word on
this. These 2 parameters were used when developing the F/A-18 for test
purposes but are no longer relevant. stallliftscalar doesn’t do anything
anymore. stallpitchscalar is applied to presspt_fwd_Alpha0_pMAC ,
presspt_fwd_AlphaStall_pMAC , presspt_fwd_AlphaHiStall_pMAC but is
reset to 1 (default value) on the F/A-18 as you can see. Both are remnants of
tests and shouldn’t be used. Apologies for the confusion this caused. Regards,

Ok Sylvain, anyway i have uploaded a video, you will need to wait until
proccessed. https://youtu.be/68gHyoaoWHo Just check the lift total force and
the total drag force, and that i’m in idle. i imagine that this is not the
intention about what these two variables should do. However at slower speeds
works as intended. **** P.S. didn’t see your previous reply, understood then
but… they are actualling doing something.

I hardly see how stallliftscalar could play a role here. The config is read
and stored in a variable that isn’t used anywhere in the code. The only things
you have changed compared to the base F/A-18 are: - elevator_maxangle_scalar
to 1.5 - elevator_elasticity_table set to 0:1, 400:1.0, 800:0.85, 1200:0.5,
2000:20 That’s it?

Also I have disabled FBW and set the stallliftscalar to 1 to make it more
evident. With FBW enabled, the plane tries to stay within G limits but still
it throttles. That’s not the point. The point is that if I eliminate these
flightuning variables, the general drag increases (aerodynamic drag to be more
precise). If I introduce these variables, the drag does not increase in tight
turns, while the lift force does increase. and if I set that scalar to 1 the
lift force increases its value accelerating the plane without power. Those
values in the flight model, as I have already said, control that the plane
remains maneuverable at angles of attack like the ones you saw at the end of
the video and if they were not there, the plane would simply make a departure
and crash. If you want I can make you a video in which I change the values in
real time and you judge for yourself.

I was able to reproduce this behaviour. Disabling FBW and slightly increasing
elevator efficiency is enough to see the problem. It seems to occur when the
speed is high and AOA is at a certain value. That said, when it happens, the G
force is around 30-40. I’m unable to produce the issue at moderate G forces so
I’m not sure there’s a point adjusting the FM behaviour in these conditions
and I’d say the aircraft should never reach such load in the first place? What
do you think? Our FM programmer will still have a look in case this is a
symptom of a more problematic issue that would also have side effects in more
normal conditions. Regards, Sylvain

Hello @CodenameJack447 The problem is
identified. This is caused by the high G buffeting calculations. At very high
G (20+), they could cause some forward bumps. We’ll change that in SU11 to
make sure there can’t be any forward component. But unless you’re creating a
flying saucer, this should not impact your FM. Thanks for reporting this. :slight_smile:
Regards, Sylvain

I will reply shortly. You caught me eating, but I’m glad you located the

We’ll keep investigating as we’re not 100% sure the buffeting problem is not
just a component of the problem. I’ll report our findings here when we have a
better picture.

Surely the high G loads are due to the excessive speed. The two are related.

Well then I’ll wait and see what you guys find out about it. One thing is
clear and it is the underlying problem, the total lift force should not under
any circumstances accelerate an aircraft in a tight turn. There must be a drag
that counteracts it or enough to maintain a sustained turn or even bleed
energy. We do not intend to create flying saucers, but fighter jets capable of
sustained turns under G as specified in the official flight manuals. Now that
is impossible in MSFS, unless we falsify values, which I am not a fan of. I am
also not in favor of you eliminating stallliftscalar, since even its value,
even though it is 0, allows squaring the maximum angles of attack with
precision at low speed, although it causes this problem in values close to
mach 1… same way I am not in favor of all planes having to be FBW in order
to camouflage an underlying problem, because by eliminating it from the
equation, an airplane that should withstand 9G’s at sea level for a 20deg/s
sustained turn doesn’t do it in practice even with FBW. Without FBW you can do
it, but probably withstanding 15-20 G’s in the process, which is not
realistic. There must be a way to maintain these sustained turns without
hurting the plane’s pitch rate, for example a lift vs mach table would help,
but camouflaging it with elasticity vs dynamic pressures to hide this problem
only camouflages it at sea level, not at high altitude. A real example would
be this.

You always try to
square this graph with the elasticity tables, but when you square the G’s the
pitch rate is low, if you square the pitch rate the G’s are too high. And of
course, there is no way to square this as you increase altitude with the tools
we have. Anyway, whatever it is, I’ll wait for your news.

Hello @CodenameJack447 Further
investigations showed that the high G buffeting issue I mentioned was only a
component of the problem. There is an hardcoded acceleration limit supposed to
prevent the FM from computing aberrant acceleration (this comes from FSX).
This limitation occurs if the plane flies at high G with a high AOA and was
done in a way that can cause the vector to change direction and end up with a
forward component. The limitation kicks in at 7G but becomes noticeable only
above 10G in our tests. Probably not an issue with the legacy FM and not
something we encountered developing FBW aircraft on the new FM. We have
addressed the problem by raising the G limit and changing the way it’s
computed in a way that won’t change the vector direction anymore. The fix will
come with SU11. Thank you for your feedback. Regards, Sylvain

Excellent news Sylvain!

I look forward to seeing this fix in SU11. Thank you!