2 minutes ago, jcomm said:

Anyway, MFS is vatsim-ready from the ATC pov. Only "problem" results from presently there being no other wildly used desktop civil flight simulation platform that models the effect of "T" in non-ISA pressure lapse rates., and yet all having VATSIM ( an other ) ATC clients and getting out-of-sync altitude information among them when MFS aircraft are in play.

This isnt the issue.

The issue is that there is no way to sync the weather between clients, Lapse rate wont help when MSFS weather says there is a CB in the vacinity and the vatsim weather source hasnt updated any of the other clients or vice versa.

True, and that sometimes makes me think that it is probably useless to think of it in a way of being compatible with MFS, but rather in it's own way... Allowing for, based on the right weather source set by the client, having the modeled atmosphere adapt to the non-ISA lapse rates.

Same for non VATSIM flights.

See it as a new feature that would be nice to have in the next version of X-Plane.

Edited August 12, 20214 yr by jcomm

17 minutes ago, jcomm said:

atmosphere adapt to the non-ISA lapse rates.

There is two ways to deal with it.

Either Vatsim handles clients with different weather sources (even if XP next gen has more diverse weather system simulation, it would still be different between different sources)

Or Vatsim is the weather source - in which case its down to them to simulate lapse rate etc.

The root of the issue is msfs doesnt support Vatsim as a weather source (and doesnt plan to)

Edited August 12, 20214 yr by mSparks

Yeah, I agree Sparks !

pretty much THIS ==> "The root of the issue is msfs doesnt support Vatsim as a weather source (and doesnt plan to) " <==

 

5 hours ago, jcomm said:

pretty much THIS ==> "The root of the issue is msfs doesnt support Vatsim as a weather source (and doesnt plan to) " <==

FWIW, vatsim could solve the issue by having their client report computed pressure altitude (from current pressure&standard alt), thats how I deal with it for AutoATC - then it doesn't matter what the clients simulated weather conditions are, the server has a common view of everyones altitude and the client deals with putting them at the correct pressure altitude in sim. Of course, that will still cause issues for MSFS pilots being given bad a QNH from ATC for landing.

Edited August 12, 20214 yr by mSparks

17 minutes ago, mSparks said:

Of course, that will still cause issues for MSFS pilots being given bad a QNH from ATC for landing.

That's where the proposed solution on the thread linked on the OP can operate a kind of "normalization" that is full-proof... Problem is, it will require that ASOBO provides a new sim var.

Edited August 12, 20214 yr by jcomm

8 minutes ago, jcomm said:

Problem is, it will require that ASOBO provides a new sim var.

There are two issues.

At altitude, when everyone is on standard pressure, FL100 and FL110 can be the same altitude if the users have different simulated local pressure.

It would solve this one.

Near the ground, you need an accurate local pressure from ATC so you dont crash into the ground on an IFR approach, this is when everyone being on the same simulated QNH is important, but if its coming from different sources differences in update times of even a few seconds can lead to getting a QNH from ATC that plonks you down 1000 feet short or long of the runway (this is also a RL issue, which is why there are decision altitudes and ILS minimums)

I'm sorry I might have wrongly understood the topic, but it looks to me there is only 2 problems:

1) displaying other aircraft around you at their relative altitude to you

-> Why not just using the ECEF position for this? or the geodetic altitude?

2) sending to the controller a pressure altitude which is consistent amongst clients.

-> With the geodetic altitude and the client pressure altitude, you can calculate any appropriate offset per-client and send this to the controller so that all aircraft from a controller point of view are all at an ISO standard lapse, but each client is locally in its own pressure model.

Does it makes sense?

4 minutes ago, RXP said:

> With the geodetic altitude and the client pressure altitude, you can calculate any appropriate offset per-client and send this to the controller so that all aircraft from a controller point of view are all at an ISO standard lapse, but each client is locally in its own pressure model.

except

ATIS

@mSparks

In any case if heterogeneous clients are not using the same atmosphere, they can't share the same ATIS isn't it? In other words, unless all clients are sharing the same atmosphere, there will always be something in the network which doesn't match from one client to the other.

