Hey Aware – you got confirmation from Asobo that this won’t be fixed in time? Is this real??
1 Like
Why should this be considered a “critical bug” if you can’t use VATSIM on Xbox anyhow?
[edit] I believe I missed this problem could be affecting PC gamers as well.
Uhhh because this sim isn’t just for Xbox users… and this bug impacts several 3rd party tools (anything that reports your altitude levels, like SimtoolkitPro, etc.)
Why wouldn’t they fix this?
2 Likes
Is it not critical that the altitude is incorrect???
Only a very casual gamer can think that the altitude is not a critical part of a flight sim.
2 Likes
What is this issue exactly, do you mean aircraft are not changing to 29.92 above transition altitude or with 29.92 set the pressure altitude is wrong. The latter is part of the whole temperature error problem.
For assurances I repeated the 4 tests at SEQU from above, and can confirm the exact same results with the current build.
2 Likes
This HAS to be fixed, I was doing shared cockpit with someone on SU4 and even at FL200, he was 400ft higher than I was, on the same pressure setting. It will get even worse as you get to FL300+
This is going to cause huge issues for online networks, and frankly, it’s something that just should not be wrong in a flight simulator in the first place.
3 Likes
I wonder how this is IRL: are actual aircraft cruising around at FL380 really up to 2000’ off geometrically just because of temperature differences?
The rule of thumb of 4’/1000’•C yields that this is possible with a ground OAT of 2C, so it’s a physically plausible scenario. That being said, that is indeed going to cause problems with VATSIM flying, especially since no other simulator VATSIM supports does this.
The calculation for sure needs to be improved so it’s less spastic and actually correct for weather reporting stations that are at an altitude above 0’ MSL, but this is a necessary feature of a flight simulator. If it’s gonna cause that much of an issue on VATSIM, maybe it should be an optional feature you can switch on/off?
I don’t know for certain though, I’ve never actually used the beta so I don’t know how bad it is.
Yes definitely, low temperature and maybe combined with a low QNH and true altitude is way lower when using standard pressure (using flight levels).
Problem is that the temperature effect is not applied to the atmosphere itself affecting the pressure lapse rate, it’s rather an “error” directly applied to the altimeter in MSFS which causes a disconnect between the pressure altitude and the indicated altitude.
We really need someone to chime in on this bug. I worry the closer we get to the 27th without some type of answer means we are less likely to get a fix. I can see this being a difficult issue with Tracon Tuesday going on.
Oh I see what the issue is now…instead of the weather engine using a 3D pressure map of the atmosphere and calculating the static pressure the aircraft sees based on this map, it’s calculating it using a simple non-temporal linear equation with many assumptions.
I have long advocated for the 3D pressure map technique (and then linearly or quadratically interpolating), though with the time left to the SU5 release I’m really wondering if this will even be possible by then.
This is what is going on:
@OlieTsubasa443 @Jummivana Is it possible to find out if this will be fixed before release? It may not look like it from a dev point of view but. for a simming point of view this is a MAJOR ISSUE. This needs fixing before release… This cant wait 2 months for SU6!
7 Likes
To add, these threads all have the same root cause:
https://forums.flightsimulator.com/t/high-altitude-altimeter-setting-wrong/418320?u=nijntje91
https://forums.flightsimulator.com/t/barometer-not-going-to-std-or-vice-versa/418490?u=nijntje91
https://forums.flightsimulator.com/t/atc-altitude-off-above-fl180/423299?u=nijntje91
https://forums.flightsimulator.com/t/please-expedite/420141/9
https://forums.flightsimulator.com/t/bug-logged-altitude-setting-logic-confused/415190
https://forums.flightsimulator.com/t/atc-not-reading-back-proper-altitude/416494
5 Likes
I don’t think they’re going to redo their entire altimetry calculation method; I think they’re more likely to just slap bandaids on it.
We need to provide legitimate alternate solutions if we want them to seriously redo it. What do you guys recommend for a pressure calculation methodology? (As I said, I always advocate for 3D temporal pressure mapping on the server side and interpolation on the client side).
There are basically two main flaws in the current implementation:
- Temperature error is applied to the height above sea level rather than the height above altimeter setting source. The addition of temperature error has the added complexity that the elevation of the altimeter setting source needs to be taken into account. I assume the sim gets pressure data from Meteoblue or METARs, the way it was before, without temperature error (standard lapse rate) you can directly use this QNH as QFF (the actual pressure at sea level). With the addition of temperature errors you can’t simply take the QNH and use it as the ACTUAL pressure at sea level, instead the altimeter setting source should be the starting point, everything above the pressure lapse rate needs to be affected by temperature.
- Temperature is not affecting the pressure lapse rate in the sim, instead its a fake error they apply to the altimeter reading. You can easily see this when using standard pressure (1013 / 29.92) and standard temperature (15C at sea level), pressure altitude and indicated altitude are the same as it should be. When changing the temperature a difference between the indicated and pressure altitude equal to 4 per 1000 ft per 1C ISA deviation can be observed. This is obviously wrong, when the altimeter is set to 1013 / 29.92, the altimeter should read pressure altitude, regardless of temperature! Thus the atmosphere itself is not affected by non-standard temperature.
Regardless of the approach they choose, this should be the end result:
- Pressure altitude versus ambient pressure shall match ISA tables!
- With the correct QNH set on the ground → the altimeter shall read aerodrome elevation no matter the temperature.
- Standard (1013.25 hPa / 29.92 inHg) set → altimeter shall read pressure altitude, no matter the actual QNH or temperature. If QNH is standard with the aircraft on ground, the altimeter should read pressure altitude = aerodrome elevation.
- With non-standard temperatures the pressure lapse rate needs to be affected in such a way that the true altitude versus indicated altitude differs. This temperature error shall be based on the aircraft height above altimeter setting source (aerodrome level) and NOT mean sea level! At aerodrome level, temperature error is → ZERO!
- Temperature error should match the real world as close as possible, not using the 4 ft per 1000 ft per 1C ISA deviation rule of thumb. Its just that, a rule of thumb. Its not allowed for use in the real world for temperatures below -15C. Let alone something to base the whole atmospheric model on
More info here:
1 Like
I don’t know what you mean by differentiating beteeen red-oing the altimetry system and slapping bandaids on it. Asobo has been presented with exactly what the problems are and where they need to be when they are fixed. HOW they fix it is to a certain extent up to them.
In my opinion, this thread should be closed as further posts run the risk of simply adding noise and confusion. There is already plenty of that in all of the threads @anon50268670 listed as pertaining to this issue.
1 Like
Please do not close this thread. It looks like (thanks to @Viralwhite letting me know) that Asobo has officially changed the thread to BUG LOGGED, so that’s at least some news on the altitude bug.
6 Likes
Hi everyone,
Seb, myself, and Royal have been working on this issue today, and we greatly appreciate all the help and high quality reports from this thread. I know that oftentimes it feels like communication is one way; unfortunately it’s hard to provide lots of granular updates just due to the mismatch in contributor volume here vs how many folks can be dedicated to just writing forum responses on the team end. And, in general, developer communication tends to be construed as promises and also tends to generate much more flak than it resolves.
That being said, I just wanted to chime in here regardless. We’re aware of the issue, we’re working on what we feel is a viable solution given the way the sim works and the data that is available which should eliminate the issues reported here. Full transparency: we’re up against it here, this may not make it into the retail release but may have to be a patch soon thereafter. But we understand the importance fully.
-Matt | Working Title
31 Likes