The latest 'Global Scenery' still identifies the Airport ID as HSSS even though the ICAO code has changed to HSSK causing problems with some ACARS 'add on' software and Zibo FMC etc
The ICAO code in the meta data was changed, but this airport is not yet included with the latest distribution. Also (see the bug report about Harare) 3rd party avionics need to read the meta data for ICAO, not the airport ID (it will never change!).
That is a long story, I try the nutshell: The XPlane scenery system needs a unique ID to tie airports to a certain spot on the ground (so you avoid having two airports shown at the same spot if you have multiple versions like a custom one and the global airport one). This is the airport ID. Unfortunately, what is now the “airport ID” used to be the only ID for airports, so some legacy navigational apps (like the ones you mentioned) still read this by default. Also some airports dont have the meta data ICAO (or FAA) YET - so in this case the navigational app needs to “fall back” to the airport ID (because it is likely right).
I hear you @Jan Vogel, and thank you for replying.
Still think it is messy...but given there is a workaround, I guess I will have to live using that option
Meta data can be changed in WED and submitted to Gateway.
ICAO Code is correctly set to HSSK, this change is reflected in update 11.55 and can be seen on the map (m key) - unfortunately the default avionics do not show this new ICAO code, instead showing the old HSSS airport ID.
I will escalate this report to the avionics expert at LR.
HSSS has the icao code HSSS in the Resources/default scenery/default apt dat/Earth nav data/apt.dat so I don't see why the GPS should display anything different.
Transition level and transition alt can be changed in WED.
The GPS should display what the scenery artists set in the “meta data” field for ICAO code.
HSSS is the “airport ID” - this should only be shown as a fallback, if the meta data fields are not filled in.
You can look on the map (m key), which honors the new system. The avionics should as well.
In theory the avionics should look at “codes” in this order, only moving to next step if the field is empty:
1.) ICAO Code (meta data)
2.) FAA Code (meta data)
3.) Local Code (meta data)
4.) Airport ID
I am not sure how these codes are contained in the apt.dat - but the rest of the XPlane system (GUI, map, etc.) are looking for these entries.
The current practice for changing an ICAO code of an airport is to leave the airport ID as it is (in this case HSSS) and changing only the meta data ICAO code (to in this case HSSK).
Could be, Julian. I have linked this bug report in our Slack “airports” channel, so Ben and Michael can look at it as well. Not sure if something went wrong with the export or if the default GPS isn´t looking for the correct data - I assume it is the former. However it is strange that the “correct” ICAO is shown on the in-game map, but not on the GPS…so it must be known somehow.
@Litjan no need to explain to me how the system that I designed works.
The airport was not included in the gateway data export, probably because it failed the inclusion test (--check_global_airports). Only scenery updates that work with the default data are included in the Resources/default scenery/default apt dat/Earth nav data/apt.dat. If an airport update causes X-plane out of the box (i.e. with no Navigraph or Aerosoft data) to no longer work at that airport it is not taken down to default data. This is the case here: x-plane out of the box expects HSSS, not HSSK. Therefore, taking the update would disable the airport for users of a clean x-plane installation. Therefore, the update is not taken into the default data. The system works correctly.
Then the system (that you designed) didn´t take account of the new ICAO code in the Gatway data. The ICAO code of Karthoum is HSSK, it was added as that to the meta data and the airport with that meta data was included in 11.55.
Why “X-Plane still expects HSSS” I don´t know - but it shouldn´t, because that is not Karthoum´s ICAO code anymore 🙂
What is the intended way to change the ICAO code of an airport (if not editing the meta data)?
Absolutely nothing went wrong here, all components are working exactly as they should.
An ICAO ID was added in WED. This is the right way to change an ID, so that’s good.
The scenery was accepted and rolled into the Global airports, so it appears in its new version, with the new ID, in Custom Scenery/Global Airports/Earth nav data/apt.dat. That’s what causes it to be discoverable under the new ID in the start flight menu, for example.
For a gateway export, the Global Airports are tested against the default navdata that ships with the sim. Starting X-Plane with --check_global_airports pretends ALL airports have been exported, and then checks the default navdata by loading every single file in Resources/default data/CIFP, thereby loading every single SID, STAR and approach once given all airports as if they had been gateway exported already. Obviously, this test takes a good long while, as it literally loads all ±100k approaches
If you look at Resources/default data/CIFP, you will notice that the file for this airport is the HSSS.dat, not the HSSK.dat, because that was the ICAO ID in cycle 1802.
Airports that fail this test are listed in the ICAObad.txt file that is written at the end. This file contains the list of airports that don’t work with X-Plane out of the box. Since HSSK would not work with the Resources/default data/CIFP/HSSS.dat, the airport ID is listed as bad.
The gateway export does not export the known “bad” airports into the Resources/default scenery/default apt dat/Earth nav data/apt.dat, therefore the old version, without the ICAO ID HSSK, stays there.
I wish we had a way to update our navdata cycle to something more current…so the user experience for changed ICAOs in conjunction with our default avionics would be better in this regard. Curious to see what XP12 will bring in this regard.
You must be logged in to participate in the discussion
no taxi signs are visible along all taxi ways.
Jan Vogel March 8, 2021 7:16 AM
A new version including taxiway signs was made and will be included soon in a XPlane update.
The latest 'Global Scenery' still identifies the Airport ID as HSSS even though the ICAO code has changed to HSSK causing problems with some ACARS 'add on' software and Zibo FMC etc
Jan Vogel June 9, 2021 11:21 AM
The ICAO code in the meta data was changed, but this airport is not yet included with the latest distribution. Also (see the bug report about Harare) 3rd party avionics need to read the meta data for ICAO, not the airport ID (it will never change!).
T_McTry June 10, 2021 12:04 AM
Fair comment about dev's needing to address ICAO ID...but why shouldn't X Plane also reflect up to date Airport ID coding too, and not outdated data.
Jan Vogel June 10, 2021 7:25 AM
That is a long story, I try the nutshell: The XPlane scenery system needs a unique ID to tie airports to a certain spot on the ground (so you avoid having two airports shown at the same spot if you have multiple versions like a custom one and the global airport one). This is the airport ID. Unfortunately, what is now the “airport ID” used to be the only ID for airports, so some legacy navigational apps (like the ones you mentioned) still read this by default. Also some airports dont have the meta data ICAO (or FAA) YET - so in this case the navigational app needs to “fall back” to the airport ID (because it is likely right).
T_McTry June 12, 2021 4:46 PM
I hear you @Jan Vogel, and thank you for replying.
Still think it is messy...but given there is a workaround, I guess I will have to live using that option
Transition Altitude is 7000feet, Transition Level is FL090,
identifier should be changed to HSSK in x-plane, still shows HSSS, in default GPS and FMS.
Jan Vogel July 8, 2021 6:57 AM
Meta data can be changed in WED and submitted to Gateway.
ICAO Code is correctly set to HSSK, this change is reflected in update 11.55 and can be seen on the map (m key) - unfortunately the default avionics do not show this new ICAO code, instead showing the old HSSS airport ID.
I will escalate this report to the avionics expert at LR.
Philipp Ringler July 8, 2021 10:05 PM
HSSS has the icao code HSSS in the Resources/default scenery/default apt dat/Earth nav data/apt.dat so I don't see why the GPS should display anything different.
Transition level and transition alt can be changed in WED.
Jan Vogel July 9, 2021 12:06 PM
The GPS should display what the scenery artists set in the “meta data” field for ICAO code.
HSSS is the “airport ID” - this should only be shown as a fallback, if the meta data fields are not filled in.
You can look on the map (m key), which honors the new system. The avionics should as well.
In theory the avionics should look at “codes” in this order, only moving to next step if the field is empty:
1.) ICAO Code (meta data)
2.) FAA Code (meta data)
3.) Local Code (meta data)
4.) Airport ID
I am not sure how these codes are contained in the apt.dat - but the rest of the XPlane system (GUI, map, etc.) are looking for these entries.
The current practice for changing an ICAO code of an airport is to leave the airport ID as it is (in this case HSSS) and changing only the meta data ICAO code (to in this case HSSK).
Julian Lockwood July 9, 2021 12:45 PM
Could this be a missed step when the most recent Gateway cut occurred? (that populates the default apt.dat from the Gateway airport metadata)?
Jan Vogel July 9, 2021 12:52 PM
Could be, Julian. I have linked this bug report in our Slack “airports” channel, so Ben and Michael can look at it as well. Not sure if something went wrong with the export or if the default GPS isn´t looking for the correct data - I assume it is the former. However it is strange that the “correct” ICAO is shown on the in-game map, but not on the GPS…so it must be known somehow.
Julian Lockwood July 9, 2021 3:10 PM
@Litjan What happens if you remove the Global Airports folder .. do you still see the correct ICAO on the in-game map?
Philipp Ringler July 9, 2021 4:35 PM
@Litjan no need to explain to me how the system that I designed works.
The airport was not included in the gateway data export, probably because it failed the inclusion test (--check_global_airports). Only scenery updates that work with the default data are included in the Resources/default scenery/default apt dat/Earth nav data/apt.dat. If an airport update causes X-plane out of the box (i.e. with no Navigraph or Aerosoft data) to no longer work at that airport it is not taken down to default data. This is the case here: x-plane out of the box expects HSSS, not HSSK. Therefore, taking the update would disable the airport for users of a clean x-plane installation. Therefore, the update is not taken into the default data. The system works correctly.
Jan Vogel July 9, 2021 6:53 PM
Then the system (that you designed) didn´t take account of the new ICAO code in the Gatway data. The ICAO code of Karthoum is HSSK, it was added as that to the meta data and the airport with that meta data was included in 11.55.
Why “X-Plane still expects HSSS” I don´t know - but it shouldn´t, because that is not Karthoum´s ICAO code anymore 🙂
What is the intended way to change the ICAO code of an airport (if not editing the meta data)?
Jan Vogel July 9, 2021 7:45 PM
Something went wrong with that airport (and probably all the other ones that had new ICAO codes assigned in meta-data in 11.55.
Michael said that the apt.dat thing will be gone with the next version of X-Plane, so it is probably not worth really finding out what went wrong.
Philipp Ringler July 10, 2021 2:48 AM
Absolutely nothing went wrong here, all components are working exactly as they should.
If you look at Resources/default data/CIFP, you will notice that the file for this airport is the HSSS.dat, not the HSSK.dat, because that was the ICAO ID in cycle 1802.
Jan Vogel July 10, 2021 3:49 AM
Thanks for the clarification.
I wish we had a way to update our navdata cycle to something more current…so the user experience for changed ICAOs in conjunction with our default avionics would be better in this regard. Curious to see what XP12 will bring in this regard.