Cannot delete existing airport ILSs or NDBs anymore?

Hi Guys. We don’t seem able to remove the default ILSs or NDBs and replace
them with custom ones when replacing an airport that comes with the simulator.
Not sure when this occurred, not had this issue before and our current airport
(WBGR) has been in development for several months, we’ve only just got around
to final testing which includes fine tuning glideslope position etc. We were
trying to reposition our custom glideslope as it seemed way out of position in
flight, but any movement didn’t make any difference to the touchdown point.
The glideslope was removed from the runway completely and tested again, we
found there was still an active glideslope for the runway even though there
was none specified. We removed the ILS completely from the runway element and
testing again gave us a VOR DME with glideslope that shouldn’t be there. Our
workflow usually sets up the initial XML manually based on the SDK
documentation. We’ve subsequently set up a simple airport replacement for WBGR
with delete commands set for everything, and a simple runway using only the
scenery editor. With the only compiled project in the community folder and
nothing else, the ILS and DME are still shown on the world map. The project
xml screenshot is attached.

a cross check we have done the same for EGNM Leeds Bradford, replacing an
existing airport using the scenery editor and deleting everything using the
delete options in the airport element. The results appear the same with the
default airports ILS and NDB being displayed on the world map and not being
removed as expected. We’re a little stuck between a rock and a hard place at
the moment.

Hi, Are you using the current SU10 beta ? Because a bug with deleteILS and
deleteAllTerminalNDB have been fixed in it. Regards Xavier

Hi Xavier, We are using the current release version rather than the SU10 beta.
Is it a known issue with the current release? All the best, Chris

Yes it is a known issue, it may have been fixed with this release:

Hi Xavier, We can’t develop using the Beta version unfortunately, we are
releasing a commercial product for Marketplace and our policy is that we must
use the current stable SDK release or revert to a prior stable SDK version at
worst case, so that we don’t release anything that can cause problems for our
customers. A couple of questions that may help us with this:

  • Is there an approximate date yet for the SU10 official release (plus SKD which tends to be deferred) so we can test and hopefully announce a product release date, if we delay things until we can test with it in release version?
  • In which version of the SDK did the bug with deleteILS and deleteAllTerminalNDB that’s been fixed in SU10 beta start? We have all the SDKs archived somewhere and can try building our package with a version that doesn’t have the bug to see if that solves the problem.
  • Can you let us know where and when this issue was initially reported in order to become something that needed to be fixed? We do study all the release notes and monitor the forums for things that may cause problems with our projects, but our fist encounter with the ILS issue wasn’t anticipated as it hasn’t been an issue prior to March this year as far as I know, which was our last commercial release. Apart from the fix in the SU10 beta notes, we can’t find any reference to the initial problem.

Sorry to ask so many questions but we need to know these things in order to
adapt as necessary as a business and Microsoft Partner. Regards, Chris

Hi Guys, Just a quick update on our custom ILS situation. We discovered this
in the very early hours of the morning and have not yet had the time to
investigate further. We attempted to add an alternate ILS on a different
frequency with all other parameters the same including ILS ICAO code. Whilst
testing the ILS approach and switching to the new alternate frequency, no
glideslope or localizer were available, suggesting the alternate ILS does not
exist. To confirm, the ILS was edited using the project editor again,
intending to change to another different frequency, but accidentally typing in
the ICAO field instead. The moment that the ILS ICAO field changed from the
default, all of the gizmo’s showing ILS LOC and glideslope appeared (which we
hadn’t noticed were missing), the glideslope was positioned correctly and the
project compiled for testing. After creating and starting a Low Altitude
Airways flight with the ILS approach as the destination, the flight was
started. At cruise the ILS parameters were checked in the FMS. Amazingly and
somewhat surprisingly, the FMS was showing our alternate ILS frequency instead
of the default. The ILS approach proceeded perfectly, precisely in line with
the PAPI indicators all the way down to touchdown. (With the default ILS, the
glideslope disappeared between 800-1000ft some distance from the runway
threshold), suggesting our custom ILS with a different ICAO code WAS now
available. We have yet to try setting the ILS frequency back to the published
frequency for authenticity, theoretically it should work if it’s an ICAO code
conflict being part of the original problem of not being able to remove the
default airport ILSs. POST EDIT: After editing the project to set the
alternate ILS with the different ICAO code, the frequency was set to the same
value as the one that we can’t remove, IMR 110.10 in our case, for Miri WBGR.
In flight after compiling, the aircraft followed the alternate ILS and the
glideslope that we set to lead in nicely to the touchdown markings. It was
noted that BOTH ILS’s were shown on the world map when display navaids was
enabled but only the newer custom ILS was active in flight. All sounds a bit
complicated but here’s the summary:

  • When the default ILS can’t be removed using the DeleteAllILSs command, creating an alternative one with a different ICAO code seems to help. Creating one with the same code appears to be ignored and doesn’t solve any problems.
  • The published ILS frequency can still be used by the alternate, in our case for testing we modified the ‘friendly name’ too to see what was displayed in the cockpit. The alternate ILS was the one used by the aircraft on IFR approach, together with it’s custom glideslope in our case.
  • Drawbacks for us: The ICAO code and the friendly name consequently different to the official ones published and duplicate LOC/DMEs are shown on the World Map with, the show navaids selected. That’s about it really.

Hope our contribution helps. All the best, Chris The Secret Studio