• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

Official Airport to SDK project: here is a small app to help you (draft)

<TaxiwaySign lat="-45.0182923302054" lon="168.741922080517" heading="71.499" label="r23-05l[C]" justification="RIGHT" size="5" />

This should read>

<TaxiwaySign lat="-45.0182923302054" lon="168.741922080517" heading="71.499" label="r23-05l[C]" justification="RIGHT" size="SIZE5" />
I did a quick test and the size attribute is correct (SIZE5). What stock airport are you using ?
 
Hi Patrick,

have a look at the MSFS 2020 format Wiki page, I've added a couple of things I found which should be useful to both this utility and to your very nice Bglviewer too ( and ADE, I guess ), it's TaxywayPath with a variable number of custom materials, the byte previously unknown at 2C offset in the TaxiwayPath record is the number of materials used and then, after the normal record ends, for each material there's a new sub record 0x00D5, which is the material definition.

If you need an example of a scenery that use this feature, it's the default ESSA ( Stockholm ) from World Update 5, found here:

microsoft-airport-essa-arlanda\scenery\microsoft\Arlanda-Airport\objects.bgl

Currently, none of the available utilities are able to parse it without crashing, Bglviewer was at least able to open it but it couldn't find any airport inside but with this info, you should be able to fix that.
 
Last edited:
This looks like it could be perfect for adding finishing touches and correcting errors with stock airports. Unfortunately, the one I am trying to work on causes a CTD whenever I try to add a painted line. Anyone wanna see if they can figure out why?

I open the project XML in the Scenery Editor, select Painted Lines, then click on Edge_Line_Dashed and One-Click Placing. Then the sim crashes to desktop. Am I missing something here? Thanks!
 

Attachments

  • Project_KBLF.zip
    29.1 KB · Views: 162
Glad it helped!
The Comm option is not available...yet. Now if you give me the name (and path) of one airport that could be used as a test airport, I'll be glad to implement the Comms


So, if I'm not mistaken, in this latest version (1.0.0.17) the communication frequencies are not detected. With BGLViewer 2.0.0.13, on the other hand, the communication frequencies are detected correctly.
I ask @Patrick Germain if it was possible to integrate this possibility into Airport2Project?

The communication frequencies are found in the NAXxxxxx.bgl file as in this location of my version of MSFS_STORE:
H: \ MSFS_2020 \ Official \ OneStore \ fs-base-nav \ scenery \ 0702 \ NAXxxxxx.bgl

(The fs-base-nav file, can also be found from C: \ Users \ User \ AppData \ Local \ Packages \ Microsoft.FlightSimulator_8wekyb3d8bbwe \ LocalCache \ Content.xml)
 
So, if I'm not mistaken, in this latest version (1.0.0.17) the communication frequencies are not detected. With BGLViewer 2.0.0.13, on the other hand, the communication frequencies are detected correctly.
I ask @Patrick Germain if it was possible to integrate this possibility into Airport2Project?

The communication frequencies are found in the NAXxxxxx.bgl file as in this location of my version of MSFS_STORE:
H: \ MSFS_2020 \ Official \ OneStore \ fs-base-nav \ scenery \ 0702 \ NAXxxxxx.bgl

(The fs-base-nav file, can also be found from C: \ Users \ User \ AppData \ Local \ Packages \ Microsoft.FlightSimulator_8wekyb3d8bbwe \ LocalCache \ Content.xml)
I believe they are decompiled for the airport. From A2P:
XML:
<?xml version="1.0"?>
<FSData version="9.0">
    <Airport region="" country="" name="KORD" ident="KORD" lat="41.9766277447343" lon="-87.907252907753" alt="201.282" magvar="0.000" trafficScalar="1.000000" airportTestRadius="10000.00000000000000" applyFlatten="FALSE" isOnTIN="FALSE">
        <Com frequency="119.000" type="APPROACH" name="CHICAGO" />
        <Com frequency="124.350" type="APPROACH" name="CHICAGO" />
        <Com frequency="125.700" type="APPROACH" name="CHICAGO" />
        <Com frequency="133.625" type="APPROACH" name="CHICAGO" />
        <Com frequency="135.400" type="ATIS" name="KORD" />
        <Com frequency="119.250" type="CLEARANCE" name="O HARE" />
        <Com frequency="121.600" type="CLEARANCE" name="O HARE" />
        <Com frequency="119.250" type="CLEARANCE_PRE_TAXI" name="O HARE" />
        <Com frequency="121.600" type="CLEARANCE_PRE_TAXI" name="CHICAGO O'HARE INTL" />
        <Com frequency="125.000" type="DEPARTURE" name="CHICAGO" />
        <Com frequency="126.625" type="DEPARTURE" name="CHICAGO" />
        <Com frequency="118.050" type="GROUND" name="O HARE SOUTH" />
        <Com frequency="121.750" type="GROUND" name="O HARE" />
        <Com frequency="121.900" type="GROUND" name="O HARE" />
        <Com frequency="124.125" type="GROUND" name="O HARE NORTH" />
        <Com frequency="134.150" type="GROUND" name="O HARE" />
        <Com frequency="121.675" type="GROUND" name="O HARE METERING" />
        <Com frequency="120.750" type="TOWER" name="O HARE" />
        <Com frequency="121.150" type="TOWER" name="O HARE" />
        <Com frequency="126.900" type="TOWER" name="O HARE" />
        <Com frequency="127.925" type="TOWER" name="O HARE" />
        <Com frequency="128.150" type="TOWER" name="O HARE NORTH" />
        <Com frequency="132.700" type="TOWER" name="O HARE" />
        <Com frequency="133.000" type="TOWER" name="O HARE SOUTH" />
        <Com frequency="122.950" type="UNICOM" name="CHICAGO O'HARE INTL" />
 
