The option you need to make sure is turn off is this one:
No need to mess with User Airspaces.
With the LNM built-in Navigraph data off and the stock MSFS scenery/NAV data loaded in, here is KDCA - totally wrong, the LDAs for RWY 19 are locked to the runway heading in the MSFS data:
With the LNM built-in 2018-era Navigraph data turned on (‘Use Navigraph data for All Features’) the LDAs are oriented correctly for RWY 19:
The data as included with MSFS is wrong.
So step 1: Use Navigraph data
Step 2: … totally not a Python script running through all .bgl files and editing the offending four bytes for all airports… no, who would do such a thing!
OMG – Thank you !! I had completely missed that override …
Turn it on and BANG, all my LDA’s disappear and become ILS with runway headings !!
THANK YOU.
OK, so thats how to control LNM.
But it’s still an issue with MSFS … even if I install navigraph data for MSFS ?
Not done that before … FSX was correct with FSX data …
or do I still have to wait for Osobo to fix it ?
lol I would in a heart beat … does such a thing exist ??
Using Navigraph data in LNM will show the correct localizer headings, and using Navigraph data in MSFS will set the localizer core data to the correct course so the the Nav receiver will auto-set the course to the correct value. BUT without also making the edit of the airport BGL, the actual localizer in the sim will remain locked to the runway heading.
I do know that Navigraph replacement nav data only partially overrides the core sim data. One problem now is that if a waypoint is found in both NavBlue core data and the Navigraph beta, it will often cause such waypoints to flicker on the MFD map display. According to a recent post on the Navigraph forum, they have found a way to override ALL the NavBlue data completely, and are testing this internally. Once this is ready for public release it might fix the offsets - but I wouldn’t count on it. From what I have seen, an edit of the airport BGL is still required.
Can we maybe write a PowerShell script for this which can simply be run after every update?
Sounds like a plan … and maybe include ASOBO on the distribution list before next update is due.
That might be pretty complicated. The edit can only be done with a hex editor, which can change individual bytes in a file while leaving all others untouched. There would need to be a means to determine which specific APX file contains the airport data. I do know that the BGL folder/file naming convention for airport scenery in MSFS appears to be identical to FSX and P3D.
For each localizer, the algorithm would have to be run on the identifier string to convert it to a 32 bit integer, and then a hexadecimal search would have to be performed on for the specific 4 bytes that would result (stored in litter-endian order), to change them all to zero. This would require a database of all localizer identifiers.
Seems way too complex to me. It’s no problem doing it for an individual runway at an individual airport, but trying to automate the process seems rather complicated.
The great majority of localizers are fine “as is”, as long as the localizer truly is aligned to the runway heading.
I assume the 4-byte value is inserted into the airport APX by the scenery compiler. I do NOT know if that value serves any other purpose other than forcing the localizer to the runway heading. If it also affects flight planning or other sim features it might break something else, but I have not seen any negative effect (so far) on the few airports I have hand-edited.
There is already a CVS document that has been generated that has all the Airport ICAO codes, and their corresponding .apx file.
That would seem to be one part already done.
I’m gonna tune in here. This seems like a pretty big oversight.
Here’s to hoping this gets resolved soon.
I agree this is a very serious problem, I filed a bug report with Zendesk, and I suggest everybody reading this thread doing the same.
Same, I filed this exact post to Zendesk.
After speaking with Hervé Sors, (who does not currently own MSFS, but has a good understanding of the structure of airport and navaid BGL files), in previous MS sims (FSX, and ESP-based P3D), the 4 bytes in question serve to link a specific ILS to a specific runway. They apparently serve the same function in MSFS, but evidentially, also cause the localizer to ignore the course in a “correct” nav data file, (such as those provided by Navigraph), and instead take the runway heading in all cases.
The actual source of the problem may actually be in the coding of the Nav receiver emulation.
There is no question that this behavior is deliberately designed, because the localizer courses in the default NavBlue core nav data, have all been set to the exact runway heading for every ILS approach in the sim world. The Navigraph replacement nav data has the correct localizer courses for those that are actually offset, but it does not matter, because as long as the 4 byte runway/ILS link in the airport scenery BGL is present, the localizer will be always set to the runway heading.
This explains why, even when an ILS that should be aligned with the runway, but it’s not ( maybe because it was inserted with True Heading like in FSX instead of Magnetic ), airplanes that you can set the CRS manually, will fly the approach just fine: the localizer IS in fact considered to be aligned, no matter what.
However, those airplanes that don’t allow to set a CRS manually, like the A320, will have the CRS wrong because, apparently, the heading information IS being used, if only to set the CRS automatically.
It seem that a lot here understand what the issues are.
Anyone else, reading the posts in Topic for the 1st time, will most likely find it very confusing, at least at first.
This is not conducive to motivating them to Vote for this, and it seems,
to get things noticed, Votes count,
So maybe , even in the 1st Post, a simple description of what Asobo needs to do to correct these issues, and some evaluation of now difficult that would be would help make the solution to this issue a lot clearer to all (including Asobo)
I don’t know how it works in MSFS, in real life it doesn’t matter a thing if you set the CDI / OBI a few degrees wrong. A localiser does not work like a VOR, on a steam case OBI for example the course selector (OBS) does not serve a purpose at all as soon as a localiser frequency is tuned.
I will try to rephrase some things in the original topic, as for the solution to the problem, I also don’t really understand how any of this works… 
Maybe someone else in this Topic does … maybe HalberQuacky ??
Having a precise short description of the Issue, and with the solution is, spelt out, at the start of the Bug Issue, should go a long way towards getting it noticed and looked at.
Its also then in an ideal format to send to ZenDesk , short, and to the point.
It’s been a few days. I checked the latest version of MSFS, and this hasn’t been addressed yet.
I’m gonna make noise in the zendesk as well.
Since it was not addressed in the (end dec 2020) last update, it might be time to make the wheel squeek again …
Hit up Zendesk again …
