plane icon Welcome to Microsoft Flight Simulator’s SDK Q&A Platform!

You have questions regarding the SDK? DevMode Tools? SimConnect? You would like to submit an idea for future improvements, seek help or exchange knowledge? You’re in the right place.

In the upcoming flighting, we've changed the behaviour of the content.xml file. If your addon uses this file, please read this article!

Please take a moment to read the platform’s guidelines before you get started!


question

CodenameJack447 avatar image
CodenameJack447 asked CodenameJack447 edited

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.

flightmodel
1 comment
10 |10000

Up to 5 attachments (including images) can be used with a maximum of 4.8 MiB each and 23.8 MiB total.

Hello @CodenameJack447

Just to clarify, are you talking about the lift_scalar and drag_scalar from the FLIGHT_TUNING section?

Regards,
Sylvain

0 Likes 0 ·
FlyingRaccoon avatar image
FlyingRaccoon answered CodenameJack447 edited

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


1 comment
10 |10000

Up to 5 attachments (including images) can be used with a maximum of 4.8 MiB each and 23.8 MiB total.

Excellent news Sylvain!

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

1 Like 1 ·
CodenameJack447 avatar image
CodenameJack447 answered FlyingRaccoon commented

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.

1 comment
10 |10000

Up to 5 attachments (including images) can be used with a maximum of 4.8 MiB each and 23.8 MiB total.

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

0 Likes 0 ·
FlyingRaccoon avatar image
FlyingRaccoon answered

@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,
Sylvain

10 |10000

Up to 5 attachments (including images) can be used with a maximum of 4.8 MiB each and 23.8 MiB total.

CodenameJack447 avatar image
CodenameJack447 answered boufogre commented

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.

4 comments
10 |10000

Up to 5 attachments (including images) can be used with a maximum of 4.8 MiB each and 23.8 MiB total.

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?

0 Likes 0 ·
CodenameJack447 avatar image CodenameJack447 FlyingRaccoon ♦♦ ·

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.

0 Likes 0 ·

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

0 Likes 0 ·
Show more comments
FlyingRaccoon avatar image
FlyingRaccoon answered

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. :)

Regards,
Sylvain

10 |10000

Up to 5 attachments (including images) can be used with a maximum of 4.8 MiB each and 23.8 MiB total.

CodenameJack447 avatar image
CodenameJack447 answered FlyingRaccoon commented

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

1 comment
10 |10000

Up to 5 attachments (including images) can be used with a maximum of 4.8 MiB each and 23.8 MiB total.

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.

0 Likes 0 ·
CodenameJack447 avatar image
CodenameJack447 answered

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.


sustained-degrees-40000lbs.png

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.


10 |10000

Up to 5 attachments (including images) can be used with a maximum of 4.8 MiB each and 23.8 MiB total.

Write an Answer

Hint: Notify or tag a user in this post by typing @username.

Up to 5 attachments (including images) can be used with a maximum of 19.1 MiB each and 23.8 MiB total.