Well,

yes, unless you want to normalize among systems with and without "T" compensation.

I don't really know how it works presently with VATSIM and other online ATC solutions. I think they have to assure all clients are getting weather from a same source ?

If that is the case then MFS will fail since it has it's only source, although there are already addons that inject at least METAR data in the sim, and do not use their Live Weather for that.

Assuming all sources are in sync regarding QNH ( aerodrome and area ) then the simplest way is to simply adhere to the altitude being reported by the transponder based on it's setting, and represent the input from other clients using whatever pressure gradient the sim uses. If it uses ISA, then the aircract will be positioned according to ISA pressure lapse rates, otherwise if the simulator uses "T" correction then it should apply it to the network traffic that has to be represented in it's World.

14 minutes ago, jcomm said:

I don't really know how it works presently with VATSIM and other online ATC solutions.

Not so much for you since I guess you know it, but more for general knowledge.

https://www.skybrary.aero/index.php/Transition_Altitude/Level

point here, is your vertical distance from other aircraft is important, distance from the ground is not even a little bit important.

The result of this for example, is flying into a cold front maintaining the same indicated altitude, initially you will climb, then descend rapidly. IRL this doesn't matter much because everyone is in the same atmosphere (there is no way IRL to get an accurate QNH or QFF miles away from a meteo station anyway).

So after take off you get given a transition altitude (or pull it from the AIP) - at that point you change the altimeter to std, if you aren't going above that altitude you get updated QNHs from ATC if you are in contact with them, or just leave it until you enter the next controlled airspace if not (you can see the ground cos you are VFR - I've had cross country flights at 2000'AGL that got ).

Thats how it works sim/irl, basically the same.

So to me lapse rate is just a complete red herring to any issues seen between sims in different local pressures - the problem is fairly similar to different sims with different terrain meshes "floating" along the runway and around the airport - and the solutions the same/similar.

 

Just for curiosity sake, I leave here a very interesting and well done video on the subject.

Can skip to 15:30 direct to the very intuitive Q-codes explanation.

 

Finally, I should say that indeed my simplification posted above assumes no problem exists with the altimeter ( no malfunction ) and that the pilot is setting the correct reference level ( QNH or QNE, or even QFE ).

If malfunctions have to be taken into consideration then, a "frozen" altimeter due to a blocked static port - which is simulated in X-Plane and I believe also in P3D and MFS - the simplistic solution will not work.

In fact the solution has to include true altitude of the aircraft, seen as height from the reference geoid at the latitude it is flying.

Edited August 13, 20214 yr by jcomm

1 hour ago, jcomm said:

In fact the solution has to include true altitude of the aircraft, seen as height from the reference geoid at the latitude it is flying.

hence my question about this, because although my intuition is telling me, when I turn this very interesting engineering problem around, that there would always be a missing variable, my intuition is also telling me a standardized geoid altitude is a minimum necessary to solve this problem in any case. But I'm just "intuitively" seeing this, and this is why I wanted to confront this idea here. I must say I'm impressed with the quality of the discussion and the constructive exchanges between all of us here! I'm learning a lot in the process too!

Edited August 13, 20214 yr by RXP

47 minutes ago, RXP said:

elling me a standardized geoid altitude is a minimum necessary

In the situation where all sims are on the same weather, the "minimum necessary" is the static pressure on the aircraft (which is all an altimeter measures page 17-12 of the FAA airplane flying handbook pitot static system)

The problem arises when the weather is different, because if ATC gives one aircraft FL100 and another FL120 they could both end up flying on the same geoid altitude, in which case you want the plane flying at FL100 to place the other plane on its local FL120 and the plane flying at FL120 to place the other plane on its local FL100 and ATC to see them at FL100 and FL120

 

1 hour ago, mSparks said:

The problem arises when the weather is different

of course, this is the only case we're discussing here isn't it?

12 minutes ago, RXP said:

of course, this is the only case we're discussing here isn't it?

even irl the weather isn't necessarily the same (e.g. across a cold front)

https://airplaneacademy.com/why-and-how-much-temperature-affects-altimeter-readings/

 

Edited August 13, 20214 yr by mSparks

On 8/12/2021 at 6:24 PM, GoranM said:

 This has already caused some vatsim controllers a headache, because some of our testers are climbing to reported altitudes, but due to temperature variation, the altitude on vatsim controllers screens are showing different altitudes.

Haha, in realworld aviation, it's very same issue but in opposite, most advance airliner have the ablity to use it's air data computer to correct the tempture variation (like the A350's FLS or 737 with U14.0 FMC or 787 with newer software have the ablity but for baro-VNAV final approach only), but still show the uncorrected (variated) altitude because they would still need to share the same sky with some old steam gaugue cessnas.