MSFS ILS/LOC Navaids Stop Working in MSFS

[downscc]

A month or so ago, when I started this project, we (we being myself and others that helped me here) found that it wasn't possible to remove the stock ILS/LOC navaids for runway 13/31. That is when I discovered that 13C/31C would work and for weeks I've been working on and testing my kcrp-corpus-christi-intl project and using the ILS/LOC navaids during flight tests (I am also beta testing the PMDG DC-6 for MSFS).

Today I found than none of the approach navaids work. This includes ILS/DME 13C, LOC/DME 31C and ILS/DME 36 (which I never had a problem with before). I have verified that the properties are correct and the raw data xml looks good. I'm lost as to why none of these three are working in MSFS. It has to be something in common with all three and I don't know what that might be.

Any help/advice deeply appreciated. Oops... the backup zip is too large. Here it is sharable alpha18 project on my google drive: https://drive.google.com/file/d/1irNR8S_Zi863VOpLXxW3wuK7w-glYDwg/view?usp=sharing

 

[downscc]

This problem became one of where ALL ILS and any airport (stock, 3d party or ADE20 created) was missing all approach navaids (ILS/LOC/DME) and missing frequencies. I resolved this issue by resetting the MSFS app in the Microsoft Store, which required reinstalling World updates and resetting my custom cameras. A real PITA but I'd tried everything else and this was my last ditch effort. Finally all back now.

 

[JimBrown]

Dan, for future reference, this sounds like the nav data that gets regularly updated (was included with the most recent sim update, but sometimes is updated on its own) may not have updated properly or became corrupted. One thing to try before doing a complete reset or reinstall is to delete the "fs-base-nav" folder from the official folders. Next time MSFS is started, it should see that it is missing and download it. (Note that the folder itself and all its contents need to be deleted or MSFS will not see that it is missing. Should not take too long to download as it is less than 100mb).

Hope that helps in the future for you or anyone else searching for a solution.

...jim

 

[downscc]

Dan, for future reference, this sounds like the nav data that gets regularly updated (was included with the most recent sim update, but sometimes is updated on its own) may not have updated properly or became corrupted. One thing to try before doing a complete reset or reinstall is to delete the "fs-base-nav" folder from the official folders. Next time MSFS is started, it should see that it is missing and download it. (Note that the folder itself and all its contents need to be deleted or MSFS will not see that it is missing. Should not take too long to download as it is less than 100mb).

Hope that helps in the future for you or anyone else searching for a solution.

...jim

Jim that is an excellent tip. Logical so I might even remember it.

 

[JimBrown]

Glad to help. By the way, should work for anything else in the Official folder. Say you went and messed around with a default aircraft configuration file and screwed it up badly, are unable remember what you need to do to undo the changes, and forgot to make a backup. Delete the folder and it should either download it next time it starts, or be in Content Manager as available for installation.

...jim

 

[downscc]

This problem returned. Deleting and downloading new fs-base-nav folder didn't help. After emptying Community folder and doing a RESET on the MSFS App, all ILS were restored until I added my ADE20 KCRPmod project to the Community folder. The thing is, I've suffered this problem twice now, and to make it harder to troubleshoot, I had KCRP added to MSFS for two days since my last MSFS RESET and I didn't have a problem; however, it is likely I didn't actually depart from or arrive at KCRP for those two days.

Would someone please load my project from this backup, build and place in your MSFS and let me know if you can place an aircraft on RWY 36 without problem. The problem symptoms are easy to spot from the MAP screen where departure is selected: No frequencies in the box on the right of the map and in the game there is no ILS36 109.5/355 IOYC. Project: https://drive.google.com/file/d/1iLEuI8XCjLwA-7GVBOCCtTeJdVllHmMt/view?usp=sharing

Let me restate the scope of the problem: All ILS in MSFS all all airports disappear with I place my KCRPmod project in the Community folder.

 

[downscc]

I have restored the operation of the ILSs at my modified KCRP airport. I have found two things, the first perhaps obvious. DeleteNavigation parameters will delete all specified objects in the MSFS world, for example DeleteNavigation - DeleteAllILSs removes ILSs globally.

