Donstim

The aircraft tracking debug window in dev mode will give you the ground and air distance separately as well as the total distance from when you opened the window. Takeoff and landing distances include both a ground and an air distance. You can get the ground distance easily from the debug tracking window, but to get only the portion of the air distance you want it works best to make a video to be able to separate out the portion of the total air distance that you want to add to the ground distance to get the complete takeoff or landing distance.

I reported in on the developer's forum. Do you have access there?

Thank you for posting this. Sorry it took so long for me to respond. This is showing exactly what I described. The wind on the ground was the input wind divided by 1.94 (the meters/second to knots conversion factor). The wind started increasing just after you left the runway. It looks like it just reached your input value of 33 knots at the end of the video when you were at 1240 feet radio altitude. From this, it is easy to conclude that MSFS 2024 is using the wind speed in meters/second (as your input wind in knots was divided by 1.94) on the ground, and the wind is in knots in flight. There is a transition gradient between them that appears to be on the order of 1200-1300 feet. Sorry, never worked on any projects for XP. I think others have already pointed out that you are missing the point here. The intent is to use a custom weather setting such that there will be no wind gradient, that is, to have a constant wind from a specified altitude all the way to the ground. This can be done very easily in MSFS 2020, but is impossible in MSFS 2024. Only the issue of the winds being increased by a factor of 1.94 every time the wind input in the weather dialog box is opened is associated with this setting. The bigger issue (at least for me) of having in-flight winds 1.94 times higher than the ground wind (with a wind gradient as you near the ground) is not caused by this setting, nor is it resolved by using either the US measurement system or the metric measurement system. I've checked it with both the US measurement system and the metric measurement system. In both cases, the in-flight wind is 1.94 times higher than the wind on the ground with a wind gradient applied starting at a low altitude (somewhere around 1000-1200 feet). If the US measurement system is used, the input wind speed is taken as knots, but is converted to meters/second (divided by 1.94) when on the ground. In flight (above 1200 feet), the wind will be the input wind. If the metric measurement system is used, the input is taken as being in meters/second, and will be the wind used when on the ground. In flight, the wind will be converted to knots, and will be 1.94 times the input wind. In both cases, the in-flight wind is 1.94 times the ground wind, with the transition occurring gradually from ground level up to about 1000-1200 feet).

Where is your 33 KTS (or 16 KTS) displayed? How about a video?

It isn't a switch at 800 feet. It starts to occur as soon as the airplane is off the ground. The reason that is a factor of 2 (or 1/2 depending on your perspective) is, as I tried to explain before, a faulty use of converting units from meters/second to knots, or the other way around. MSFS 2024 seems to be confused over what units the wind input is and what the wind should be in the sim. When the inputs are approximately doubled (such as when you have made the input while on the ground and the airplane becomes airborne, or you simply re-open the weather window and look at the wind value), it is converting from meters/second to knots. When the input is halved, such as when you are in the air, and you input a wind value, it is converting from knots to meters/second. You have to be careful about how you are verifying what the wind actually is in the sim. You can do that by using the simulation variables (simvars) "ambient wind direction" and "ambient wind velocity." The wind won't increase in a step fashion, Asobo a while ago put in a nice, smooth transition for wind changes after step changes from live weather caused a lot of problems. So you won't see the wind suddenly jumping when you go from the ground to being airborne, or vice versa, but you can definitely see it start to increase immediately after becoming airborne and end up at half the value input in flight when the airplane touches down. I've made a little video that shows the increase after liftoff. (Ignore the piloting; I did not bother fully set up the MCDU or to even watch what I was doing input wise.) 2026-02-23 18-52-02.mp4

The issue in the post you replied to is not an airplane developer issue. It is purely an Asobo bug in the custom weather settings. It is based on whether the airplane is on the ground or not, or as was shown in the video in this post , any time you re-open the weather window and look at the wind that is set. That is different than the parameters that allow developers to specify when a crosswind effect starts being appled.

That appears to be the same unnecessary and unwanted meters/second to knots conversion (and reverse). Just manifested a bit differently.

I have encountered the same issue and have given up on being able to do crosswind testing in MSFS 2024. I have tried one wind layer at the ground, multiple wind layers all with the same wind speed/direction at different altitudes, and just now with @LRBS's suggestion of setting one layer at 10,000 feet. Here is what happened on that last attempt and my hypothesis of what the problem is. On the ground at KLAX 25R, I moved the wind layer up to about 10,000 feet and set a wind of 40 knots at 340 degrees, gusts 0 knots at 340 degrees. Shortly after takeoff (I have a screenshot at about 2100 feet), the wind had increased to nearly 80 knots (340 degrees). To get the wind back to 40 knots, I had to change that layer to about 20 "knots." Returning to land, as I neared flare height, the wind started decreasing from 40 knots, reaching 20 knots by the time I touched down. What looks to me like what is going on is that the MSFS 2024 is confusing meters/second and knots. It seems to take the input wind speed in knots fine on the ground, but once airborne assumes it is in meters/second and converts it to knots (nearly doubling it). So to get the right speed in knots in the air, you need to halve the value of the desired wind when entering it in the custom weather window. Then when you get back to the ground, it converts it back, so that the wind you put in the weather window is what you get (which is half of what you wanted).

