Physics and Aerodynamic on Directional Stability - Part 2 - Getting to the Root of the Problem

I’m looking at the G1000 screen and it show 9kts on the ground, and yet:


I also tried whacking that scalar up to 10, and it doesn’t feel much different in the air either. I don’t know in which direction these changes are supposed to influence rudder behaviour, but when I set it to 10 either my rudder should be much more effective, or do next to nothing. Neither appears to be true.

It’s also perhaps outside the scope of this, but if I configure the weather to have 0kts gusts, its a smooth crosswind, at least in the air. If I set it to even 0.1kts, I see the crosswind components gusting between 2kts and 15kts. Even with 0.1kts its next to impossible to maintain centre line. Gusts just seem broken to me, but live weather never feels like this. Perhaps live weather never has gusts simulated?

Tried setting it to 20, and it still feels the same in the air. I was kicking the rudder from full left, to full right, and set to 20, and then 0.1, I couldn’t detect a difference in how it flew. Should the secondary effect of induced roll be affected, as that definitely felt the same?

More playing around after lunch I think.

I don’t want to be rude, but sincerely I think that one of the negative aspects of being a developer is just to read/hear simplicistic analysis from customers that don’t see the giant complexity of a project as MSFS.
I am really grateful to MS/Asobo for making the glorious franchise live again after a 14 years break. I can only imagine how difficult is to manage such a plan, also considering, as others noticed, that aeronautical companies are usually quite strict in providing data or collaboration.
So my solidarity to the developers, please rest assured that many users understand the actual scale of the commitment.

1 Like

This topic shows one thing for sure:
There are some scientists using FS

1 Like

Rather than make an arrangement with consultants, they have aerodynamicists on staff…
Flight modeling is no simple task, certainly not on a single PC that’s also handling many, many other tasks. It will get better.

Discussions like this are fun, but, really, you’d have to be talking to the developers themselves to determine what they did and why, and for that you’d need an NDA…


I think microsoft/asobo are already working on the aerodynamics problem. Sebastien in the last live Q&A talked about a redesign that could take several months. In this same live Q&A he also shows the effect of inertia in flight by comparing to the real world.

Thank you for sharing the astute process through which you’re trying to help with the flight model. I find this interesting, and actually your comments on the relationship with the config files and the flight model integration loop is reminding me I’ve submitted a question for the Live Q&A which was not specifically addressed*.

I was wondering among other things whether this “integration” step purpose is not just to converge to a best-fitting approximation of the model in order to help porting FSX add-ons first. I’ve perused the online SDK docs yesterday and I find interesting bits I didn’t read before, which are somewhat supporting this idea.

Here is what I was asking:

Which raises another question to me: in making their normalization algorithm "bending’ their 1000 element model to match the FSX historical flight model behaviour, didn’t they just cut out what could have made their new engine a key differentiator from the past and from competing simulators?

*ref: Live Dev Q&A: Guided Question - #18 by CptLucky8

Because it looks to me the main difference between FS2020 and XP11 flight model is this:

  • XP11 extrapolates flight model from a source model. It takes a source model in a certain format (be it 3D, values, both) and derives the model and behaviour from the source. You make the end result matching reality in fine tuning the source data (shape, values etc…).
    The more they refine their equations and physics, the better and closer to reality the flight model.
    The more they refine their technique, the better the flight model will match any flight situation and physics
    To illustrate what I’m thinking of with this: when they simulate air flow in inverted flight, the model will fly inverted as expected. Or when they simulate the air flow from the props hitting the tail or the elevator, you’ll get expected results from these as well.

  • FS2020 bends the flight model from a target performance. It takes a target behaviour, and a base source model (FSX area type), and integrates the former to match the latter. Extra elements are therefore not building blocks of a refined model, they are a necessity to converge the solution from a few target data point to a few source model data point otherwise their wouldn’t be enough precision to integrating the target performance.
    The more they refine their equations and physics, the closer to target performance the flight model.
    Regardless of the refinement, it won’t make the flight model capable of matching flight situations which are not accounted for in the target performance model.
    To illustrate what I’m thinking of with this: if there are no inverted flight target values, it won’t fly properly inverted. If there is no provision for target values defining the prop wash effect, it won’t be simulated either

I believe therefore both XP11 and FS2020 models are doing the same in the end: matching a target value to a source model. Both are using a source model based on geometry of some sort, but the difference seems to be the target model. XP11 target is real physics and air flow, FS2020 model is expected values:

  • The former is not constrained, the latter depends on the accuracy and number of expected values.

  • The former could produce convincing and acceptable simulations for any flight situations but they could be wrong as a whole, the latter could depart outside its envelop in cases for which there is no matching target to source integration but could be right where it is well defined.

