MSFS20 Fixing MSFS LDA information in APX data files

[Geoff_D]

From what I have read :

for each runway in a given airport’s APX data file (the BGL that defines the airport layout), there is a hexadecimal 4-byte number that forces any ILS linked to a specific runway to set its localizer to the exact runway heading no matter WHAT the nav data says the actual localizer heading should be.


The four bytes can be removed with a hex editor, and an offset localizer will then work correctly

Is there a Tool yet, capable of doing this for MSFS ( Internal or External) ??

(A total of 39 airports (worldwide) have an LDA, for which this is an issue )

 

[Geoff_D]

Can anyone thow any light on this issue ? Please ...

 

[scruffyduck]

Where did this information come from? I am not aware of it

Do you mean finding the four bytes or changing them - also it is very bad practice to edit APX files and if they get updated during and update then your changes will be lost.

 

[mottoth]

for each runway in a given airport’s APX data file (the BGL that defines the airport layout), there is a hexadecimal 4-byte number that forces any ILS linked to a specific runway to set its localizer to the exact runway heading no matter WHAT the nav data says the actual localizer heading should be.

The thing is that I don't see how ILS are linked to runways in the xml definition: the ILS code is outside of the runway element, and nothing in the ILS code links it to a runway:

<Ils lat="30.237948" lon="120.453419" alt="6.7M" heading="66.9" frequency="109.9" magvar="4" ident="IXX" width="5.0" name="ILS07">
            <GlideSlope lat="30.222439" lon="120.421189" alt="6.7M" pitch="3" range="27.01N"/>
            <Dme lat="30.222439" lon="120.421189" alt="6.7M" range="27N"/>
</Ils>

Here I named that ILS "ILS07" for runway 07 but I could have named it something completely different with no reference to runway 07, and besides of this nothing could explicitely relate that ILS to runway 07.
Btw I already involuntarily made offset localizers when messing up with the magvar attribute so it's possible and working as intended (basically I had a sign error on the magvar and realised during a test flight that my LOC had an offset that equaled twice the magvar).

Scruffyduck already said it, it's bad practice to amend APX files, and it's quick and easy to start a small project to exclude stock ILS/LDA and design a proper, functionnal one.

 

[hervesors]

ILS XML element is defined inside airport runway element so there is a direct link between any defined ILS and its airport runway assignment
At compilation time, even if ILS data are stored in a different section than airport runway data, localizer subrecord contains information on associated runway and each airport runway subrecord contains ICAO idents for primary and secondary ILS if any. So, yes there is definitely a link between ILSs and airport runways..hopefully

The information regarding the incorrect alignment of all offset ILSs and LDA in MSFS comes from both navigraph and MSFS forums

Offset localizer

Hello everyone. I have installed the Beta package, however I am experiencing few offset localizers and/or final course track not being aligned with charts. Is Navigraph navdata beta supposed to update these as well? thanks,

forum.navigraph.com

Offset (ILS / LDA) Approach Issues

Problem There are two big problems concerning ILS / LDA approaches, in short: Currently all approaches which are offset in real life are aligned with the runway course in MSFS, see my Innsbruck (LOWI) example below. Bearing pointer or RMI give bearings towards the localizer antenna, this is...

forums.flightsimulator.com

 

[mottoth]

ILS XML element is defined inside airport runway element so there is a direct link between any defined ILS and its airport runway assignment
At compilation time, even if ILS data are stored in a different section than airport runway data, localizer subrecord contains information on associated runway and each airport runway subrecord contains ICAO idents for primary and secondary ILS if any. So, yes there is definitely a link between ILSs and airport runways..hopefully

The ILS code doesn't have to be nested in the runway element, as shown in the SDK simplenav samples. So I still think excluding stock items and adding a new LOC should fix this issue. I'll try something for LOWI this afternoon. As I said before I already accidentally made offset ILS entering a wrong magvar, so eventually that trick may also be reproduced.

 

[hervesors]

The ILS code doesn't have to be nested in the runway element, as shown in the SDK simplenav samples. So I still think excluding stock items and adding a new LOC should fix this issue. I'll try something for LOWI this afternoon. As I said before I already accidentally made offset ILS entering a wrong magvar, so eventually that trick may also be reproduced.

