Hi guys. I would like to ask you if there is a way to modify the airport glideslopes.
I found that in many airports they are usually bad placed. For example in Naples airport LIRN, the horizontal glide is completely wrong and placed on the far left of the runaway.
Thank you in advance to anyone who can answer me.
1 Like
Are you talking about the lateral path or vertical path because when you say āāhorizontal glideāā itĀ“s quite confusing.
The vertical path is the glideslope, the lateral path is the localizer.
1 Like
Yes sorry I was confused, I mean the lateral path, the localizer. Usually I donāt find errors in the vertical path, while the lateral is often bad placed, in smaller airports.
Are you far off to the left the whole time during the approach, even at 10 miles out or only when youĀ“re getting really close to the runway?
As you get closer to the runway youĀ“ll need to be more and more precise thus small deviations from the localizer at 10 miles will seem insignificant, but will be much larger at say 0.5 miles.
Which runway are we talking about so that I can give it a try?
It should be runaway 06. I think I was quite afar to be honest, it seemed that the runaway was on my right for the whole approach.
If you want to try and give me your feedback, that would be awesome! It is indeed a very beautiful approach, from the sea, you can see all Naples with his harbour, Vesuvio, and the beautiful island of Ischia.
Yes, just finished testing. Did a quick take off and tried runway 24 and it is perfect and then tried runway 06 and itĀ“s totally off to the left, you were right.
Contact zendesk to let them know and hopefully they will fix it.
It is indeed a very nice place to fly! I had no idea 
Thank you! I will contact them. Glad you liked it tho
The runway 6 ILS at LIRN has an offset localizer. The localizer is angled 3 degrees from the runway. The runway heading is 56 degrees but the localizer course is 53 degrees. The localizer antenna that generates the signal is located to the left of the runway, not directly at the runway threshold as is usually the case.
Normally when a real world localizer is offset, there are technical reasons why it has to be done that way. Sometimes it is due to the fact that there may not be enough room beyond the end of the runway to build the antenna in the standard location.
If you were to fly this approach in a real airplane, on a clear day where you could see the runway from a long distance, you would find that the ILS is guiding you at an angle. You would be approaching from the right side of the runway. The beam will cross the runway centerline at a location equivalent to the minimum decision height of the vertical glideslope. At this point the pilot would disconnect the autopilot, make a slight right bank to align with the centerline, and land manually.
The problem in MSFS is that every offset localizer that exists in the real world has the wrong course. MSFS sets every ILS in the world to have exactly the same course as the runway itself. This is perfectly fine for most ILS approaches that have no offset, but it the wrong thing to do when the real localizer is offset. It will cause the airplane to land to the side of the runway. If the localizer has a right offset, the airplane will land to the left of the runway. If it has a left offset, the airplane will land to the right side of the runway.
There is no easy way to fix this yet. The ILS systems are part of the airport scenery. Although there is an airport editor in the SDK which can be accessed in developer mode, you canāt use it to edit just one thing like the ILS course. Because LIRN is a default airport, you would have to rebuild the entire airport just to fix the ILS, and put the modified airport in the Community folder so it would override the default.
4 Likes
Thank you for your exhaustive answer!
Yes I noticed that in a lot of airports, I usually end up a bit too much on the left or on the right of the runaway if I keep using ILS till the end, and now I know why.
In LIRN it is waaay on the left, but if there is no fix for this I will just try not to use that ILS approach.
Thank you to everyone!
This photo shows where the ILS 6 localizer antenna is actually located at LIRN. It is the structure halfway between the runway and the ramp taxiway marked with a X.
Normally, the localizer antenna will be directly beyond the threshold at the far end of the runway. Looking at the satellite photo of LIRN, it appears that it was once located there at some time in the past. You can see a patch of bare ground in the grass where the antenna used to be. There is no obvious reason I can see why they changed the localizer to offset, but there must have been some valid purpose. Sometimes localizers are offset because of terrain clearance issues, or to prevent the aircraft from flying over noise sensitive neighborhoods in the city.
Yes, that definetely makes sense, I can see the big offset here.
Yes, and because the in-game localizer is incorrectly set to the same course as the runway itself, in MSFS the airplane will track directly to this antenna, parallel to the side of the runway.
I did submit a Zendesk ticket about this bug. Similar problems exist throughout the world for any ILS with an offset localizer. It would be easiest for Asobo to fix it, because they have the original source files for all the default airports. The āfixā is to set each ILS in the game to the course in the published nav data, not to simply set each ILS to the runway heading. Then all the default airports would have to be re-compiled.
Yes I agree, I hope they will try to fix this like that. Sometimes when I try a 0 visibility approach I just crash on the ground at the side of some runaway 
Hello,
after many hours spent studying the .bgl file format i found a workaround to obtain the correct alignment for an offset ILS.
As many others said, the problems are that the ILS data stored in .bgl files reports the runway heading and not the ILS heading if it is different, as for LIRN RWY 06. But also if you correct this value, then MSFS automatically aligns the ILS heading to that of the runway.
So, for LIRN airport, i modified the runway section of the bgl file containing airport data deleting the reference to the ILS id and then i modified another bgl file containing the ILS data correcting the Localizer heading (with LittleNavMap you can easily see which are these files).
This is a screenshot before the mod:
ā¦and this is a screenshot after the mod:
I made the two approaches both on autopilot.
The only effect i noted for now is that you have to manually insert the ILS frequency in the FMS if you use the A320 and have selected one of the RWY 06 ILS approaches (i think itās the same for the G1000).
Itās complicated for me to describe the process for modifying the bgl files (anyway there are lots of info about them), but if someone is interested i can give the offsets of the files and the modifications i made (can i do this??? these are modifications of official filesā¦) for LIRN.
Sorry if i made confusion, this is my first postā¦
Saverio
1 Like
Hi! This seems really interesting, I would love to know which are the modifications you made to those files!
Hi, sure!
I hope you are familiar with hex editors, i use HxD, i find it very easy.
A couple of things before starting.
1-Always make a backup of the files you are going to modify!!!
2-These modifications work only for 1.9.5 version of MSFS, with another version the addresses could change.
Now open with the hex editor the file NAX51170.bgl located in the folder ā¦.Official\OneStore\fs-base-nav\scenery\0602
Go to address 246016 dec (if you are visualizing addresses in hex then the address is 3C100). You will see a sequence of these four bytes: 0B 22 60 42. It is a float number representing the localizer heading (about 56.033 degrees). Change it to 0B 22 54 42. The new Localizer heading will be about 53.033 degrees. Save the file (remember, backup first!)
The next step is editing the file APX51170.bgl located in the folder ā¦.Official\OneStore\fs-base\scenery\0602
Go to address 994096 dec (again, if you are visualizing addresses in hex then the address is F2B30). You will see a sequence of these four bytes: 14 91 00 00. It is an encoded number representing the localizer id for runway 06 (NPC). Change it to 00 00 00 00, in this way you delete the link between the runway and the localizer without deleting the localizer. Save the file.
Let me know if it works for you or if you have problems!
Sorry to say, but when you fly an offset-approach - the loc signal canĀ“t be aligned with the center line as in the āsolutionā. LIRN 06 has a 3 degrees offset - means runway-center line is 56 degrees, localizer bearing is 53 degrees. That means, that the loc-signal should be slightly left 1 mile before touchdown and not as in the screenshot centered. Because when itĀ“s centered, the antenna must be also at the end of the runway centered, and thatĀ“s not the case as HalberQuacky explained very well.
I will give you an another example:
Look at LOWI 26, this is also an offset approach - when you āfixā this according this āsolutionā and you fly the approach, that the localizer signal is centered - you will crash in the hills on the left side. As HalberQuacky explained - there are normally special reasons for such offset approaches like terrain reason, noise reasons, or similar else.
2 Likes
Apparently āgreat minds think alikeā!
I was just about to report that I had performed this exact same experiment.
In my case, I modified the course of the ILS 22R localizer at KJFK in the actual airport scenery to the correct offset course of 221 magnetic instead of the incorrect runway heading of 224 degrees which is how the ILS is set in the default airport scenery. This is different than unlinking the airport/ILS ID field.
I did it by modifying the 4-byte value for the localizer heading in the compiled APX.
This was a good learning experience for me. I spent several hours yesterday reading through reference documents at FSDeveloper.com that give a detailed explanation of the internal structure of BGL files in order to learn how to locate the specific 4 bytes that set the localizer heading.
I would point out that if you use Navigraph beta nav data it is not necessary to also modify the default NAX bgl that the ILS receiver in the aircraft uses to preset the ILS course, since since the Navigraph files do already contain the correct value for those r/w localizers that are offset.
By contrast, the default nav data AIRAC files all contain the exact runway heading for every localizer, even for those that should be offset. Iām sure that the original nav data files supplied by NavBlue do contain the correct values for localizer heading, so I have to assume that Asobo modified the values in the process of converting the NavBlue source files into BGL format.
With a correct NAX file (from Navigraph), and the correct localizer heading in the default airport APX file, (hand modified by myself), I can report that the KJFK 22R offset approach works correctly. The aircraft now tracks to the runway at a 3-degree angle from right-to-left, arriving at the centerline at the same point where the glideslope height crosses the published MDA.
That said, I would not encourage users to attempt this sort of modification. For me, this was simply a āproof of conceptā, to test whether an offset ILS would work correctly in MSFS if both the NAX and APX BGL files contain the correct data, and the test was successful.
BUT directly modifying a default airport BGL with a hex editor is frankly a āhackā. If any mistake is made in editing the bytes for the localizer heading it could corrupt the BGL which could easily make the airport unusable, or perhaps lead to a CTD. Also, leaving a default APX BGL in the modified state could cause issues when a scheduled patch update is released. For that reason, I restored the APX to its original state after my test, since a new patch is coming out tomorrow.
This is really something that should be Asoboās responsibility to fix, especially since there is no easy way to determine whether a specific localizer is offset in the r/w airport ILS, short of examining actual approach charts for every airport in the world.
3 Likes
Hi, iām happy that there is someone else who likes to experiment like me!
@HalberQuacky
i totally agree with you, i made these modifications just to learn and for fun, if you donāt make backups or make errors then you could have problemsā¦
So itās better if these issues will be resolved directly by Asobo.
@NAVData
Thank you for your observations,
anyway i didnāt modify the position of any navadata, i simply rotated the loc heading by 3 degrees. I canāt tell you if i made mistakes, i took the 2nd screenshot about at the intersection between the runway centerline extension and the loc-signal. The approach chart of LIRN rwy 06 says that the runway centerline extension intersects the loc signal at 0.75 nm before runway threshold. If you consider that the DME is about 0.2 nm miles besides the rwy threshold then i was at about 1 mile from it.
I registered the aircraft trail with Littlenavmap during an approach on autopilot:
If you look closer you can see the moment in which i leave the localizer:
Right, I only want to inform that you (or better the original poster) canāt fly the ILS till the runway (autoland) on such offset approaches (also with your āsolutionā). The first screenshot of your āsolutionā looks exactly this and I only want to make clear, that you must turn off the AP on short final because you must leave the localizer signal somewhere (exactly when the beam cross the center line).
In other words, when you sit on runway 6, and you will receive the loc, you will see, that the needle is slightly left of the centerline.