i tried now. Does not work . the ils is wrong at LOWI. and so I think everywhere. But does Asobo know the problem? @Jummivana
1 Like
I think this bug fix is something different though, its under âdisplayâ. I think there was just something wrongly displayed on an MFD or so regarding LDAs which they have fixed.
for a moment I hoped they get at least one thing right 
âŠ
depressing 
The TWO LDAâs into KDCA work well, and the AP can follow the âVHFâ Localizers correctly.
Even the VFR Map looks :almost" correct .
However, the original WORLD MAP flight planner, is still putting in extra WPs, to fudge an aligned runway approach â shame, but itâs ONLY THE VFR MAP, so easy to ignore itâs Fantasy World.
The Plane does NOT fly the magenta line on the VFR MAP ( Good thing) â It flys the path on the GPS. - which is good !!
the whole WORLD MAP flight planner needs a major overhaul, but for any serious flight planning, there are many better tools, that do a far better job than MSFS will ever be expected to do.
Still wrong everywhere I checked. Although at most places the correct course is showing on the course selector, the actual localiser still tracks runway heading.
1 Like
OK ⊠been trying to follow this thread to see whats going on as I am sure MKJP (Normal Manely INTL) RNWAY 12 ILS takes me RIGHT of the runway and lines me up with the grass ⊠every time. Are these broken ILS in the game that needs to be fixed ??
Maybe, is the ILS you are speaking of offset in real life? The problem is that approaches which are offset in real life are actually aligned in MSFSâŠ
1 Like
The approach chart mentions an offset localizer. Runway heading 117°, ILS inbound course 120°.
This means that the location of the loc antenna is most likely correct, but as @anon50268670 pointed out, the inbound track in MSFS is wrong.
I now know for certain that what I have long suspected about this problem is indeed due to coding in the actual NAV receivers of the default Asobo aircraft.
Even with Navigraph beta nav data in place (which sets all localizers to their correct r/w values), all default aircraft âseeâ the localizer as having the exact same heading as the runway no matter what the navdata says.
Asobo did change this behavior in SU3 for a few selected airports with really large offsets, like the LDA 19 approaches at KDCA, but most smaller offset localizers are still wrong.
But - guess what? There is one aircraft that does not have this problem - the new Aerosoft CRJ.
The reason why, is that the CRJ does not use the Asobo Nav receiver as all the default MSFS aircraft do. It has its own nav receiver emulation, and the CRJ does indeed fly every single r/w offset approach correctly, as long as Navigraph beta nav data is installed to provide the correct r/w localizer courses in the scenery.
I have tested this at KDCA (before Asobo fixed it), KJFK ILS22R, the ILS-Y04L and ILS-Y22R at KDTW and the LDA 28R at KSFO and the CRJ flys every offset localizer perfectly, as verified by tracking the flight path on georeferenced approach charts in Foreflight.
This is not due to anything âspecialâ in the CRJ, other than the fact that it uses itâs own nav receiver coding.
So, without question, the ultimate source of this issue is due to the way the default Asobo Nav receivers are coded.
3 Likes
Nice find 
Hi,
Does it mean that if one is using the Aerosoft CRJ, ILS offsets should resolve itself?
I do have a Navigraph subscription.
Do I also need to âupdateâ MSFSâs scenery?
Yes, for this to work correctly with the CRJ, you would need to use the beta MSFS core nav data replacement, so that all localizers in the scenery (both offset and non-offset) have the correct r/w headings.
In contest to this: I had just tried to fly the LDA 35 approach into KSLC. The localizer is aligned with the runway heading but is offset. Similar to what everyone was reporting before SU3.
The Aerosoft CRJ flew the same profile that the default Asobo TMB930 flew.
So two things from this:
- The Aerosoft CRJ doesnât emulate the nav database. It uses the sim data.
- The threshold that Asobo uses as the minimum offset for them to make the localizer offset in game is insufficient. The KSLC LDA35 approach couldnât be done as designed.
Why does there have to be a threshold? Just make the threshold something low enough like 0.1 degrees, so if theyâre designed to be aligned but theyâre not because of computer rounding, then they round to be aligned.
Why not just make them CORRECT â far easier in the long run âŠ
Put it right & move on âŠ
1 Like
I just flew the LDA 35 at SLC in the CRJ, and agree that it is not working. As you said, it approaches from the wrong side, which is what the default aircraft do. This was working during the test pre-release test phase of the CRJ - I flew at least 10 different offset approaches at different airports, and all were tracked perfectly. (Using Navigraph beta core nav data for MSFS).
I suspect that this may be because the CRJ is possibly now using the default Asobo Nav radio âbehind the scenesâ to try to solve the problem where the aircraft would sometimes do an immediate dive when intercepting the glideslope - or, the changes that Asobo made in SU3 to fix some (but not all) offset localizer tracking at selected airports (like KDCA) has now broken the localizers at airports that were not fixed like KSLC LDA35 - at least where the CRJ is concerned.
There is no question in my mind that this behavior is coded into the Asobo Nav receiver itself. Looking at the KSLC LDA35 in Little Nav Map (with Navigraph beta nav data active) shows the localizer has exactly the right orientation, crossing the runway from left to right, and oriented 344 degrees, but the Nav receiver ignores that and tracks the localizer as if it was actually oriented 349 degrees.
I am still at a loss as to why Asobo has deliberately coded their Nav system to work this way. Instead of fixing âsomeâ offset localizers at a âfewâ airports, they should simply remove the code that forces the Nav receiver to always see every localizer as having the exact runway heading (no matter what the actual localizer course is), and then change the default core nav data to set the localizers in the scenery to the correct r/w courses. Navigraph already does this, but the default Nav Blue data does not.
Neither P3D nor X-Plane have this issue - this is unique to MSFS.
BTW, looking at KDCA in Littke Nav Map without Navigraph installed shows that they only fixed the LDA 19 Y approach - the LDA 19 Z is still wrong.
1 Like
Further mystery⊠I just flew the ILS-Y 22R at KDTW in the CRJ, which has a 3 degree right offset, and it flew it perfectly, just as it did in previous testing with this aircraft, so I am somewhat at a lost why this works, and the KSLC LDA 35 does not. I will investigate further.
Just some information for my attempts to âshiftâ an ILS defined in an airport that i deemed to be at a wrong coordinate.
Airport in Question : WMKP
Navigraph ILS Localizer Coordinates : 5.311306,100.290389
MSFS Default ILS Localizer Coordinates : 5.311306,100.290389
Real World seen from Google Maps : 5.311271, 100.289413
Basically as you can see in real world, the Localizer antenna array is actually at a different coordinate.
Things Iâve tried:
- Since i know that MSFS loads packages in order, and a later package can override older loaded packages, i uninstall Navigraph data first. So that everything is default.
- Then i created an airport project and defined deleteallILSs for the airport, moved the ILS coordinates
- save and exported the project into community folder.
- reloaded the game.
- Planes still recognize the localizer as the old position and bring me land on grass.
I couldnât figure out why. When i load the packages/scenery up in Little Nav Map, it accurately showed the ILS cone with shifted position, but planes still doesnât seem to reflect that update.
So similar to this Off LDA approach issues, I think we are missing the link where the planes are referencing nav data to use ILS following, both for a plane that uses itâs own nav data and a plane that uses msfsâs nav data. .
Hi,
according the AIP Malaysia, the coordinates are correct so far. So, when this is wrong then the real-world AIP Malaysia is wrong - Jeppesen can only handle data which are validated by the countries.
Here directly from the AIP Malaysia:
051840.7N = 5.311305555
1001725.4E = 100.2903888
Exactly the same values as we have in the database. Sorry, in this case, we can do nothing because it looks like a real-world issue and not a navdata in the sim.
Cheers,
Richard
1 Like
Maybe they donât use WGS84 in that part of the world?
This same problem already occurred in FSX in Innsbruck, it also happens in the approach to Sitka (PASI). Does this have any solution?
1 Like