MSFS20 Fixing MSFS LDA information in APX data files

[JRBarrett]

Curiously, MSFS ILSs records in NAX files contain wrong runway aligned courses for offset ILSs but changing them to correct values does not change instrumental LOC course indication, the reason why it is supposed to be set by the sim independently of what is defined in the ILS LOC subrecord, unless the airport data are altered as mentioned above. This situation was not observed in any previous sim version.

Changing the ILS record in the NAX file to alter the course to the correct value, (or overriding the default NAX with the Navigraph replacement nav data) will alter the instrument indication insofar as it will cause the correct localizer course to be auto-selected on the analog or digital OBS. But it does nothing to alter where the localizer actually appears spatially in the simulated world. Removing the link in the APX is the only thing that will allow the localizer to take the course defined in the NAX file.

I’m not sure what Asobo’s intention was in designing the ILS emulation to work this way. I suspect they did not consider the fact that there are valid reasons why some real world localizers are offset. In the case of the ILS22R approach at KJFK it was done for convenience. Aligning that localizer with the runway centerline would have required constructing the antenna in a saltwater marsh. The LDAs at KDCA exist to keep aircraft out of restricted airspace. The offset approaches at LOWI are the most important in terms of flight safety, as they assure safe terrain clearance.

 

[jaxx_]

Could you please explain how you find the value for the ILS in the BGL file? I tried to look into your example at KDCA and I followed the instructions from https://www.fsdeveloper.com/wiki/index.php/BGL_File_Format#ICAO_Identifiers_and_region_codes to get the value to search for but I cannot find it in the APX27180.bgl with a Hex editor.
The ILS identifier is IASO, and I followed the instructions from the link above to encode it:

I (20) -> 20
*38 -> 760
+ A (12) -> 772
*38 -> 29336
+ S (30) -> 29366
*38 -> 1115908
+ O (26) -> 1115934
*38 -> 42405492
-> 0x2870E74

But 0x2870E74 is not in the APX27180.bgl. What is the correct way to find the value you have to zero-out?

 

[JRBarrett]

Could you please explain how you find the value for the ILS in the BGL file? I tried to look into your example at KDCA and I followed the instructions from https://www.fsdeveloper.com/wiki/index.php/BGL_File_Format#ICAO_Identifiers_and_region_codes to get the value to search for but I cannot find it in the APX27180.bgl with a Hex editor.
The ILS identifier is IASO, and I followed the instructions from the link above to encode it:

I (20) -> 20
*38 -> 760
+ A (12) -> 772
*38 -> 29336
+ S (30) -> 29366
*38 -> 1115908
+ O (26) -> 1115934
*38 -> 42405492
-> 0x2870E74

But 0x2870E74 is not in the APX27180.bgl. What is the correct way to find the value you have to zero-out?

That is indeed the correct algorithm, but you did one too many multiplications by 38. The last digit for “O” (26) is simply added to the running total without additional multiplication, so your final value is 1115934, which is 0x11071E. Since the link is 4 bytes total, you should pad it with 0x00 to give 0x0011071E. The final step is to reverse the byte order, since intel CPUs use “little endian” byte order, meaning 32 bit integers are stored on disk with the LSB first, and the MSB last. Thus, the value to search for is 0x1E071100. Once found, just change those 4bytes to all zeros and save the file.

I highly recommend making a backup copy of APX27180.bgl before making any edits. As a reminder, for this to work, it is necessary to also install Navigraph beta nav data, which will override the default NAX27180.bgl with their own version that will have the IASO localizer course set to the correct value of 149 degrees.

This 4 byte value in the APX runway record that links a specific ILS to a specific runway, has long been standard in APX bgl files since at least the days of FSX. Only MSFS (apparently) uses the presence of that link to force the localizer to the runway heading even with a corrected NAX file from Navigraph.

Though zeroing out the bytes (in conjunction with correct localizer course information from Navigraph) will definitely make offset localizers work correctly, it may have other side effects, such as preventing aircraft from auto-tuning the ILS if it is included in the MSFS flight plan - but you can always manually tune the Nav 1 receiver to the correct frequency, and the LDA will definitely work.

At one time, the LDA-Y at KDCA also had a glideslope, but that was removed in 2017, and both Navigraph and default NavBlue nav have this as a localizer-only approach.

 

[jaxx_]

