Setting custom winds in MSFS 2024

[AwarePlot117729]

Version: 1.7.7.0 (and earlier)

Frequency: Consistently

Severity: High

Marketplace package name: if applicable

Context: In built weather engine independent of any packages

Similar MSFS 2020 issue: insert url here if applicable

Bug description: It is impossible to set a constant wind speed for doing crosswind testing, which is needed for airplane developmental tests. I have tried setting one wind layer at the ground, multiple wind layers with the same wind speed/direction, and one wind layer at about 10,000 feet. It appears that there is an unnecessary and unwanted meters/sec to knots (and vice versa) conversion happening between the ground wind and the airborne wind.

Repro steps: An example setting a single wind layer higher than you intend to fly: With live weather turned off, and using any airplane at KLAX 25R, using custom weather, move the ground wind layer up to about 10,000 feet. Insert a wind speed of 40 and a direction of 340 with 0 speed gusts in teh same direction.

Take off. Note (via the ambient wind speed and direction simvars) that the wind speed rapidly increases to 77 knots, nearly double what was input, and is what the wind in knots would be if the input wind was 40 meters/second.

Go to the weather dialog and note that the wind speed value was changed to the 77 value. Input a value of 20, which is about half the desired value and note that the ambient wind speed value is now about 40 knots. (Sorry, no screenshot of that one.)

Complete your circuit and land. As you approach the ground, note that the wind speed starts reducing.

When you reach the ground, note that the ambient wind speed is now 20 knots, which is what you input in flight to have the wind speed be 40 knots in flight.

It appears that once airborne, the wind value went through a meters/sec to knots conversion even though the input value was in knots and treated as such on the ground. When reaching the ground again, the inverse conversion is then made. There is a transition between the two.

To add to this, once you set a wind speed in the custom weather window on the ground, closing that window, then re-opening it and viewing the wind speed will also cause the wind to increase by the meters/second to knots conversion factor.

Attachments:

Private attachments: Send a PM to @PrivateContent with the link to this topic and the link to download your content

[B21]

It’s highly likely you’re using the Settings → Language → Units of Measurement set to Hybrid

There are bug reports already posted for that. Most (all?) gauges have their own methods for determining a pilot’s preferred display units as AFAIK there’s no simvar telling the SDK API’s what the user’s ‘Units of Measurement’ setting so there’s very little common usage.

E.g. specifically to your issue see here where setting wind speeds with Hybrid Units set will rapidly pump up the speeds on each Wx load as the UI repeatedly converts between kph (m/s?) and knots. Wind speed incorrectly saved when using a Weather Custom Preset in Hybrid mode - Weather & Live Weather - Microsoft Flight Simulator Forums

It’s a broad issue. AI-assisted search is pretty convincing there IS an easy API access to find the Units preferred by the user in MSFS, but see below this is a hallucination which itself is interesting. Overall, users just need to be as simple as possible with their units and “Hybrid” isn’t really feasible given the underlying support.

But that simvar is not to be found in the excellent docs:

And indeed on testing with Settings → Units = “metric” ( so supposed simvar would be “1”) this fails on the first test in html/js:

[AwarePlot117729]

Thank you for your response. I am indeed using the hybrid units of measurement. Although I noted that closing and re-opening the weather window will repeatedly increase the input wind speed by the meters/second to knots conversion factor, that issue was not the main point of my post.

This is not a question of units for gauges, it is a broader issue with how the custom wind inputs are implemented in MSFS 2024. One simply cannot get a constant wind value from the air to the ground (or vice versa). Something that is possible (and very easy to do) in MSFS 2022.

I tried both the US measurement system and the metric system and still have the same issue. Regardless of the system used, it uses the wind in meters/second on the ground. If the US measurement system is used, the ground wind speed will be the input wind speed divided by 1.94. If the metric system is used, the ground wind speed will be the same as the input wind.

When the airplane is in the air, the wind speed in knots is used. If the US measurement system is used, the in-flight wind will be the input wind speed, which is 1.94 times the wind speed used on the ground. If the metric system is used, the in-flight wind speed will be 1.94 times the input wind speed (and also 1.94 times the ground wind speed). In other words, the in-flight wind speed is always 1.94 times the ground wind speed, regardless of which measurement system is used.

There appears to be some sort of transition gradient between the in-flight and ground wind speeds. I’m not sure what the exact height above the ground that the wind speed reaches 1.94 times the ground wind speed (somewhere in the range of 1000 to 1200 feet AGL), but if you level off below that altitude, the wind speed remains constant at that altitude.

[B21]

I understand your challenge - we glider pilots work quite a bit with the WPR settings. I agree there’s no getting around MSFS halving the ground wind speed, but with multiple wind layers you can kinda fine-tune that a bit.

E.g. the two lines in the graph below are approximate wind speeds 0..2000 feet AGL with the weather also set “AGL”.

Series1 (blue) has a zero-AGL wind set at 25 knots (hence the 12.5 knots recorded), and at 1640 feet (500 m) there’s another wind layer in the same direction at 4 knots, so you can see MSFS doing it’s “half the wind speed, start climbing to the specified speed, then start merging to the next wind layer” routine.

Series2 (orange) is the same idea but with the 1640 feet layer set to 20 knots - same halving/transition but with the different parameters.

