I find crosswind landings fantastic in the sim, with either the 152 or the Arrow (both of which I fly in real life). Taxiing and takeoffs are the problem. Way to squirrelly on the ground while taxiing. The sim also does not like aileron deflection on takeoff (crosswind correction). Flight dynamics for both are tremendous.
The coefficient by itself doesn’t tell the whole story, as you also need a reference length to go with it. So, it will depend on what that length is. For example, for a yawing or pitching moment, does the sim use the wingspan, semi-span or mean aerodynamic chord as the reference length? That’s part of it.
My theory is that they are not calculating 3D lift slopes for tail surfaces. That is, corrected for aspect ratio and sweep. They are using 2D lift data for an airfoil ( I think ). Also, they are not factoring in downwash from the wing in the lift slope of the tail surfaces, which would cut the tail lift in 1/2, approximately. So, when you combine those things, you could easily see a factor of 5 or more.
Moments of inertia also play a huge role in the yaw or pitch response. More testing is required. A work around would be to reduce the htail and vtail areas by “the factor”. Here’s an example for a vertical tail
2d lift slope = 0.1 / deg
3d lift slope for aspect ratio 1.5 with 30 deg of sweep = 0.037 / deg
@Alec246 Thanks for this very instructive post which is fully appreciated!
Hopefully Asobo will care deeply about what is mentioned here!
Good job Sir!
Thank you all for the support!!! It’s very appreciated it!!!
Thank you Jayne!! They know where to find me if they need anything
You are completely write! Marco had already warned me about that. It was a dumb attempt that I tried to make it easier for everyone to understand, but it’s just not correct, and I have already eddited the Post to remove the conversions. The good news is that MSFS2020 and the real C172 are in Radians-1, as it should be, so the original point is still 100% valid! Thanks
This is really not how it works in the Aviation Business. Just see how difficult it is for Jorg to get Airline Companies to allow their Liveries on the Sim, something 100X more simple than getting real data from the plane manufactures. They don’t want to be involved in anything they don’t have 100% control with. Almost all the data you can get for the aerodynamic of an aircraft is basically searching the internet, specially for university studies. And hope the plane you want to recreate has data on it, if not, you are out of luck.
Unfortunately it’s not as simple as that. In the case of the C172, was this attribuite on the .cfg. But everyplane will require some fine tuning, and when you change one value, it will affect 100s of others in the simulation, so it needs a lot of time to really get the FlightModel to improve in a consistent and realistic way across the envelope. Anyway, I’m doing my tweaks on the C172, and maybe if I think they turn out good enough, I will consider releasing it as a freeware mod for users to try!
I’m probably doing something wrong here, so thought I would check.
I have tried playing around with the “rudder_effectiveness = x” value for the 172 G1000, in a 9kt crosswind. I’m using dev. mode to re-load the plane between making changes to the file.
I have tried values from 2 to 0.01, and have not felt a significant change in the way the plane handles, during takeoff or landing.
I even loaded the classic, then switched back to the G1000 version in case the changes were not being loaded correctly.
There’s a huge factor in the way the Sim handles Crosswind right now, that makes it impossible to have a realistic experience during takeoff and landings. When the plane is stopped, the Sim removes all Crosswind Effect on the simulation, probably to avoid the issues with the extreme Weathervaning that happened during early builds.
As you increase your speed during takeoff roll, the Sim gradually injects more of the Crosswind, up to a point where it achieves the proper value that will be used in flight. During Landing, the same happens but inversely. Open the Speed Debug Tab in DevMode, and check the Crosswind speed there!
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.
This topic shows one thing for sure:
There are some scientists using FS
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?
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 )
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.
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
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