A couple of questions for the fellow VATSIMers here: I haven’t used VATSIM that much with MSFS yet and have just recently found out about the altitude reporting issues related to MSFS’s weather model.
Am I correct that the only workaround currently available is flying with the weather set to “clear skies”? Or are the controllers, in your experience, willing/able to deal with this somehow and can still make it work?
And finally: does anyone know if the issue also occurs when using Swift as a client instead of vPilot?
Thanks a lot!
The bug has been fixed some time ago. All good now.
Thanks for your reply! I actually still have the issue: LittleNavMap shows my altitude correctly but all the VATSIM maps (vattastic, SimAware, etc.) show my altitude up to 2,000 ft too high.
Or is that just a problem with the online maps and the controllers see the correct altitude?
Hmm. Odd. The issue is/was to do with the realistic pressure-temperature model introduced to MSFS that the API used by Vatsim and other third party mods could not correctly translate as they used a more simple model. But now I might see a variance of 50 to maybe 390ft on LNM or vatspy. But not the 1000s of feet that the original issue caused so I really don’t know why you might be experiencing such large differences.
I’m not sure what the controllers see, but I too still notice the issue, at least when looking at my flight on vatspy. Yesterday, I was cruising at FL360 and my altitude on vatspy displayed as FL375.
Same API so the controllers should see the same thing.
I flew the Newark shortfield ops event last weekend and there were dozens of aircraft in various approach patterns, all at 4000ft and we were definitely all at the same altitude judging by the number of urgent deviations required…
But then the issue gets more pronounced with altitude. My view is that if the controllers are happy, then I’m happy.
I’m glad I’m at least not the only one with the issue. It is plausible that the differences in the atmospheric models may be negligible at lower altitudes depending on the circumstances. Unfortunately, at higher flight levels it becomes impossible to ignore, as @TheHoser11 pointed out: I’m seeing FL411 instead of FL390, or FL350 instead of FL340, and so on…
Not necessarily “clear skies”, any preset will do. I just pick one that is closest to the real weather for my flight. Set altimeter to 29.92, and off you go. Until the online networks can figure out how to deal with a sim that takes non-standard lapse rate into account (MSFS) and all the rest (that use standard lapse rate no matter the real conditions), this is probably the best work-around.
Thanks, that’s what I was afraid of. But for the time being, being able to use presets is at least a lot better than being limited to clear skies. Of course, disabling live weather still is a huge sacrifice, especially now that the depiction is getting better and better… The price of progress, I guess!
With “Live Weather” I was being reported at 31,149 when I was shown as 30,000 in the aircraft. I switched to “Clear Skies” and using “REX Weather Force” and the variation dropped to “Showing” 30000 and “Reporting” 30,193. So, “Live Weather” certainly causes an error in apparent altitude reporting, which is a pity as it is really impressive after latest update/
Is this still an issue? Currently cruising happily FL390 in the sim, but VATSIM shows me at FL382:
Edit: Changed to clear skies and then all is fine after settling down…
Different tools/maps solutions used different variables to determine the planes altitude. Not sure what the controllers is seeing, but I have never had any issue with them complaining about me not maintaining my assigned altitude.
this is still causing massive issues on VATSIM. Anyone using MSFS reports correct altitudes to ATC, but physically we cause massive issues with actual altitude depending on altimeters. Flying in FNO now, we are experiencing several TA alerts when we shouldn’t because of the difference in altitude reporting between sims.
inside aircraft on gauges all looks correct, they fixed QNH error but looks like they didn’t fixed this inside some Simconnect/Vatsim vars depended. I reported this also inside official SU8 thread.
It is not on MSFS side, but on the Vpilot side where changes are required to use the proper variables from MSFS.
At least, that is what I understand.
so logically something was changed inside MSFS to need rework on Vatsim SWs, correct? Really I’m confused here because I expect look at data/variable at one specific, not changed inside MSFS/SDK.
The variables in MSFS have changed indeed to enable more accurate atlitude modelling/info - as far as I know.