Title: <GustAngle> field in .WPR weather presets is corrupted on save (multiplied by 1.94384) in MSFS 2024
Steps to reproduce:
-
Create a
.WPRweather preset containing a<WindLayer>with<GustAngle Value="180.000" Unit="degrees">(any value 1–360). -
In MSFS 2024 → Weather, load the preset from the dropdown. The editor correctly displays the gust direction as
180. -
Modify any field (or none) and use Save As to persist the preset.
-
Reopen the saved
.WPRfile and inspect the<GustAngle>value.
Expected: the value is preserved as 180.000 (or normalized to 0–360 if internally stored differently).
Actual: the value is written as 349.892, which equals 180 × 1.94384 — the well-known knots-to-m/s conversion factor.
Additional test cases (slider input → saved value):
| Input (slider, displayed as degrees) | Saved value in .WPR |
|---|---|
| 0 | 0.000 |
| 180 | 349.892 |
| 200 | 388.769 |
| 270 | 524.838 |
Ratio is consistently 1.94384 (i.e. kts/(m/s)).
Impact:
-
The
Unit="degrees"declaration is misleading — the field is being persisted as if it were a wind speed inm/srather than a heading in degrees. -
Third-party tools (ACARS clients, weather injection apps, mission editors) that generate
.WPRfiles using documented degree values (0–360) are read correctly on first load, but corrupted on the next Save As, breaking round-tripping. -
Fortunately the corrupted
GustAngledoes not appear to affect the simulator’s actual wind/gust behavior at runtime — the gust direction followsWindLayerAngleinstead. This is a persistence/serialization bug, not a runtime simulation bug.
Suggested fix: either preserve the input value on save (no conversion), or correct the unit declaration to reflect the internal representation. The same .WPR file format is used by MSFS 2020 and works there without this issue, so the regression is specific to the MSFS 2024 weather serializer.