I'm a little curious as to where you came up with these entries as many of them are either deprecated or non-existent in the FS2020 SDK, and only a few of them would affect the behavior the OP is concerned about.

By jove, you've found it. I had my winds set with AGL for exactly this reason. I had found this some time ago, and that is why I changed to using AMGL, but had completely forgotten about it. @LRBS If using the AMSL altitude basis for preset weather, the winds are halved for some reason. The total wind velocity is halved, so both headwind/tailwind and crosswinds are affected. (Don't ask me why!☺️)

Interesting. Have you tried it with the default Asobo 787-10? I think that one has the crosswind parameters set to use the real wind by default. At least, I don't remember having to change them.

If you install the MSFS SDK, Simvar.exe should be in C:\MSFS SDK\Samples\SimvarWatcher\bin\x64\Release That's for MSFS 2020. I don't know if it would be any different for MSFS 2024.

Good question. Are you manually entering or confirming the correct value for the 2 ground crosswind parameters into the Flight Tuning section of the flight model.cfg file and making sure there isn't a different entry later in the file? Are you doing this before starting MSFS? I just confirmed that the PMDG 737-700 works the same way I showed for the default Asobo 787-10 once I manually edited the 2 crosswind parameters to change their values to -1000. Screenshot below. The true vs mag heading issue remains as well. Not sure about that one. Screenshot 2025-03-30 114058.jpg

The same wind direction issue is present with live weather. I just confirmed it with the 787, and @fsiscool's screenshot shows it as well (magvar for KJFK is 13 degrees W). Screenshot 2025-03-30 083310.jpg

Sure it is. Which airplane did you use? See below screenshot for the default 787-10. I also included the Simvar watcher window, which shows exactly what wind is being applied in MSFS (that is, for the default ground crosswind parameters it will show half the crosswind that is input in the weather UI). The ambient wind velocity/direction and ambient wind X (crosswind) all show the full 20 knots of crosswind being applied. @jcomm the Simvars show wind direction referenced to true. Since the ambient wind direction Simvar is the same as the wind direction that was input in the UI, this implies that input winds are referenced to true. Note that the 787-10 cockpit wind display shows a different direction, which is different by approximately the magvar for that runway. Normally wind direction shown on airplane NDs is referenced to true, but I don't know if that's the case with the 787. If it is, then there is something either messed up with the display coding, or there is something odd about manually input wind direction in MSFS and the Simvar depiction of it. Screenshot 2025-03-30 080741.jpg

Here we go again. Those parameters affect the crosswind velocity vs speed, which is what you are seeing. This is indeed a meteorological condition, not an aerodynamic adjustment. But changing the crosswind that is applied (halving it in this case) compared to what the "real" wind condition is effectively affects the aerodynamic response of the airplane to input crosswinds. If you want to have the actual crosswind velocity applied, these parameters need to be added in the Flight Tuning section of the flight model and each set to the value of - 1000.

Since your native language appears to be something other than English, you may have misunderstood what I wrote. The FMS does not provide the wind direction/speed information on the ND for either the A320 series nor the A380. This information comes from the ADIRS. When the airplane is on the ground, it's track is constrained by staying on the runway. This means that the airplane is pointing (heading) in the same direction it is traveling (track). The track and heading sides of the vector triangle are in the same direction. What does that mean for the "final" side of the vector triangle? Edit: A350s and A380 may be different than the A320s in regards to being able to determine the crosswind on thoe ground. It may be through the sideslip probes.

I am also having trouble posting here using my computer, so I have to do it using my phone. I realized shortly after posting my message that I had not used a direct crosswind, so I did that later. But with the posting issues and @MattNischanchiming in, I did not post it. Also, the assertion that the airplane knows the accurate wind while traveling down the runway is incorrect. It can only know the headwind/tailwind component accurately because there is no difference between the heading and track of the airplane during the takeoff roll. You can see the wind depiction change as the airplane weather vanes after takeoff: As an aside, it isn't the FMS that computers the wind direction/speed in Airbus airplanes. Finally, while wind velocity is technically unrelated to magnetic variation, it is extremely important to know whether the reported winds are relative to true or magnetic north in areas of significant magnetic variation when trying to determine headwind/tailwind vs crosswind component.

