OK, I’m with you now. I haven’t come across this because, like I said, I am only using the Islander since the update. Thanks.
BTW…Navigraph have sorted out all the out of line ILSs which is great news.
Do you happen to know if they are working on a fix for this? It’s a bit frustrating that we can’t line up correctly with the runway. Aren’t we supposed to be able to trust the ILS? I just did a landing at Alice Springs Australia and it put me right in the dirt.
Question for ya… but how do you use navigraph? I am new with this and would like to fix the ILS issue if possible. If I get a subscription what do I do with it?
I still hope and I’m pretty sure that Asobo will fix the offset ILS issues within the next few sim updates.
Contrary to PZL I’m not that optimistic. This has been a year already without improvement.
They released their upcoming 7 September fixes. It’s a handful. Either they’re not communicating sufficiently about what they actually fix, or it’s just the handful.
There was a Q&A (don’t remember which one) where Martial said that they’ve fixed a couple of those already and they keep improving and updating the rest. However, I haven’t seen any improvement so far. Maybe the Q&A question wasn’t understood (not the first time).
The issue is it shouldn’t have to require a manual fix for every occurrence. The correct data already exists, the MSFS system incorporating this data incorrectly is the problem.
The fact Asosb’s response is to make manual corrections indicates they’re not really trying to fix the underlying issue. Are they really going to find and fix every single problem ILS/LDA/LOC in the world, manually, one at a time?
Unfortunately I see a bunch of the more well know and popular offsets being corrected, and then attention slowly drifting elsewhere.
But if it’s a ‘translation’ problem by the sim, how does Navigraph get it right?
That more or less seems to indicate the delivered data by the other one (NavBlue?) is incorrect. Or it could still be a broader issue, where Asobo uses buggy tools to convert the data. If that’s what you mean.
Yep. Initially Asobo arbitrarily set every ILD/LDA/LOC to the runway heading, and this is hard coded into the system, regardless what the navdata indicates.
Prior to SU4, the ILS receivers in all default airplanes would “see” the ILS localizer as having the exact same heading as the runway if there was a standard 4-byte code in the airport scenery file indicating that a particular runway had an ILS. Normally in previous sims, the ILS localizer course was set to the value in the nav data file.
I assume this was deliberately done in anticipation that there would be an influx of new users to MSFS with no previous familiarity with ILS approaches. The fact is that the great majority of r/w ILS localizers are perfectly aligned with the runway centerline, so this “simplification” would work most of the time.
MSFS does read the nav data file, and the ILS course that appears on the PFD in the default Garmins (when an ILS is being received) comes from that file.
Because (initially), all localizers would be “seen” as having the same heading as the runway, I assume that Asobo either instructed NavBlue to set all localizers in the nav data to the exact runway heading, (no matter what the real world course of the localizers might be), or Asobo themselves sets the localizers that way in the process of importing the NavBlue source data into a form that can be used in the sim.
I am quite certain that NavBlue has the correct localizer headings for all r/w ILS approaches in their original source data, just as Navigraph does.
Apparently Asobo did not at first realize that doing things this way would cause problems with r/w offset localizers because in those r/w systems, the localizer antenna is not physically positioned beyond the end of the runway, but off to one side. With the correct localizer position in the airport scenery (but incorrect course), it would force aircraft to land beside the runway when an offset approach was flown by the autopilot.
When SU4 was released, Asobo fixed “half” of the problem. The code in the nav receiver emulation that would “see” the localizer as having the exact runway heading was removed. After that change, the localizer course would come directly from the nav data, as in all previous MS sims (FS9 and FSX).
But, apparently they forgot to change the nav data. The default nav data localizers are still all set to exact runway headings.
Navigraph by contrast has all localizers set to the correct r/w values, so after the “fix” that was applied to the nav receivers themselves in SU4, offset localizers do work correctly - if Navigraph nav data for MSFS is used.
If Asobo initially instructed NavBlue to ignore the localizer course from r/w sources, and set all localizers to exact runway heading to be compatible with the original “simplified” ILS in MSFS, then they simply need to tell NavBlue to stop doing that going forward, and retain the correct r/w course data.
Or, if Asobo themselves are still setting the localizer course data to exact runway heading in the process of converting NavBlue source files to MSFS format, then they need to stop doing that, and instead use the correct r/w values. There have been several updates to the default nav data since SU4 was released, but the offset localizers still have the (wrong) course values in the default data.
I suspect this is an oversight. Asobo fixed the “simplified” ILS behavior in the default nav radio emulation in SU4, but forgot to fix the default nav data to match the new (correct) nav radio behavior.
Since SU4, all r/w offset localizers do work correctly as long as Navigraph nav data is used for MSFS instead of the default NavBlue data.
If you subscribe to Navigraph, you will be able to download a stand-alone data manager app that will automatically update the default MSFS nav data with the replacement data from Navigraph. It is very easy to use. The same data manager can also be used to uninstall Navigraph and revert to the default data if you wish.
Navigraph does not overwrite the default nav data, but it is placed in the Community folder at a higher priority level than the default data, so MSFS will use it in lieu of the default.
Okay… well… then I don’t fully understand why people are still complaining about landing next to the runway?
I haven’t tested this myself on all these Chinese airports that are wrong. I mean, just look in Little Navmap at Beijing. It’s a mess. But if you tell me the airplane is ignoring that data (if I understand correctly), it should work anyway?
That the localizer course is synched with the runway heading does not mean the you’ll end up at the runway. If you take Innsbruck as an example, one localizer antenna is not even located at the airport, the other is located next to the runway. You will end up over the threshold in real life because the localizer is offset, in MSFS you end up parallel to the runway in the grass.
Point is that the geographical location of the antenna is correct in most cases, that also answers your Chinese question. The localizer course might be aligned with runway heading but if the localizer antenna is not at the right geographical location, you’ll end up flying parallel to the runway into the grass.
Yes, I think we’re mixing up two issues here: real offset ILS antennas that are wrong and ILS antennas that are just out of whack (offset in the Asobo data but not IRL).
I’m mainly focused on the second problem, where the ILS is just wrong on so many airports.
Perhaps I don’t fully get the lengthy explanation of @HalberQuacky, but he seems to indicate that there’s a difference between the data (e.g. as shown in Little Navmap) and how an airplane handles it. However, I never noticed that: a wrong ILS lands me wrong. But I haven’t tested any of this recently.
Do you mean you haven’t experienced this “parallel/offset” bug?
In this case try LFMN ILS 04R 110.7
No, I mean that my airplane does not ignore the offset (wrong) ILS if it’s grossly misaligned. It lands the plane wrong. In other words: what I see in Little Navmap happens in the sim.
What do you mean by offset? Offset as in the wrong final approach course or offset as in flying parallel to the runway? I’m only aware of these two bugs:
- Airports having the localizer aligned with the runway where the real world localizer is offset.
- The localizer antenna at the wrong geographical location, in other words flying the right course but flying parallel to the runway into the grass.
I’m talking mainly about number 2.
The aircraft can’t ‘ignore’ the offset. It can only follow the fixed localizer course.