What I'm trying to understand is what is the factor I'm yet to see which would prevent using an implementation which remains local at the client level regardless of each one pressure, and unified at the controller level using an ISO atmosphere. The idea is the controller is only seeing clients in a standard model, ATIS is emitted in a standard model (I mean automated ATIS here for example). Each client is seeing his own world locally, and each client is seeing other clients at the correct relative altitude because for visuals it would use a geodetic altitude, not an atmospheric altitude.

I'm certain there is an unsolvable variable whichever solution when not using same atmosphere for all. This is what is making me wondering whether this approach would be the lesser of multiple evils for solving what I thought was the main 2 issues: displaying 3D model of other aircraft at the correct relative alt from you (hence using geodetic alt) and making the controller agnostic to the simulation atmospheric models by using a standardized view at the controller side.

PS: and the discussion in itself is helping me understanding this topic better as well.

Edited August 12, 20214 yr by RXP

1 hour ago, RXP said:

I'm certain there is an unsolvable variable whichever solution when not using same atmosphere for all.

There's big broad brush issues on STD which are fairly easy to resolve client side, everyones on 1013 anyway.

In airport airspace as long as they are reasonably close it doesn't matter. But there are good reasons pressure/weather can be funky around an airport, CB, inversions, windshear, and these are when juggling heavy traffic load is "fun".

Here, getting anything like realistic simply requires that all clients have the same weather simulation - ATC generally only updates every 30 minutes, so if the weather is changing what a client sees can be quite different than what ATC is expecting.

But if you are only landing one plane every 10 minutes no one will notice.

(EGLL IRL in normal conditions does a land + departure on average every 45 seconds)

 

Sorry for arriving late and staying short 🙂

The solution is pretty much the one we use in aviation meteorology, and one that usually plays tricks on the ATPL METEO exams... - QFF

If QFF is used as the reference for the normalization among clients then:

- those sims using ISA lapse rates will have QFF = QNH

- those using T factor will have QFF = QNH corrected for T

But, there's a catch 😕  Various methods can be used to calculate QFF... 

Play with it here: 

https://www.metpod.co.uk/calculators/pressure/

Edited August 12, 20214 yr by jcomm

19 minutes ago, jcomm said:

Sorry for arriving late and staying short 🙂

The solution is pretty much the one we use in aviation meteorology, and one that usually plays tricks on the ATPL METEO exams... - QFF

If QFF is used as the reference for the normalization among clients then:

- those sims using ISA lapse rates will have QFF = QNH

- those using T factor will have QFF = QNH corrected for T

But, there's a catch 😕  Various methods can be used to calculate QFF... 

Play with it here: 

https://www.metpod.co.uk/calculators/pressure/

Unless the local QNH is being estimated the same way from the same source, the baseline QNH will be different between clients, with one client estimating it just flew through a cold front and the other flying 1000 feet below thinking it is still 10nm away.

Edited August 12, 20214 yr by mSparks

9 hours ago, mSparks said:

Unless the local QNH is being estimated the same way from the same source, the baseline QNH will be different between clients, with one client estimating it just flew through a cold front and the other flying 1000 feet below thinking it is still 10nm away.

Yes, but OFC the QFF, or even the proposed solutions so far assume consistent weather sources among clients.

If the sources are coinsistent and all have equal QNH and Area QNH then a flag for the type of source sim so that the clients are marked as calculating or not "T" compensation, can be used to calculate the "height" of the aircraft, or, simply forget about it when exchanging positional data among clients.

This way when a client receives data from another “T-aware” client it simply proceedes, depending on itself being T-aware, with the positioning of the aircraft in it’s World at the same geodetical height OR in case they differ, at it’s local consistent geodetical height.

This all assumes consistent sources of weather data, such as T, QNH and area QNH among cliens, and also the same Geoid model ( WGS84 usually ).

For cold weather operations though, the simulators using the "T" compensation method might correctly represent situations like those that arrise from such situations, when for instance the altimeter, on a precision approach with the aircraft flying an ILS, shows the aircraft above the glidepath at reference points in the approach chart. 

Edited August 13, 20214 yr by jcomm

3 hours ago, jcomm said:

Yes, but OFC the QFF, or even the proposed solutions so far assume consistent weather sources among clients.

I'm not sure where this fits in.

IRL

If you are above transition altitude everyone is on standard pressure 1013/29.92, if you are near a station an accurate QNH stops you crashing into the ground, and everyone being on the same pressure setting stops them crashing into each other.

 

Edited August 13, 20214 yr by mSparks