The second item is a bug that I've submitted to Zendesk (not that that ever results in anything): DeleteAirport -DeleteAllILSs does not act as expected. When TRUE this parameter will remove all pre-existing ILS such as those in the stock airport AS WELL AS ILS IN THE CURRENT AIRPORT.

At least this is what I have found at KCRP. Doesn't matter if I use ADE20, the MSFS DEV Mode, or create the airport.xml by hand. DeleteAirport - DeleteAllILSs removes all ILSs at this airport.

 

[mottoth]

DeleteNavigation parameters will delete all specified objects in the MSFS world, for example DeleteNavigation - DeleteAllILSs removes ILSs globally.

These parameters should never be used when designing local scenery, as they indeed deleted everything globaly in the content that is loaded before your scene. They are intended for Navigraph or any other global nav supplier that would replace all stock items with theirs.

 

[Ironpot]

DeleteNavigation parameters will delete all specified objects in the MSFS world, for example DeleteNavigation - DeleteAllILSs removes ILSs globally

I don’t believe that this is entirely true. In my experience the delete statement only affects the airport that you create the compiled project for (your projects and the underlying airport it is based on). All other airports that have ILS (or Nav data - if you clobber approaches etc as well) remain intact. Remove the project from the Community folder and ILS shroud be restored.
If what you state were true, then no-one would be able to fly using ILS etc because someone had used the statement in a package in the Community folder.
Perhaps I’m misunderstanding what you are staying?
Usually if I add ILS, I set the statement to false anyway and leave all approaches etc so that users of Navigraph and others get both mine and the inbuilt MSFS settings. Doing it this way means that I sometimes have to specify additional unique waypoints, approaches and navaids.

 

[downscc]

These parameters should never be used when designing local scenery, as they indeed deleted everything globaly in the content that is loaded before your scene. They are intended for Navigraph or any other global nav supplier that would replace all stock items with theirs.

Yes of course. My problem is that I didn't add the <DeleteNavigation> object to the ADE20 project, it was placed there by ADE20 maybe? Once I found it, early in my trek to get ILS restored, this was an obvious delete.

 

[downscc]

I don’t believe that this is entirely true. In my experience the delete statement only affects the airport that you create the compiled project for (your projects and the underlying airport it is based on). All other airports that have ILS (or Nav data - if you clobber approaches etc as well) remain intact. Remove the project from the Community folder and ILS shroud be restored.
If what you state were true, then no-one would be able to fly using ILS etc because someone had used the statement in a package in the Community folder.
Perhaps I’m misunderstanding what you are staying?
Usually if I add ILS, I set the statement to false anyway and leave all approaches etc so that users of Navigraph and others get both mine and the inbuilt MSFS settings. Doing it this way means that I sometimes have to specify additional unique waypoints, approaches and navaids.

Be careful to differentiate between <DeleteNavigation> and <DeleteAirport>. The latter being the object normally used to remove stock airport objects. The problem I identified was with <DeleteAirport>DeleteAllILSs removing both stock and current airport ILSs.

 

[lonewulf47]