Looks like another issue caused by a flight model that limits the effects of crosswinds on the ground. Notice the wind you have chosen is basically a direct crosswind. Do you know what the ground_crosswind_effect_zero_speed and ground_crosswind_effect_max_speed values are in the flight tuning section of the airplane you are using to show this issue are? I suspect they are effectively halving the crosswind value at the speed you are at in the screenshot. Here is an example in FS2020 for an airplane for which there is no canceling out of the crosswind. I set the surface wind to 164/20 at KSEA 16L. (Note: in the screenshot I forgot to scroll back up to show the steady wind direction, but it is 164 degrees (same direction as for the gusts, but the gusts are set to zero.) You can see from the ambient wind velocity and direction Simvars {in the Simvar watcher) are indeed 20 knots at 164, and the aircraft wind Z (longitudinal direction) is also about 20 knots (more on this below). The airplane ND display shows the wind true direction (correcting for the runway's 16 degree east mag variation. Now there is an issue here in that this correction should not have been applied here. When you input a wind in MSFS 2020 (or get it from a METAR with live weather), the direction is already true. And if you do the calculations, the Simvar wind speed of 19.2 knots is due to the difference between true and magnetic headings (with the wind being at 164 true and the airplane being at 164 magnetic heading). https://1drv.ms/i/s!Ajsy7Ey4_8uFgaZNY1P0lDxHqL6Nqg

No comment on that one other than I don't think MSFS 2024 allows for that type of damage. There are several issues here: 1) MSFS does not have the correct braking coefficients (at least not what is used for transport category airplanes) for these surface conditions. 2) What you see visually in the sim for the surface condition may not be the same as what is used for the flight physics (that is, you may see a snowy surface, but a dry surface may be what is being used for the physics model. You need to look at the surface condition simvar to see what is being used for physics. 3) It can be difficult to get other than a dry surface condition for the physics model even with custom weather and even much more difficult when using real weather. This has been discussed pretty extensively. As with FSX, crosswinds were completely zeroed out up to a certain airplane speed on the ground in the original version of MSFS 2020. This was changed in SU10 to allow the developer to specify the speeds at which the crosswind starts to phase in and the speed at which 100% of the crosswind is applied. The developer could also tune the lateral motion of the airplane on the runway at higher speeds during takeoff. With SU15, a new ground contact model was introduced with further inputs available to the developer for tuning both longitudinal and lateral friction. With both SU10 and SU15, these new capabilities are not applied at all unless the developer sets these parameters. For MSFS 2024, both of these changes from the original version of MSFS 2020 remain in place along with some additional physics changes "under the hood" that are not yet well understood/explained. See above. I don't know what was used in the flight model of this airplane for that behavior. For the standard A330 (accepting your typo in reference to the airplane you were talking about), although it ostensibly uses the new parameters available since MSFS SU10 and also includes activation of some portions of the new ground contact model of MSFS SU 15, they have chosen to phase in the crosswinds very slowly from 0 crosswind at 0 knots airplane IAS to all of the crosswind at 207 knots airplane IAS. The new ground contact model for longitudinal and lateral friction are basically disabled as well.

First time I've looked at that SDK information and it gives me great pause. I hope most of the issues are just attempts at rough approximations for calculations and are not indicative of FS2024 physics calcs. For example, there is no effect of runway slope on takeoff or landing distances. And this is the first mention (in the Notes on Takeoff Distances) I've seen of the rolling friction assumed for wet and dry runways. In IRL jet transport performance, we never used different values for wet and dry runways, and the value we used is only about half the dry value shown on that page. That's probably why we have to artificially increase ground idle thrust so much to get realistic taxi performance. The takeoff distances don't seem to consider all the different factors that may be involved, unless that is supposed to be "baked" into the numbers supplied by the developer. There doesn't appear to be any accounting for reduced thrust/derates. I have no idea where the safety margins that are applied to the distances came from, but they are not appropriate for transport category airplanes. (These are just a few of the issues/questions I have about this SDK content.

While the flight model inputs affecting ground handling may be exactly the same between 2020 and 2024 for a given airplane, we don't really know whether the simulation using these same inputs has changed between 2020 and 2024. Nothing has been provided publicly through the SDK or the development forum to developers to specifically identify any such changes.

What? They absolutely do not. If you own the airplane, you can check the flight_model.cfg file yourself. I'm sure that @lwt1971 would agree with me that the inputs to turn on the new ground contact model are not there.

Ok, I agree with you on SU10 vs SU15. The point that I was trying to make still stands (that the Fenix does not make use of the new ground contact model -- in either FS2020 or 2024).

No, that is not the new ground contact model. Those are adjustments made to the "old" ground contact model. See the SDK here regarding how to invoke the new ground contact model: https://1drv.ms/i/s!Ajsy7Ey4_8uFgZ0pLWmSXZURMj7_jg?e=gCfp8u