Thank you, I got it working
Tested it with a few offset localizers and they behave fine in my eyes now (using the latest Navigraph data also).

If anyone is interested, I wrote a Python script (not sure which version is needed, at least Python 3x) that applies the fix to a specified ILS.
You have to call it with the path to the BGL and the ILS identifier, like: offset_ils.py "G:\MSFS\Microsoft Flight Simulator\Official\OneStore\fs-base\scenery\0302\APX27180.bgl" IASO

I've added some simple checks for validity and it also creates a backup, but use at your own risk.

EDIT: Removed script, enhanced version below at https://www.fsdeveloper.com/forum/t...ormation-in-apx-data-files.450267/post-867645

 

[mottoth]

In the meantime I tested the "soft" way, i.e. excluding stock ILS/LDAs with MSFS SDK and adding corrected ILS/LDAs with (slighty) different Identifiers (to make the links encoded in the APxxx.bgl file inop) but the same frequencies.
Tests were conducted at LOWI (Asobo version), and got mixed results: the MSFS built-in compiler apparently ignores the deleteAllILSs=true flag and both stock and add-on LDAs are now present in the sim, with the same frequencies. This doesn't lead to a CTD as I feared but it's all random which one is picked by your aircraft receiver when you tune on the frequency: some times I picked the default OEV beam which points dangerously to the mountains, and some times I picked my custom IOEV LDA beam with the correct course (66°).

 

[Geoff_D]

The KDCA LDA Z approach works correctly with only Navigraph present (no APX edit required), because as you know, there can be only one ILS linked to a specific runway, and in the case of KDCA the link is attached to the LDA Y approach. Since the LDA Z approach has no link to runway 19, it works correctly with just Navigraph installed. You could get the same result (without Navigraph) by editing the default NAX file to change the float value for LDA Z from the incorrect 186.5 to the correct 147.0.

Thank you ... I thought i was going Crazy .. one day I could fly the LDA 19, another day i could not .. Now i know why .. the LDA Z works, the LDA Y does not !!

So what it going to take for Asobo to both recognize this as an issue, and then fix it ?

If I use a Custom airport, say the one out there for KDCA, will the LDAs both working depend on what the Custom airport developer did to code the LDAs. ?

I find it particularly disappointing, that even after the USA Update, that featured KDCA as a "custom, manually enhanced airport" that the LDA issues were not discovered by ASOBO, and corrected at that time.

Yes ASOBO have many other (maybe more important) things to fix in MSFS, but most of those are functional code issues, this is Airport scenery, done by (I assume) a very different department of Asobo, so should not be an issue.

Rather than add new Incorrect airports, why not at least first get the existing ones right !!!

But now knowing that the LDA Z works, I am happy (. in any case, I thought that the LDA Y was no longer used in RW ?? )

 

[Geoff_D]

Thank you, I got it working
Tested it with a few offset localizers and they behave fine in my eyes now (using the latest Navigraph data also).

If anyone is interested, I wrote a Python script (not sure which version is needed, at least Python 3x) that applies the fix to a specified ILS.
You have to call it with the path to the BGL and the ILS identifier, like: offset_ils.py "G:\MSFS\Microsoft Flight Simulator\Official\OneStore\fs-base\scenery\0302\APX27180.bgl" IASO

I've added some simple checks for validity and it also creates a backup, but use at your own risk.

Thanks ... any chance this could be used to just process EVERY ILS/LDA in the Sim -- something that one could run easily and let it do it's thing, especially if needed when new airports are added.

ie all_offset_ils.py "G:\MSFS\Microsoft Flight Simulator\Official\OneStore\fs-base\scenery\*