Interesting..I didn't know ILS code could be defined outside runway element and didn't succeed compiling without errors <Ils></Ils> data outside of it
If it is the case, I really don't know how the compiler could properly define some parts of the ILS and runway records. However the tests I performed were for FSX up to P3Dv5. Did MSFS behaves differently?..
Could you provide us a text example of such a XML file that compiles seamlessly?

ILS magvar will not offset ILS course on simulator side, just ILS visual map course.
On instrumental side ILS offset is just defined by the difference between LOC TRUE course and runway TRUE course as set in their respective sections (that are for XML files ILS heading and runway heading)
Whatever the ILS magvar is, if both courses (headings) are equal and loc is positionned on runway axe, it will be aligned
For a more comprehensive and complete review of such aspects, I wrote a summary document some time ago

https://www.aero.sors.fr/documentation/UnderstandingMV.pdf

 

[mottoth]

I provided working MSFS ILS xml code yesterday, a few posts above. It's part of the Airport Element, not the Runway.
Here it is again:

<Ils lat="30.237948" lon="120.453419" alt="6.7M" heading="66.9" frequency="109.9" magvar="4" ident="IXX" width="5.0" name="ILS07">
     <GlideSlope lat="30.222439" lon="120.421189" alt="6.7M" pitch="3" range="27.01N"/>
      <Dme lat="30.222439" lon="120.421189" alt="6.7M" range="27N"/>
</Ils>

Also, in MSFS, the ILS course entered in the xml code is a magnetic course. On the example above, coding Hangzhou (ZSHC) ILS runway 07, the magnetic course is 66.9°, the true heading is 62.9°. True HDG + magvar = Magnetic HDG.
So if I entered heading=66.9° and magvar=0 then my ILS beam would have a 4° offset to the left of runway 07.
I already did this unintentionally and upon testing and testing with the classic C172 tuned on my faulty ILS the offset became evident: I actually had to fly that offset to center the ILS needle.

I'm back home right now and will get my hands right now on LOWI to see what I can do.

 

[hervesors]

Ok, so it appears MSFS XML ILS coding is somehow different from previous sim versions. Thanks for the insight. Now, it will be worth analyzing how it is internally coded at BGL level, especially as regards course (mag or recalculated true) and this "forced alignment" integer that has been mentioned

 

[mottoth]