You can finesse this with more layers (e.g. at 500 feet), and having the zero-feet wind layer at least gives you direct control over that value (i.e. half of that).

Net net, we generally accept the wind speed falling significantly mainly in the bottom 300 feet. Not exactly what we want but kinda livable for our ridge soaring.

Our main concern is Microsoft/Asobo don’t arbitrarily change what winds X/Y/Z are generated in the MSFS for a given WPR preset (Y is fairly crucial for us, but X/Z wind on the slopes matters a lot too). That includes the current wind halving at ground level. I.e. IF MS/Asobo make a change, then that should only affect a recognizably new version of the WPR file. We have great difficulty logging whatever WPR preset has been loaded as it is.

Couple of other comments in case they help (probably not, apologies):

* AMBIENT WIND VELOCITY is the 3D wind vector magnitude so including the vertical wind. This used to equate to the ‘conventional’ wind when there was no rising/sinking air in the sim, but now in MSFS the ‘wind Y’ can easily exceed the prevailing horizontal wind so that will determine the “velocity”. E.g. windsocks are using this ambient simvar but they can now show a 10-knot wind even though that is mostly the vertical movement of the air. Similarly planes are using ambient wind speed (i.e. the velocity simvar) and direction to work out what headwind/tailwind they might have but this is now flawed. For general wind use, sqrt(WindX^2+WindZ^2) is a more usable quantity.

* Not to harp on but I’d avoid the Hybrid setting for any winds testing - it simply introduces units bugs that really confuse any detailed testing.

[AwarePlot117729]

I’ve tried “finessing it” with multiple wind layers. As you mentioned, there is just no way to get a constant wind speed as you near the ground, which is what I need for crosswind landing testing. This is very easy to do in MSFS 2020, but impossible in MSFS 2024.

You may be concerned about “arbitrary” changes to what winds are generated for custom weather presets, but from my perspective, they’ve already done this. Edited to add: There is nothing arbitrary about either this issue or it’s resolution. It must be a bug that in-flight winds just happen to be the metric conversion factor higher than ground winds. I am simply requesting that this bug be fixed. As I understand your concern, when this is fixed you would like it to be associated with a change in version for the WPR files as a convenience so that you do not have to update them. That’d be fine with me; my concern is to get this bug fixed.

Thank you for the additional info on the ambient wind velocity simvar. I’ve already picked a testing location and weather parameters where the wind Y vector is essentially zero.

The hybrid setting does not really affect my testing with my testing procedure. Your advice is good and noted, and this is another bug that should be fixed.

[B21]

@AwarePlot117729

It must be a bug that in-flight winds just happen to be the metric conversion factor higher than ground winds

Ah, what’s led me astray here is this “bug description” conflates multiple independent “feature/bugs”:
(1) MSFS has a chequered history of exactly halving the wind speed in the WPR to apply at ground level and then tapering the wind to the WPR set value/altitude and then tapering that value to the speed of the next wind layer and so on. It’s unrelated to the units setting.

That is separate from these other two bugs:

(2) There’s a units bug in the Weather UI which means you can’t trust the wind speeds you read there. The wind speeds in the original WPR file are “safe” (i.e. read correctly, but then halved at the ground) so long as you don’t open the weather UI.

(3) The Weather UI in MSFS 2024 always reads-then-rewrites your custom WPR file in the Weather UI. This is a design disaster, as your custom WPR files are being silently re-written, including with incorrect values from the units bugs or any inadvertent adjustment in the UI.

There are multiple discussion threads on (1), and the “implementation” in MSFS2020 and 2024 has flip-flopped a bit (you could consider that a temporary bug fix but it’s equally described as implementation details).

There are bug reports for (2) and (3).

[AwarePlot117729]

Sorry, you are the one conflating the bug description. I was only reporting item (1) in your list while noting (3) briefly. I can deal with (2) and (3), so while it would be nice to have them fixed, (1) is a show stopper for me (and I assume every other airplane developer).

You say there are multiple discussion threads on (1), but the only ones I’ve found are in regards to MSFS 2020, which had the same issue, and that issue was fixed. (Example: SU15 Beta Wind Speed still bugged - [MSFS 2020] Questions & Community Discussions / Aircraft - MSFS DevSupport)It seems that we are back to square one again that regard.

Someone on an Avsim forum on this topic suggested the cause of this bug:

“In regular Live Weather, surface winds come from the latest METAR report (in knots) and winds aloft come from the MeteoBlue model. I believe the transition from METAR wind to MB model wind happens about 1500 feet AGL.

Wind speed in a gridded weather model is always expressed in meters per second. The direction is expressed in rectangular coordinates U and V in which the U is the east/west component and V is the north/south component. Actual direction is calculated by doing a rectangular to polar coordinate transform.

It appears that when winds are set manually, the entered direction is being used (as entered), but the conversion routines used for the MeteoBlue model wind speed are still active even though the model is not actually in play. That would explain why speed manually entered in knots is being interpreted as meters per second above a certain AGL altitude. It seems as if this would be an easy thing for the developers to fix. The MB model wind parser should be completely disabled when manually entering wind. The directional parser is indeed disabled, but the speed parser is still active when it should not be.”

It would be nice if someone from MS/Asobo would respond.