When reading this thread I'm really starting to get concerned about the bad habit to use ILS definitions on an airport project. It should be known that ILS's are part of the worldwide AIRNC database and should not be part of any add-on. Using it on an add-on automatically creates the necessity of checking such ILS's towards each AIRAC update for correctness as it may or may not change within an AIRAC cycle. Using the standard navdatabase must be sufficient for the worldwide coverage of any ILS'es. Funny enough the ARINC database is sufficient for worldwide Real Life Aviation, but obvioulsy not for simulation ?!?!? Only if an add-on airport is NOT part of the default database an ILS should be defined in an add-on airport. Everything else is playing havoc to the idea uf using a worldwide database - which was the basic idea in MSFS (like it works perfectly in Laminar's X-Plane). But a lot of developers have decided to use their own ILS definitions within an airport BGL - the result sometimes being catastrophic as MSFS decided to use the magnetic bearing as a a new standard for ILS definitions and the interaction of ILS bearing and actual magnetic variation within the airport record is also leading to errors in the ILS setup. No one with some basic knowledge in Aerial Navigation would ever have defined such a silly thing - but Asobo did... So whenever you come across the need of using an ILS definition in your airport project, please think it over twice whether you really want to "recreate" an ILS where it is already defined in the woldwilde database. There is simply NO NECESSITY FOR THAT !!

 

[Ironpot]

Hi. My comments were around two things essentially:
1. Yes adding ILS for say fictional use and because it’s only in that specific project, does not need require the ILS nor Approaches etc set to True
2. Actually using these statements only disables them for the package and not for every airport globally

 

[downscc]

When reading this thread I'm really starting to get concerned about the bad habit to use ILS definitions on an airport project. It should be known that ILS's are part of the worldwide AIRNC database and should not be part of any add-on. Using it on an add-on automatically creates the necessity of checking such ILS's towards each AIRAC update for correctness as it may or may not change within an AIRAC cycle. Using the standard navdatabase must be sufficient for the worldwide coverage of any ILS'es. Funny enough the ARINC database is sufficient for worldwide Real Life Aviation, but obvioulsy not for simulation ?!?!? Only if an add-on airport is NOT part of the default database an ILS should be defined in an add-on airport. Everything else is playing havoc to the idea uf using a worldwide database - which was the basic idea in MSFS (like it works perfectly in Laminar's X-Plane). But a lot of developers have decided to use their own ILS definitions within an airport BGL - the result sometimes being catastrophic as MSFS decided to use the magnetic bearing as a a new standard for ILS definitions and the interaction of ILS bearing and actual magnetic variation within the airport record is also leading to errors in the ILS setup. No one with some basic knowledge in Aerial Navigation would ever have defined such a silly thing - but Asobo did... So whenever you come across the need of using an ILS definition in your airport project, please think it over twice whether you really want to "recreate" an ILS where it is already defined in the woldwilde database. There is simply NO NECESSITY FOR THAT !!

Thank you for your opinion. I am very familiar with navdata, airac cycles and products available from sources such as Navigraph as a backdrop to my years of actual flight experience (I earned my instrument rating in 1984),

The problem that I am solving is that at my home base, KCRP, whereas the stock APX bgl file for this airport has correct and current definitions for the the approach navaids (ILS, ILS and LOC) the MSFS platform does not render or make available the glides slope information in-game. One may do a bgl to xml conversion, create a project and load the project into the in-platform DEV mode and see the properties for the glideslopes. However, when the xml package is compiled either in-game or with DEV mode Investigator the result is missing glideslopes. This has been posted several times with the zendesk but it's probably not going to be fixed.

So yes sir, there is a necessary need to define the ILS for KCRP in a user defined package.

As an aside, I quickly saw their use of magnetic course and immediately wondered why they need the mag var parameter LOL. You have to remember the Asobo developers went for a ride once in a GA aircraft and someone read a book about aviation and that's the extent of their qualifications.

 

[lonewulf47]

As an aside, I quickly saw their use of magnetic course and immediately wondered why they need the mag var parameter LOL. You have to remember the Asobo developers went for a ride once in a GA aircraft and someone read a book about aviation and that's the extent of their qualifications.

Well, this is - unfortunately - exactly the qualification level of almost all people of the MSFS team. Apart from that my opinion regarding own ILS definitions in add-on airports is unchanged. It may well be that in ONE single case a definition may be necessary. In your case of KCRP of course a extension is necessary as the default layout simply misses RWY18/36. There are other such "errors" in the default database which needed corrective actions. Looking at the currently available commercial and freeware add-ons I see that approx. 20% of the developers use their own ILS definitions on perfectly correct ground layouts, one qarter of them including erroneous ILS definitions ! This is simply unbearable. And I'm not talking "out of the blue" but have installed some 350 add-on airports to-date, which gives me a pretty good picture of the habits of these "developers". Thanks god we have deveoped our own MFS BGL Editor in our company, which allows us to manually edit and correct faulty data.

As a sidenote I might add that I also used to be a commercial pilot for almost 40 years with private, business and airline experience /(20'000+ flying hrs) including all necessary instructor licenses and after my retirement from active flying I worked another five years for Lufthansa/LIDO on exatly the subject of ARINC Navigation data. So, believe me, my opinion on destroying the initially well thought worldwide common database has quite a reasonable background and I'm not really happy to see it weakened by far too busy developers.

I do hope that the navigation database will be substantially improved. It was in fact a strange move by Asobo/MS to choose NavBLUE for their database where Jeppesen or LIDO would definitely have been the better choice. Let's hope for the better in this respect and see MSFS being developed into a REAL Flight Simulator rather than graphically pefect Landscape Simulator...

 

[mottoth]

Be careful to differentiate between <DeleteNavigation> and <DeleteAirport>.

Yes I may have mixed-up those two. My comment was about <DeleteNavigation>

 

[downscc]

Well, this is - unfortunately - exactly the qualification level of almost all people of the MSFS team. Apart from that my opinion regarding own ILS definitions in add-on airports is unchanged. It may well be that in ONE single case a definition may be necessary. In your case of KCRP of course a extension is necessary as the default layout simply misses RWY18/36. There are other such "errors" in the default database which needed corrective actions. Looking at the currently available commercial and freeware add-ons I see that approx. 20% of the developers use their own ILS definitions on perfectly correct ground layouts, one qarter of them including erroneous ILS definitions ! This is simply unbearable. And I'm not talking "out of the blue" but have installed some 350 add-on airports to-date, which gives me a pretty good picture of the habits of these "developers". Thanks god we have deveoped our own MFS BGL Editor in our company, which allows us to manually edit and correct faulty data.

As a sidenote I might add that I also used to be a commercial pilot for almost 40 years with private, business and airline experience /(20'000+ flying hrs) including all necessary instructor licenses and after my retirement from active flying I worked another five years for Lufthansa/LIDO on exatly the subject of ARINC Navigation data. So, believe me, my opinion on destroying the initially well thought worldwide common database has quite a reasonable background and I'm not really happy to see it weakened by far too busy developers.

I do hope that the navigation database will be substantially improved. It was in fact a strange move by Asobo/MS to choose NavBLUE for their database where Jeppesen or LIDO would definitely have been the better choice. Let's hope for the better in this respect and see MSFS being developed into a REAL Flight Simulator rather than graphically pefect Landscape Simulator...

I believe we could share many interests although our paths are different. I had the commercial pilot's license but only flew a few for-hire flights because my career was in the US Air Force as a communications engineer and my areas of responsibility grew from HF radio (think aeronautical stations) to all things electronics attached to the ground on a base (navaids, meteorological, radio, telephone, radar etc.) and I finished that career as the Chief of Logistics for a combat communications group during Desert Storm. I then spent a few decades as an electrical engineer consultant and project engineer in the petrochemical industry, which is why I had so few for-hire flights (the pay wasn't good enough) and instead flew a Cessna Chancellor C-414 (MSN 0004) until retirement.

I also have quality checked and made corrections to many many 3d party airport sceneries, and it seemed as if the developers would spend hundreds of manhours on a project only to ignore the navaids and rely on the stock, which before P3Dv5.0 were obsolete and could never correctly place a GS or DME transmitter. However, I found the LM finally updated those navaids in v5.0 but never provided a tool to keep that data up to date. Now it seems that Navigraph is closing in on an ability to provide recurring updates to MSFS, at least for those not attached to an airport object, and I agree fully with you that scenery developers need to leave the navaids alone unless they know what they are doing.

Back on topic at KCRP. The MSFS rendering is likely based on satellite data taken about 2008 when 18/36 was closed for lengthening, and before 13/31 was later lengthened, and the taxi layout vastly changed. They also missed the new US Coast Guard ramp and facilities that are a vital resource for our area. So the scenery is missing a runway but the navaids for that are baked-in, and a too-short runway is in there but the actual GS is not aligned with the runway. I wonder if the mis-alignment or mis-match between runway and navaids is the reason they do not render? The only way I know to test this is to edit the stock APX21220.bgl correcting the runways and then observing if then the navaids are rendered correctly.

I only use the FAA NASD data from their website for setting the runway and navaids. I'm sure you are familiar with their eBrowser. Thanks for the exchange.

 

[lonewulf47]

I only use the FAA NASD data from their website for setting the runway and navaids. I'm sure you are familiar with their eBrowser. Thanks for the exchange.

No, but I have direct access to most of the ARINC wordwide database as far as navaids are concerned. When it comes to checking navaid positions Google Earth is a pretty reliable and accurate means for crosschecking.
As a sidenote: When checking the stock APX21220.bgl I see that all LOC/GS/DME transmitter are available at correct positions. So if you define the RWYs correctly, they should be in correct place too.