Yep as I recall comms are decompiled.

this is from ADE which uses the same decompiler

1643206338650.png
 
I ran Airport2Project against the OJAM airport.
This is the beginning of the XML file it generated :
<?xml version="1.0"?>
<FSData version="9.0">
<Airport region="" country="" name="OJAM" ident="OJAM" lat="31.9727029278874" lon="35.9915721416473" alt="763.981" magvar="-3.400" trafficScalar="1.000000" airportTestRadius="10000.00000000000000" applyFlatten="FALSE" isOnTIN="FALSE">
<Com frequency="121.700" type="GROUND" name="AMMAN" />
<Com frequency="118.100" type="TOWER" name="AMMAN" />
<Com frequency="121.600" type="TOWER" name="AMMAN" />
<Ils lon="35.9726223349571" lat="31.9648360088468" alt="744.321" frequency="109.500" magvar="-4.000" range="50017.000" backCourse="TRUE" heading="240.049" width="3.4" ident="IAMN" name="ILS RW24">
<GlideSlope lon="36.0048834979534" lat="31.977036036551" alt="744.321" range="50017.000" pitch="3.000" />
<Dme lon="36.0048834979534" lat="31.977036036551" alt="764.133" range="50017.000" />
</Ils>

So COMs are here
 
Thanks everyone for your help.

If with A2P I open the APXxxxxx.bgl file directly in the folder H: \ MSFS_2020 \ Official \ OneStore \ fs-base \ scenery \ 0702 ... then \ COM is decompiled.
While if I take a copy of APX xxxxx.bgl and put it in another location outside of H: \ MSFS_2020 \ Official \ OneStore \ fs-base \ scenery \ 0702 then there is no \ COM ... and \ILS
Is all this possible?
 
Last edited:
Navaids and comms are not in the APX stock bgl file. If you decompile it directly then you will not see them in the source. The app works by looking for the ICAO in both the APX and relevant NVX file(s)
 
There are lots of Spanish airports that are mislabeled in MSFS. MSFS uses the ICAO as the airport identifier, but it only allows 5 alpha-numeric characters for the ID ("-" is not allowed"), so on 2 counts, they do not use ES-0218. At least this was the case a few updates ago.
What they have done, is simply made up an unused ICAO for the airport. You cannot use ES-0218 as that is not allowed in the sim's compiler. You could use E0218 or S0218.

The aerial imagery of ES-0218 clearly shows 2 runways, so Asobo's computer-generated AI placed 2 runways.

Attached is an example of closing LEBM, and opening E2018.
@rhumbaflappy : Hi Dick, could this example show as well a way to "kill" closed airports in MSFS, like EDDT that is full alive in the sim?

Up to now I didn't find any hint how to explain, why Tempelhof (EDDI) obviously has a secret existence (not shown on the map and not selectable), nonetheless detectable by all tools like ADE, MakeRunways, and @Patrick Germain's BglViewer. In this case this could at least help to hide other airports as well - hopefully.
 
What is the current state of EDDI and EDDT in the real world? From what I understand EDDI closed in 2008. And EDDT closed in 2020 (excepting a heliport on the northern side until 2029). So EDDT could exist in the sim, but runways should be closed and a heliport used.
I find 2 helipads:
Untitled.png


I'll look at the code Asobo has used and see what can be done.
 
Using msfsbglxml.exe on APX51139, I see this (and Patrick should look into this):

XML:
  <Airport country="TT:AIRPORTEK.EDDI.country" city="TT:AIRPORTEK.EDDI.city" name="TT:AIRPORTEK.EDDI.name" lat="52.47301954776049" lon="13.403668105602264" alt="167.0F" magvar="358" ident="EDDI" trafficScalar="0.69803923" isOnTIN="TRUE" onlyAddIfReplace="FALSE" applyFlatten="FALSE" starAirport="FALSE" closed="TRUE">

closed="TRUE"
So this is how Asobo closed that airport. They didn't close EDDT, but seemed to have simplified it a lot. It needs everything closed or deleted and the heliport pads added, I think. But the airport itself would stay open for the helicopters.

It's good to have 2 people working on decompilation, as one might find something the other doesn't find or add:

Untitled.png
 
Last edited:
Using msfsbglxml.exe on APX51139, I see this (and Patrick should look into this):

XML:
  <Airport country="TT:AIRPORTEK.EDDI.country" city="TT:AIRPORTEK.EDDI.city" name="TT:AIRPORTEK.EDDI.name" lat="52.47301954776049" lon="13.403668105602264" alt="167.0F" magvar="358" ident="EDDI" trafficScalar="0.69803923" isOnTIN="TRUE" onlyAddIfReplace="FALSE" applyFlatten="FALSE" starAirport="FALSE" closed="TRUE">

closed="TRUE"
So this is how Asobo closed that airport. They didn't close EDDT, but seemed to have simplified it a lot. It needs everything closed or deleted and the heliport pads added, I think. But the airport itself would stay open for the helicopters.

It's good to have 2 people working on decompilation, as one might find something the other doesn't find or add:

View attachment 80667
Thanks a lot Dick, after a snack I detected this flag as well. I've just tried it for Tegel and it worked. First I likely misunderstood the flags used in ADE that did not seem to work and got the right track after looking closer into Patrick's Wiki, comparing the described data with ADE's Raw Data View.

EDDT is decommissioned and no longer an airfield. Probably the Federal or local Police might use the heliport still for some reasons, but I doubt it. Those guys would use any free spot within the city area if necessary. The area itself will contain (hopefully soon) a couple of hundred apartments and a research and industry park (the old airport buildings mostly).
 
Back
Top