I must admit that I spent the afternoon trying to fix LOWI localizers, with no success.
At a first glance I was on a good track: started a LOWI project, Deleted only ILS, saved, edited the xml to add both localizers. Compiled, restarted: my modified LOCs would appear on the world map (I could tell by the altitudes being different than stock ones), but in game the beams were still strictly parallel to the runway (i.e. 078° / 258° mag).
Then I tried to Delete also the runway (since it's somehow associated with the ILS in the APX files), and add myself a runway: my LOCs wouldn't appear anymore on the map, instead the stock ones are displayed.
Then rolled back and never could get the semi-success I had at my first compilation and get back my stuff on the map. Very strange, the very same stuff wouldn't behave the same despite many compilation attempts.

I'm considering to fill a zendest report, because this should work and we should not be 'encouraged' to amend stock APX files the day we we finally crack them, this is definitely not good practice. The Delete / override method with the SDK should prevail.

My previous experience with MSFS airport modding so far was only with missing airports, adding something completely new to the sim not intefering with what's in APX files. This is where I figured that offset Localizers were doable, I'm disapointed it's not that straightforward with existing airports.

BTW here is my code that half-worked once and then failed miserably:

<?xml version="1.0"?>
<FSData version="9.0">
    <Airport region="Europe" country="Austria" city="Innsbruck" name="Innsbruck" ident="LOWI" lat="47.26010989230301" lon="11.34347713399294" alt="582.10892196651548" magvar="357.000000" trafficScalar="1.000000" airportTestRadius="2000.00000000000000" applyFlatten="FALSE" isOnTIN="FALSE">
        <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"/>
        <TaxiName index="0" name=""/>
        <Aprons/>
        <PaintedElements/>
        <ApronEdgeLights/>
        <Ils lat="47.258592" lon="11.340612" alt="582M" heading="255" frequency="111.1" magvar="-3" ident="OEV" 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="579M" range="27N"/>
        </Ils>
        <Ils lat="47.314864" lon="11.602320" alt="838M" heading="66" frequency="109.7" magvar="-3" ident="OEJ" width="5.0" name="LOCDMEWEST">
            <Dme lat="47.314864" lon="11.602320" alt="838M" range="27N"/>
        </Ils>
    </Airport>
</FSData>

I may try something else tomorrow, but I had enough of this today

 

[JRBarrett]

Where did this information come from? I am not aware of it

Do you mean finding the four bytes or changing them - also it is very bad practice to edit APX files and if they get updated during and update then your changes will be lost.

I am the source of that information,

Currently In MSFS, every localizer at every airport, is set to the exact runway heading. This is not a problem for the great majority of localizers that actually are aligned to the runway centerline, but causes major problems if the real world localizer is offset for operational or safety reasons. The lat/lon coordinates for the antenna arrays are correctly defined in the airport scenery. For example: the localizer antenna for runway 22R at KJFK is physically located to the left of the runway, just south of the intersection of runway 13R/31L. The localizer was placed here, because the normal location for a localizer antenna for 22R, immediately beyond the threshold of the opposite end (04L), would have required building the antenna on protected wetlands in Jamaica Bay.

In the sim, if you land on 22R at KJFK and taxi past the runway 13R/31L intersection, you will see the localizer array on the left side of the runway, exactly where it is located at the real airport.

As a result, the ILS22R localizer is offset by 2.5 degrees. Its course is 221 degrees (magnetic), while the runway centerline is 223.6 degrees magnetic.

In r/w operations, an aircraft flying this approach, tracking the localizer, will approach the runway at a 2.5 degree angle from the right side of the runway. The offset localizer will cross the runway centerline at a location in space where the glide slope MDA is located. Obviously, if the weather conditions are above ILS minimums, an arriving pilot can adjust his heading at any time prior to MDA to align with the centerline visually.

However, in MSFS this does not happen. Unlike other sims, in MSFS the Nav radio automatically sets the CDI course to the localizer course contained in the nav data file as soon as the ILS is within range and being received. (At least this is the case with all default aircraft). You cannot manually adjust the course once the ILS is being received. Of course in the case of a localizer, the path the aircraft follows is based only on its spatial position in relation to the localizer beam. As long as the CDI is kept centered, the aircraft will track the localizer correctly no matter how the OBS or digital course it set.

In the case of KJFK ILS22R in MSFS, the course auto-displayed on the PFD will be 223 degrees (the same as the runway). Indeed, the localizer is set to 223 degrees, because if you track it inbound with a centered CDI, the aircraft will align parallel to the left side on the runway, and if left to its own devices, would land on the grass. This is due to the fact that the localizer antenna is correctly placed, but the localizer course is wrong.

I know that often, when an ILS takes you “into the grass”, it’s because the localizer antenna is placed incorrectly in the scenery, but in this case, it is in exactly the right place.

The same situation exists with all approaches with offset localizers.

The most egregious example of how bad this can be is with the two LDA approaches to runway 19 at KDCA, which are offset almost 40 degrees from the runway centerline. The runway heading is 186.3 degrees. The LDA Y 19 approach I-ASO (109.9) localizer is set to 149 degrees. The LDA Z 19 approach I-VWH (108.5) is set to 147 degrees. In both cases, the offsets exist to keep arriving aircraft west of the Potomac, and out of the prohibited airspace over the Capitol, White House and Pentagon.

In default MSFS, both of these LDA approaches have localizers set to the exact runway centerline, 186 degrees, and flying either one will bring the aircraft directly through the very prohibited airspace that is supposed to be avoided.

In the case of KDCA, the localizers are defined in the file: Official/OneStore/fs-base-nav/scenery/0302/NAX27180.bgl. This is the default Nav Blue data. BGL View can read this file, and it does indeed show (under QMID 9,109,72) that both localizers are set to the runway heading of 186.5 degrees instead of the correct 149 and 147 degrees.

Either NavBlue has been instructed to set all localizers to exact runway heading, or Asobo does it themselves when post-processing the NavBlue source data as part of the process of converting it to NAXxxxxx.bgl format.

Now, the new Navigraph beta nav data partially corrects this problem. The Navigraph data in the Community folder overrides the NavBlue default NAX file. With Navigraph installed, if I tune the LDA Y 19 approach on 109.9, the PFD course is automatically set to the correct 149 degrees. Tuning the LDA Z approach on 108.5 will set the course to the correct 147 degrees.

BUT, in the case of the LDA Y, the localizer itself is still stubbornly set to186 degrees, and tracking it in flight with a centered CDI will still bring the aircraft directly through the prohibited airspace, directly aligned with the runway centerline. Interestingly, with Navigraph installed, the LDA Z approach works correctly.

Here’s why: The “thing” causing a localizer to take the exact runway heading is the 4 byte runway-ILS link contained in the 0xCE runway record in the airport APX file. (Thank you to Hervé Sors for the insight as to what those bytes are).
In the case of KDCA, this file is: Official/OneStore/fs-base/scenery/0302/APX27180.bgl

As you undoubtedly know, this link consists of the ILS identifier numerically encoded as a 4 byte integer.

In the case of the KDCA LDA Y approach (I-ASO) if I “break the link” by editing the APX file with a hex editor to change each of the four bytes to 0x00, the forced localizer-to-runway-heading “bug” goes away, the LDA Y localizer in-game assumes the correct course of 149 degrees, and tracking it in flight brings the aircraft over the correct ground path west of the Potomac.

I have verified that any offset localizer in the sim can be made to work correctly, by overriding the default nav data with Navigraph, and zeroing out the ILS-runway link in the associated APX file. In the case of a custom airport like KJFK, it also requires editing the custom APX file the same way.

Though this “works”, it is obviously not a recommended procedure, as one should not be directly edit default APX bgl files.

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.

Conclusions:

In default MSFS, every runway localizer is set to the exact runway heading in the associated NAX file. It is either being supplied that way by NavBlue, or post-edited by Asobo.

Even with a correct localizer definition supplied by Navigraph beta nav data, it makes no difference, because if an ILS-runway link exists in the airport APX file, the presence of that link forces the localizer to the runway heading no matter what the nav data file value is. If the link is disabled by changing the four bytes to 0x00, then the localizer will take whatever course is defined in the nav data.

This was obviously a deliberate design choice by Asobo. The fact that every localizer in the default NAX files is set to the exact runway heading (rather than the correct published course), makes this clear. It’s fine for the majority of ILS approaches in the sim, but very wrong for localizers that are offset - especially when the offset is substantial as is the case with the two LDA approaches at KDCA.

It occurs to me that this behavior may actually be encoded into the default Nav receiver emulation - i.e. if the receiver “sees” the ILS-runway link in the APX file, then it ignores the nav data localizer definition and “sees” the localizer as being aligned with the runway centerline. Without the presence of the link, it ”sees“ the localizer as defined in the nav data. Of course without Navigraph, the nav data will always be wrong where offset or LDA approaches are concerned.

That’s all I’ve got to say about that. Expert insights very welcome, but there are some questions about this situation that only Asobo could answer,

 

[Tim Collins]

A little off-topic, but it's 2 am and I was reading through JRBarrett's post above. This is the VS9, an A340-600, on short finals for 22R at JFK on the offset ILS on 9 August 2019. There wasn't much wind, so the apparent drift is actually down to the offset. The threshold for 22R is inset around 4000ft, which is why it looks so high. I was driving the VS4, an A330-300 (G-VRAY), about to return to London. The photo is my own copyright.

 

[JRBarrett]

A little off-topic, but it's 2 am and I was reading through JRBarrett's post above. This is the VS9, an A340-600, on short finals for 22R at JFK on the offset ILS on 9 August 2019. There wasn't much wind, so the apparent drift is actually down to the offset. The threshold for 22R is inset around 4000ft, which is why it looks so high. I was driving the VS4, an A330-300, about to return to London. The photo is my own copyright.


View attachment 65994

As I understand, at JFK they usually try to use 22R for takeoffs, and 22L for landings, but obviously at busy times, both might be required. Great photo!

 

[Tim Collins]

Yes, that's right. This is around 7pm, and it's very much peak time for transatlantic traffic at JFK - it's not unusual to queue for over an hour for departure. As you say, they occasionally throw in a landing on 22R to ease the arrival flow, but it winds up everyone waiting to depart as it puts in a 5-8 minute gap in departures!

 

[JRBarrett]

Yes, that's right. This is around 7pm, and it's very much peak time for transatlantic traffic at JFK - it's not unusual to queue for over an hour for departure. As you say, they occasionally throw in a landing on 22R to ease the arrival flow, but it winds up everyone waiting to depart as it puts in a 5-8 minute gap in departures!

I work for a corporate flight department, and we occasionally dispatch our aircraft to JFK to pick up company executives arriving on international flights. (Or did, prior to Covid). We would often look at the ground traffic on FlightRadar24 to try to pick out where our aircraft might be in the “conga line” waiting to depart. The best scenario was when they were using 13R for departures, as the runway threshold was very close to the sole FBO at JFK. The worst scenario was when they were using 22R, as the departure end is about as far from the FBO as you can get.

 

[Tim Collins]

Haha - we use FR24 to estimate how long the taxi will be, how much fuel to allow for it, and - in the case of the VS4 I was flying in the above post - what time to leave the gate so we don't risk arriving at LHR before 6am if we have a fast flight time.

Well, 'used' in my case. I last flew in March and leave the company on retirement in two weeks' time.

 

[JRBarrett]

Haha - we use FR24 to estimate how long the taxi will be, how much fuel to allow for it, and - in the case of the VS4 I was flying in the above post - what tome to leave the gate so we don't risk arriving at LHR before 6am if we have a fast flight time.

Well, 'used' in my case. I last flew in March and leave the company on retirement in two weeks' time.

Very sorry you couldn’t end your career with an official “last flight”, but congrats on your retirement.

 

[mottoth]

Here’s why: The “thing” causing a localizer to take the exact runway heading is the 4 byte runway-ILS link contained in the 0xCE runway record in the airport APX file. (Thank you to Hervé Sors for the insight as to what those bytes are).
In the case of KDCA, this file is: Official/OneStore/fs-base/scenery/0302/APX27180.bgl

As you undoubtedly know, this link consists of the ILS identifier numerically encoded as a 4 byte integer.

So the link is pointing to the ILS identifier. Then if one delete the stock localizers of an airport ("deleteAllILSs=true") and add new ones with different/fictional Ids then I assume the links would break. Gotta try this with LOWI LDAs, using Ids such as IOEJ / IOEV instead of real world OEJ/OEV.

 

[hervesors]

The links Jim is talking about are the coded ICAO Id of primary and secondary ILSs (DWORD) that are defined in the fixed part of runway subrecord at offsets 0xC and 0x10 respectively. Removing these links by setting values to 0 (that is no associated ILS) or coding there a non existent ILS apparently solves the problem but may have some side effects..or not (to be investigated). Also, it will certainly change - at compilation time - the ILSVORIndex section that contains airport ident for each ILS. I don't know how this summary information is used by the simulator but it may have some importance (also to be investigated).
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.

 

[JRBarrett]

So the link is pointing to the ILS identifier. Then if one delete the stock localizers of an airport ("deleteAllILSs=true") and add new ones with different/fictional Ids then I assume the links would break. Gotta try this with LOWI LDAs, using Ids such as IOEJ / IOEV instead of real world OEJ/OEV.

This might work. I know very little about airport creation in MSFS, other than what I have discovered from reading up on FSX/P3D BGL structure using the reference document available here, as well as the program BGLView, which can read the contents of an MSFS NAX file, but crashes if you try to read an MSFS APX file. I don’t know what files are created if you build a new airport from scratch using the SDK airport editor.

As I understand, the link between an ILS and runway in the APX file is nothing new - it has existed since FSX - but only in MSFS does it have the effect of forcing a localizer course to the runway heading despite the course that may be defined in the NAX file.

Although disabling the link in the APX by zeroing it out (along with using correct localizer course definitions from Navigraph) definitely will make offset localizers work correctly, removing the link may have other unwanted side effects - it might prevent the ILS from appearing in the flight planner on the world map as an available approach for a specific airport for instance. This is something which I have not looked into yet.

I do suspect that this localizer behavior is built into the coding of the VHF Nav receiver used in MSFS aircraft. For some reason, Asobo wants all localizers to be aligned to the runway centerline no matter what the real world localizer course might be. I don’t know if this was done to make their flight planner work more efficiently, or to make flying ILS approaches easier for Flight Sim newcomers or for some other reason.