I wouldn’t pretend knowing which one is better than the other, but I can say at least the FS2020 documentation about XP11 is wrong because it doesn’t take in account the latest XP11 developments in the flight model since XP11. It looks in fact as-if the FS2020 SDK docs was redacted by the time they started developing FS2020 and this relates to XP10 area flight model docs (the FS2020 SDK docs about flight model could just be the internal memo they’ve redacted for MSFT when ‘selling’ their approach to the decision maker). And if I’m not mistaken, FS2020 approach is closer to what is used in the industry like in Level D simulators where the flight model is not accurate but is matching expected values for standard flight regimes and situations (it was fun once making barrel rolls in a 737-400 simulator 2 decades ago when all of a sudden the platform was going haywire when 180 deg inverted :wink: )


Are you entirely sure about MSFS being Rad-1? I cannot find that definition in the SDK.

Thank you for the compliment. Very nice insights on your post!

So, we have no ideia, which areas in the Flight Model are 100% being generated on the Fly, using the 1000 Points Virtual WindTunnel, etc, and which are still relying on Legacy Tables to set as target, and then running Iterations to approximate to the best solution, using that in the Modern FM. This is something only Asobo and Microsoft can answer.

Also, I heard somewhere, maybe even Sebastian saying, that he plans on expanding this 1000s points to a lot more, with better hardware, because it’s not even close to enough to give consistent result across the envelope.

I think this decision to still rely on legacy tables will end up being an anchor in the near future. This is already showing signs that some major rewriting of some areas for Modern FlightModel is going to be needed. By being tied to these old tables, you just loose too much control over what you want to set as performance target for your addon, you end up hostage of what the iterations are achieving as solution, and having to chase the numbers until you get what you want, without being able to use real values. It will always have some interpolation that will deviate the original target to some middle ground.

One example I have noticed of that is that since we are not allowed to use Angle of Attack vs Cl for individual wing, still stuck to the Legacy code to have a CL for the entire airplane, the Modern Flight Model is doing some interpolation to generate WingCl, and from what I have noticed, that is generating some pretty weird values for the Wing alone. The Modern FM needs to generate individual Cl for the Wing because it simulates the stall of the Wing separate, each one at different Angle of Attack, etc, taking into account the shape of the wing, etc, something that was never considered in FSX and before. But this resulted in some crazy numbers for the WingCl when I tried to do some maneuvers, reaching over 10! Maybe this is one of the reasons Aircrafts are difficult to Stall in the new Sim, the WingCl still is too high when the whole aircraft CL is stalled.

Now, back to my original Post. I don’t think there’s interpolation between LEgacy Code and Modern FM for the Sideforce and Yawing Moment due to Beta. The Legacy Tables for these values are not being considered at all by MSFS2020. You can delete them from the .cfg, and nothing will happen. It relies on Fuselage Dimension, Tail Dimension, Moment Arm from Wing to Tail, and the Scalars for Rudder Effectiveness, Stability, etc.


Always add, “At the current moment” to these analyses. It’s been shown that Asobo at one time was using certain parameters from the CFG file, then quit using them — breaking the autopilot turn behavior as a result — then started using them again.

I applaud your analysis, but realize that it is likely to become invalid the next time they update the sim. All we can do is build houses of cards as long as they can change the code to interpret the CFG files differently at any time.

1 Like

I didn’t realise it until you pointed out those readouts, but this was exactly what I was feeling on takeoff, this creeping increase in crosswind. I shot some video showing this increase, and it gets even worse when you introduce even a tiny amount of gusting.


Thank you for your hard work and research on this. I am sure this will help a lot of people including myself. Will be eagerly watching this thread for updates and I’m excited that you got the attention of the MSFS team :slight_smile:


I know it can seem like stuff is happening in the dark, but as a member of the MSFS team now, I can tell you that we discussed this thread specifically yesterday. We do read this stuff!

The specific issue brought forward by the OP is the issue that Seb spoke of at the last Q&A: that specific flight model configurations in some aircraft were being adjusted to reduce tail effectiveness so that they don’t stick so hard to their current yaw angle, which has both the side effect of increasing adverse yaw as well as reducing (if done by the right amount) the perceived twitchiness as the aircraft will swing through the yaw with less tendency to want to return to the original yaw angle.

There are a few things to keep in mind. One is that 10 different papers will give you 10 different sets of values for these aero coefficients for the 172. Lots of these materials were already looked at and lots of different aerodynamic theories and sources were used to put together the modern flight model. The second thing is that these scalars are not necessarily normalized so that the desired behavior always lands at a scalar value of 1. They’re just multipliers into the inputs of the flight model. A lot of the early pilot feedback (of which there was a ton sourced) and alpha/beta feedback was related to wanting more flight model stability, and so that’s how the internal coefficients that the scalar drives was arrived at. It’s totally OK to set these scalars to non-1 values to get the specific effects and target coefficients you’re looking for. We will be looking adding configuration values that make using those a bit more intuitive in the future. However, that’s not so much an indictment of the flight model as it is the documentation and communication.