(easy enough to backup all of "G:\MSFS\Microsoft Flight Simulator\Official\OneStore\fs-base\scenery\" before hand )

(unfortunately beyond my abilities to do -- I am going to struggle to figure out how to run Python on my w10 PC .. !!)

Did not expect to have to be so Tech savvy just to run a "Flying game"

 

[JRBarrett]

But now knowing that the LDA Z works, I am happy (. in any case, I thought that the LDA Y was no longer used in RW ?? )

The LDA Z is preferred, because it has lower minimums. The RNAV approach is probably much more common operationally than either of the LDAs. I’ve done the River Visual 19 in the C172, which is pretty easy. Someday I’ll have to try it in the A320!

 

[JRBarrett]

Thanks ... any chance this could be used to just process EVERY ILS/LDA in the Sim -- something that one could run easily and let it do it's thing, especially if needed when new airports are added.

ie all_offset_ils.py "G:\MSFS\Microsoft Flight Simulator\Official\OneStore\fs-base\scenery\*

(easy enough to backup all of "G:\MSFS\Microsoft Flight Simulator\Official\OneStore\fs-base\scenery\" before hand )

(unfortunately beyond my abilities to do -- I am going to struggle to figure out how to run Python on my w10 PC .. !!)

Did not expect to have to be so Tech savvy just to run a "Flying game"

All that really needs to happen if for Asobo to remove whatever function they have built into the sim that forces the localizer to the runway heading if the ILS/Runway link exists. (And update the default NavBlue nav data so it will contain the actual published localizer headings for those who do not use Navigraph). Though disabling the link does work, hacking default scenery files is not a very elegant solution and the link does have other legitimate uses. I’m convinced this behavior is coded into the default Nav receiver that all MSFS aircraft use.

 

[Geoff_D]

All that really needs to happen if for Asobo to remove whatever function they have built into the sim that forces the localizer to the runway heading if the ILS/Runway link exists. (And update the default NavBlue nav data so it will contain the actual published localizer headings for those who do not use Navigraph). Though disabling the link does work, hacking default scenery files is not a very elegant solution and the link does have other legitimate uses. I’m convinced this behavior is coded into the default Nav receiver that all MSFS aircraft use.

That's so right, but trying to get Asobo to even recognize & understand this as an issue, when there so much Eye Candy and X-Box stuff that "needs" to be addressed, will take some considerable lobbying, or a word from the right person into the right ear. -- although when it was brought up at the last Q&A, Asobo, looking surprised, said they would "research" it ...

 

[jaxx_]

I'm looking into going via parsing the BGL structure instead of just searching for the ident occurrence to be more reliable and being able to just change via ident without having to know the specific file.
If that works it should be no problem to just wipe the entry for every ILS. But I don't think it's a good solution for everyone for a couple of reasons.
1. You should generally not modify files outside the Community folder.
2. The entries might be used for unknown reasons and the removal might cause glitches.
3. In several cases it can make it worse, as I think the Navigraph data is not 100% accurate. It looks to me as if their magvar and/or ILS headings are only provided with an accuracy of 1°, so non-offset localizers that are dead-center now might be at an slightly off angle when "fixed".
4. Any custom airports, including internal premium or world update and Community folder would probably override the change again, so to really catch everything its not enough just to go through the base scenery. And no chance changing encrypted fsarchive addons.

 

[jaxx_]

I updated my script and it should now be more reliable and provide more features.
You have to change the path in the beginning of the script to your MSFS root path and then it can be used.
The script parses the structures of the BGLs to find an ILS and is surprisingly fast with that (it only takes a few seconds to apply the fix to all files).

I added an option to apply it to all airports and runways:

ils_fix.py --all

Though I do not recommend that as it will make things worse for localizers that should be centered but are slightly off due to the Navigraph data having not the highest precision.

There is also an option to read airport/ils entries from a CSV file, so you can reapply it quickly after an update:

ils_fix.py --csv example.csv

LOWI;OEJ
LOWI;OEV
KDCA;IASO
KDCA;IVWH
EDHK;IKHE
BIAR;IAR
BIAR;IAL
BIAR;IEY

In the included example I added idents that are not affected to show it does not harm to add them (like KDCA;IVWH).

It's also possible to fix a single ident:

ils_fix.py --airport KDCA --ident IASO

If you omit the --ident part it will apply to all entries for that airport.

There is also the option -n that will output the progress as usual, but will not execute any changes, so you can see what the command will do before performing any changes:

ils_fix.py -n --csv example.csv

All affected files will be backuped to a backup folder in the MSFS root that has the same directory structure as the original, so to revert the changes you only have to move or copy the content of the backup folder to the MSFS root.
I suggest to restore the files and delete the backup folder before you update MSFS to a new version.

 

[JRBarrett]

I updated my script and it should now be more reliable and provide more features.
You have to change the path in the beginning of the script to your MSFS root path and then it can be used.
The script parses the structures of the BGLs to find an ILS and is surprisingly fast with that (it only takes a few seconds to apply the fix to all files).

I added an option to apply it to all airports and runways:

ils_fix.py --all

Though I do not recommend that as it will make things worse for localizers that should be centered but are slightly off due to the Navigraph data having not the highest precision.

There is also an option to read airport/ils entries from a CSV file, so you can reapply it quickly after an update:

ils_fix.py --csv example.csv

LOWI;OEJ
LOWI;OEV
KDCA;IASO
KDCA;IVWH
EDHK;IKHE
BIAR;IAR
BIAR;IAL
BIAR;IEY

In the included example I added idents that are not affected to show it does not harm to add them (like KDCA;IVWH).

It's also possible to fix a single ident:

ils_fix.py --airport KDCA --ident IASO

If you omit the --ident part it will apply to all entries for that airport.

There is also the option -n that will output the progress as usual, but will not execute any changes, so you can see what the command will do before performing any changes:

ils_fix.py -n --csv example.csv

All affected files will be backuped to a backup folder in the MSFS root that has the same directory structure as the original, so to revert the changes you only have to move or copy the content of the backup folder to the MSFS root.
I suggest to restore the files and delete the backup folder before you update MSFS to a new version.

Nice job!

 

[Szpike]

Updating files in place is absolutely dangerous, really really don't do that. Also whenever there's an update your changes will be wiped out with alacrity by MSFS.

The script will also only work with MS Store downloaded versions of MSFS right now. I'm actually surprised that just blanking the ICAO is enough to make the ILS go away without causing a crash; this behaviour is probably not defined and is risky for the future.

MSFS built-in compiler apparently ignores the deleteAllILSs=true

@mottoth This is surprising. Can you give an example of how you used it?

 

[mottoth]

This is surprising. Can you give an example of how you used it?

With this code:

    <Airport region="" country="" name="LOWI" ident="LOWI" lat="47.26010989230301" lon="11.34347713399294" alt="582.10892196651548" magvar="357.000000" trafficScalar="1.000000" airportTestRadius="11000.00000000000000" applyFlatten="FALSE" isOnTIN="FALSE">
        <TaxiName index="0" name=""/>
        <Aprons/>
        <PaintedElements/>
        <ApronEdgeLights/>
        <Ils lat="47.258592" lon="11.340612" alt="582M" heading="255" frequency="111.1" magvar="-3" ident="IOEV" width="5.0" name="LOCDMEEAST">
            <GlideSlope lat="47.260082" lon="11.353576" alt="579M" pitch="3.77" range="27N"/>
            <Dme lat="47.260082" lon="11.353576" alt="582M" range="27N"/>
        </Ils>
        <Ils lat="47.314864" lon="11.602320" alt="600M" heading="66" frequency="109.7" magvar="-3" ident="IOEJ" width="5.0" name="LOCDMEWEST">
            <Dme lat="47.314864" lon="11.602320" alt="838M" range="27N"/>
        </Ils>
        <DeleteAirport deleteAllApproaches="FALSE" deleteAllApronLights="FALSE" deleteAllAprons="FALSE" deleteAllFrequencies="FALSE" deleteAllHelipads="FALSE" deleteAllRunways="FALSE" deleteAllStarts="FALSE" deleteAllTaxiways="FALSE" deleteAllBlastFences="FALSE" deleteAllBoundaryFences="FALSE" deleteAllJetways="FALSE" deleteAllControlTowers="FALSE" deleteAllDepartures="FALSE" deleteAllArrivals="FALSE" deleteAllPaintedElements="FALSE" deleteAllLightSupports="FALSE" deleteAllTaxiwaySigns="FALSE" deleteAllILSs="TRUE" deleteAllTerminalWaypoints="FALSE" deleteAllTerminalNDBs="FALSE"/>
    </Airport>

I end up with duplicated LDAs (the default ones OEV & OEJ and the corrected ones IOEV / IOEJ).

 

[Szpike]

I wonder if it might be related to the fact that OEV & OEJ are presumably referred to within the <Approach> records which state the LDA?

 

[jaxx_]

Updating files in place is absolutely dangerous, really really don't do that. Also whenever there's an update your changes will be wiped out with alacrity by MSFS.

I don't see any viable and working alternative right now. Even with complete addon-airports the base data seems to still interfere with this. Also I would not call it dangerous, you can always restore the backup or just delete the fs-base folder and it will be downloaded again.
The root cause is for Asobo to fix and until then we only have limited options to fix it.
And it's not like updates are that frequent, so re-applying isn't that much of a problem.

The script will also only work with MS Store downloaded versions of MSFS right now. I'm actually surprised that just blanking the ICAO is enough to make the ILS go away without causing a crash; this behaviour is probably not defined and is risky for the future.

The ILS is not going away, ILSs have their own records that remain untouched. It only removes the ILS ident from the runway record. And while this may be used for some convenience functions (like auto-dial ILS frequency for a runway) it is not surprising that it is not interfering with the general functionality of the ILS. Otherwise situations like KDCA where there are more than one ILS per runway would be impossible in the sim, as each runway has only the option to store one ILS ident per runway direction.

 

[JRBarrett]

The ILS is not going away, ILSs have their own records that remain untouched. It only removes the ILS ident from the runway record. And while this may be used for some convenience functions (like auto-dial ILS frequency for a runway) it is not surprising that it is not interfering with the general functionality of the ILS. Otherwise situations like KDCA where there are more than one ILS per runway would be impossible in the sim, as each runway has only the option to store one ILS ident per runway direction.

For the great majority of ILS localizers that truly are aligned with the runway heading, this is not a problem. But for those localizers that are offset in the real world, it causes the aircraft to fly an incorrect flight path. In the case of the LDA-Y at KDCA it brings the aircraft directly through the prohibited airspace that the LDA was designed to avoid. If flying offline, no big deal I suppose - you won’t get shot down by an F16, which might very well happen to an aircraft that did that for real. At the very least, the pilot would probably face the loss of his license, and possible jail time. If flying this approach on Vatsim, it would certainly draw a rebuke from the controller, although by now, it is probably known on the network that the LDA approaches do not work correctly in MSFS.

At LOWI, flying the localizer without the offset will cause the aircraft to hit terrain if doing the approach in simulated IFR conditions without visual references.

The “undefined behavior” has been introduced by Asobo, because in all previous MS sims, the presence of the ILS link in the runway record does not force the localizer to take the exact runway heading, even when the ILS record itself has the correct heading (as is the case with Navigraph replacement nav data).

In FSX and P3D, the localizer section that defines the ILS parameters (identifier, frequency, localizer heading and beam width), was contained in the APXxxxxx.bgl scenery file for the airport. In MSFS, that section has been moved to the new NAXxxxxx.bgl file, (where the xxxxx has the same number sequence as the APX). One difference I have noted is that in FSX/P3D the localizer heading was defined in degrees true. In MSFS, it is defined in degrees magnetic.

If, as I suspect, the “locking the localizer to runway heading when the APX link exists” behavior is coded into the simulated Nav receiver, then this problem is also going to affect add-on aircraft like the upcoming Aerosoft CRJ if it uses the default Nav receiver emulation provided by Asobo.

Even though complex add-ons in FSX/P3D like PMDG, FSL, Leonardo and Majestic often have their own custom FMS and autopilot emulations that use no part of the simulators default code, I believe that they all link to the simulator’s own Nav receiver for VOR and ILS.

 

[jaxx_]

For the last days I've tested with all ILSs patched and haven't encountered any bad side effects.
The only thing is that the navigraph data is not really precise enough as they seem to set the localizer heading and magvar only to a precision of 1° and from my tests it would probably have to be at least 0.1° to be reliable.
I've posted this in their forums, hopefully they have more precise raw data. Otherwise if Asobo patches this issue the Navigraph data would not accurate enough for many ILSs.

 

[JRBarrett]

For the last days I've tested with all ILSs patched and haven't encountered any bad side effects.
The only thing is that the navigraph data is not really precise enough as they seem to set the localizer heading and magvar only to a precision of 1° and from my tests it would probably have to be at least 0.1° to be reliable.
I've posted this in their forums, hopefully they have more precise raw data. Otherwise if Asobo patches this issue the Navigraph data would not accurate enough for many ILSs.

Yes, I saw your post at Navigraph. I’m pretty sure the Jeppesen source data has the localizer headings to a precision of 0.1 degree, so it should be an easy fix to implement. The data field for localizer heading in the BGL is already a float, but as you noted, all localizers are set to xxx.0 in the current Navigraph data files.