Lastly, as explained to me, the flight model normalization step is really just there to get you to your target Cl and Cd and such; it doesn’t integrate down to an FSX model as is posited here. The geometry section is ultimately what has the most influence over this, but since so much is based on those, getting to a target Cl and Cd by messing with the geometry section alone can be super tedious and frustrating. So, the normalization step will ever so slightly adjust the individual contributions of each of the 1000-ish segments (of which each separate contribution is calculated in real time, it isn’t “baked”) by generating some normalization scalars, to reach your overall targets. If the normalization step is producing huge numbers, then it’s likely your geometry is not actually very correct for the results attempting to be achieved. It should be just barely nudging things.

We’re talking about ways we can better discuss the FM from top to bottom, perhaps some presentations as we proceed throughout this year. We’ll see how things go.

-Matt | Working Title


the ‘rubber-bandy’ rudder / yaw effect is being worked on? That right there is a big positive indicator.


It is, at the individual flight model config level. Things like the vertical stabilizer area and associated scalars, etc.

-Matt | Working Title


This is wonderful news.

1 Like

…so can we talk about the fly-by view now?..

Anyone already tried this? Im sceptical as it mentions nothing about what they changed and on what data or experience. But maybe one of you guys has tried it and can review it?

First of all, let me say that I appreciate, and can imagine also everyone in this Topic, that someone working with Asobo could share these informations!

My perception is that the Modern Flight Model has the tendency to overestimate Stability Across the range of Aircrafts. From the Ultralight, to CRJ and Airbuses, it always will by standard calculate by Default too much Stability, specially on the Yaw and Pitch Axis. Its interesting you mention the Scalars are not normalized, because thats exactly oposite of what is stated multiple times at the SDK. It always make the Point, for multiple atributes, that a value of 1 should be the most realistic solution found by the Simulator for the entered aircraft attributes. If thats not the case with the Control Surface Scalars, maybe I think it would be better for it to be more clearly stated.

Another issue that comes to my mind, is that the Simulator has taken this approach of the Virtual WindTunnel, specially because they wanted a system that would make developing easier and faster, by having a system that would use the real dimensions and data for the aircraft, and come with the solution on it’s own, resulting in a more realistic output that would be possible than by estimates and guessing from the Developer to approximate the desired result. That would be specially true for airplanes that has no Aerodynamic Data available online, which are actually the case for most of them. Not even the Airfoil for many of the modern GAs are available since that is all classified information.

If the Scalar are not normalized, and the Virtual WindTunnel is unable to achieve satisfactory results, note i am saying satisfactory, because achieving a spot on Aerodynamic Model for an airplane based on a computer is something that only professional grade CFD Simulations on SuperComputers can do, so that will never be a realistic expectation from a Desktop Simulator, but Satisfactory I mean around the ballpark of what an airplane that would be allowed to be certified by being having resonable and predictable flight handling, that should be a priority IMO for the Team for the next Sim Updates.

Its a simulator still in its infancy, an I dont think we should expect the same level of fidelity other Sims have achieved after over 10 years of continuos improvements and polishing. Having said that, when there is a trend of Overstimation of Stability by the Modern Flight Model identified on most, if not all, aircrafts available since launch, unless the developer has worked on the issue himself to overcome the initial undesirable result, it’s for me easy to wish that Asobo team worked themselves on why this is happening in the Core of the Calculations, and bringing it closer to what an airplane, even the most exotic ones, should present as derivatives, translated as terms of flying qualities, that should be within range of the most extremes oposite values that would be within bounds of what doesnt translate into a very undesirable flying experience. The same happens for real aircraft certification steps, and its not what the exactt nmbers that matters, but if its within acceptable parameters.

Hope these kinds of chat between users and Asobo team, increases, as it can be very beneficial for both sides to make this experience better!


Perhaps you could point me to the areas in the SDK where it makes this point about the scalars. I don’t disagree that this is the most intuitive expectation, but I’m not seeing where this is specifically pointed out and we definitely want to make sure that this is cleared up if the SDK docs are saying that.

I’m not sure I totally follow why normalized scalars are a requirement for accuracy (and again, I’m not saying having them normalized is a bad thing). They’re just variables into the flight model. If the internal code has a coefficient of 1.5 and the scalar is 1, that’s not any mathematically different than internal code with a coefficient of 3 and a scalar of .5. The output force calculations will be the same.

The team (well, mostly Seb) is working on additional parameters that will enable some scalars themselves to be more normalized. However, a number of planes have been built on the dynamics as they exist today; you can’t simply just change internal coefficients without breaking the world, so to speak. The knowledge that the individual planes have too much stability is known and is being worked on for each individual plane. And I can see what we can do about adding recommended values to the documentation. But indeed accurate stability derivatives can be achieved with the right scalar values, today.

-Matt | Working Title


I think what is missed in this topic… I think the decision was made to make this more of a ‘game’ than a ‘simulator’.

Maybe the devs will move more towards the simulator version as time goes by.