Clarification on ILS issues at addon airports

[Mir // Flightbeam 541]

I recently saw a thread here regarding ILS issues at addon airports. So here is some quick clarification with facts:

- Yes, there is certainly some big ILS issues going on.
- It's caused by the SDK not allowing us to create custom ILS for our airports.
- The issue seems scattered among all airport devs. Asobo is very aware of the issue (for many.. many weeks)
- Asobo is responding by implementing a new custom ILS tool in the next SDK update, hopefully coming in the next week(s)
- I believe this will solve the issue once and for all.. unless it contains bugs as well.

Thanks for your attention

Edited November 19, 2020 by Mir // Flightbeam

[OSM 683]

15 minutes ago, Mir // Flightbeam said:

...to create custom ILS for our airports
 

What do you mean "custom ILS" in terms of a Global Navigation in FS2020 data from NAVBLUE or Navigraph?

Edited November 19, 2020 by OSM

[Mir // Flightbeam 541]

10 minutes ago, OSM said:

What do you mean "custom ILS" in terms of a Global Navigation data from NAVBLUE or Navigraph?

Nav data for Navblue is the default data we will be able to edit in the coming SDK update. Currently addon airports are inheriting the default data from an underlying layer of scenery, which seems to cause issues.

[OSM 683]

16 minutes ago, Mir // Flightbeam said:

Nav data for Navblue is the default data we will be able to edit in the coming SDK update.

Why do you need to edit default Navigation data especially ILS, and what will be if I use Navigraph Navdata?

Edited November 19, 2020 by OSM

[Mir // Flightbeam 541]

9 minutes ago, OSM said:

Why do you need to edit default Navigation data especially ILS, and what will be if I use Navigraph Navdata?

Several issues happening. Just the main ones here:
- alignment is off at many airports
- ILS is not activating correctly on approach to addon airports
According to Asobo the new ILS editor will solve these and more issues (for addon airports)

[OSM 683]

13 minutes ago, Mir // Flightbeam said:

Several issues happening. Just the main ones here:
- alignment is off at many airports
- ILS is not activating correctly on approach to addon airports
According to Asobo the new ILS editor will solve these and more issues (for addon airports)

Did you test your addon airport without "custom ILS" and did you test airport with the Navigraph navdata?

Edited November 19, 2020 by OSM

[Mir // Flightbeam 541]

We haven't able to test yet since it has yet to be distributed to developers.

[OSM 683]

10 minutes ago, Mir // Flightbeam said:

We haven't able to test yet since it has yet to be distributed to developers.

Thank you for your answers! I am sure you will find a proper solution.

[Noel 4,503]

19 hours ago, Mir // Flightbeam said:

I recently saw a thread here regarding ILS issues at addon airports. So here is some quick clarification with facts:

- Yes, there is certainly some big ILS issues going on.
- It's caused by the SDK not allowing us to create custom ILS for our airports.
- The issue seems scattered among all airport devs. Asobo is very aware of the issue (for many.. many weeks)
- Asobo is responding by implementing a new custom ILS tool in the next SDK update, hopefully coming in the next week(s)
- I believe this will solve the issue once and for all.. unless it contains bugs as well.

Thanks for your attention

Great, does that mean ILS frequencies will be restored in the MFD Frequencies tab?  I noticed the 3 airports I bought inc FB KPDX are missing this data which leaves me 100% disinterested in buying any further 3rd party airports until this is solved.  Very good news.  NOW this question:  does this mean FlightBeam and all the others will need to issue updates to restore this functionality?

[regis9 4,014]

Thanks Mir, appreciated the info.

[virtuali 4,421]

7 hours ago, Noel said:

disinterested in buying any further 3rd party airports until this is solved.  Very good news.

Well, I can assure you our airports don't have this problem. I just made a quick test flight from KSEA to CYVR using the default A320, and after filling the flight plan on the world map to use 8L as destination, the ILS frequency was already pre-selected even before takeoff.

The are TWO changes from FSX/P3D ( which we have both fixed in our airports ) here, which might confuse developers, and are:

1) In FSX/P3D, if you redefine a runway and don't add any ILS, the simulator will just see the ILS from the default scenery. In FSX/P3D the problem ended there, because with default airplanes you *had* to tune ILS manually in any case, and with 3rd party airplanes, they might have their own internal database and FMC custom code, so they could offer an automatic tuning feature which wasn't otherwise supported by the sim. MSFS doesn't have any 3rd party airplanes with custom FMC yet, but has planes that DO offer automatic tuning and, it seems they cannot find an ILS, unless it comes WITH the runway. I think such ILS would still work when tuned manually, it's just the auto-tune that doesn't work if the ILS is coming from the default and not with the runway. 

It's not the SDK doesn't allow to create and ILS, because it surely does. It's the visual *Scenery Editor* that can't ( although we have been promised this will be fixed soon ) so, if you create a new runway with it, there's no way to add an ILS using the Scenery Editor. But editing the resulting XML code generated by the Scenery Editor manually, to add an ILS, seems to work just fine, it's just annoying, because you must find all lat/long coordinates of the localizer, glide and dme on a map, and eventually tweak them a bit to match your own custom scenery ground textures, but it works.

 

2) The ILS works, but it not well aligned. Issue #2 can be caused by to sub-issues:

A) Asobo used basically the same XML schema for the ILS from FSX but, without saying anything in the documentation ( maybe because ILS cannot be "officially" added yet ), it changed the meaning of the heading parameter. For many years, from FSX to P3D5, it meant as True heading, which makes sense, since the heading for the runway it's True ( and this hasn't changed ), now the heading is Magnetic, which is very confusing, since there's also a MagVar parameter, which doesn't make much sense, since you want to add True+MagVar to get a Magnetic Heading, if the heading is already Magnetic, the MagVar becomes useless, and perhaps this is exactly what is happening: the default instrumentation just reads the ILS heading, ignore the MagVar and considers it as Magnetic. All ILS in the default scenery are now magnetic and this affects the Auto-tune on the A320 as well, since on the A320 you cannot manually set an OBS course, and if that's wrong, the auto-pilot will screw up ( worse than it normally does... ).

I'm fairly sure of this because, in our initial release of CYVR, we assumed ( I'm sure many other scenery developers assumed the same ) the ILS heading was expressed like in FSX/P3D, and we didn't had any reason to think otherwise, since nowhere in the documentation you can find anything that would suggests that, so we set our ILS with True heading, and with of course the proper MagVar setting and...it didn't work very well, the ILS worked if you followed it manually, but the A320 auto-tuning tried to set the OBS to the True heading, and this caused the autopilot to fail entirely. At CYVR, with 17 degrees of variation, the problem was obvious, but it didn't show up if you were flying in a Cessna, where you are supposed to both tune manually AND set the OBS course manually too.

For example, 8L at CYVR is 100 degrees True, but with 17 degrees of variation, it reads 83 magnetic on the approach chart so, what used to happen in the initial release, is if you dialed the frequency manually, the OBS heading went to 100 instead of 83, so it couldn't auto-land ( not that it can *really* do a proper auto-land even when it works but, that's another issue ). Before CYVR we made Key West, which has no ILS, and before that we made KORD, but there the MagVar is just 3 degrees, so it's not *enough* to cause the auto-pilot to completely screw up, maybe it was a bit glitchy, but you didn't noticed as you did at CYVR.

So, we released an update, and the only thing we changed was setting the ILS to 83, and how all is well, the auto-tune picks it correctly, and 83 is set as the OBS heading automatically, and the auto-land is workable, although not as good as it should, but only because it doesn't flare correctly, not because of the ILS.

This tells me two things:

- It's 100% confirmed the ILS format has changed, at least when the heading is concerned, from True to Magnetic. I don't think it makes much sense because, when the magnetic variation changes over the years, if all headings were stored as True, it would have been enough to update just the magvar database, which is a fairly small file. Instead, by storing all headings as Magnetic, when the variation changes, you must update the *every single ILS in the world*. Well, Navigraph will be happy, at least...

- We CAN redefine the ILS in a scenery. If we couldn't ( eg., the sim was always reading the default one), we wouldn't be able to "screw up" in the first CYVR release, and we wouldn't be able to fix it with the update.

B) The previous one was one glaring difference which might explain misaligned ILS. But there's another one, and it might be due to differences between the aerial images used by the scenery and the way they are used in the sim.

If such images are used as what is called "Projected Mesh" in the SDK, which is a very fast way to allow custom backgrounds from FSX/P3D to be converted to MSFS, and it's what is allowing airports to be ported over fairly easy ( this single feature has saved the 3rd party airport market from having to throw away everything and wait months or even years to have some airports to sell ), those images, if used as they are, have an inherent projection error, meaning the conversion between meters in 3D Studio Max and lat/long coordinates in the sim is NOT 100% precise. No, it's not a big error, it's probably something like 10-20 meters at the most ( depending how big the airport is, for smaller airports is like 5 meters ), but on an ILS, it *might* be enough to have it slightly misaligned, especially if the developer placed its location "visually", basing on what he's seeing on the scenery, after having placed his custom background, possibly using antennas location as a reference. The problem is, that texture is NOT in the correct place. A special calibration procedure, made with annoying trial and error must be made, to be sure that a certain linear distance in 3DS Max gets converted in exactly the same way compared to a scenery element (like a runway, a parking *and* an ILS...) that is already inserted as Lat/Lon in the scenery XML source code. Without such calibration, they won't match, so the custom texture will be "almost" right, but not 100% right.

I'm not fully aware of what other developers use to align their sceneries, but we wrote our own custom plugin for 3DS Max which creates the "AFCAD" airport elements *and* the custom objects/polygons together, using the same coordinates system, and we use an extremely accurate formula to convert from Meters to Lat/Lon which use exactly the same ellipsoid model as MSFS 2020 with a precision of less than a thousand of a millimeter so, I can safely say we can place things quite accurately, and that has allowed to notice this error because, the *same* ground polygons, when they are exported as "just" polygons, don't end up exactly in the same place as when they use the "Projected Mesh" feature, which is some kind of MAGIC feature, that elegantly wraps all your custom polygons over a custom sloping terrain with no issues whatsoever of ground flickering, which was a great source of pain, especially in FSX. So, it's like magic, but it DOES have a slight error, and of course we found a procedure in 3DS Max to calibrate it to compensate the error, and put things exactly where they are supposed to be.

[marsman2020 1,310]

I'm curious - in the simulator, what does OBS course have to do with following an ILS? 

In real life it's just convenient visual reminder for the pilot, since the horizontal guidance represented by the localizer needle is determined completely by the physical orientation of the localizer beam and its two different frequency lobes.  There are no 'radials' on a localizer and adjusting the OBS doesn't change the needle deflection at all....

Maybe this is different in the sim? 

Edited November 21, 2020 by marsman2020

[Roman Design 344]

I'm facing the same ILS issue (missing ILS from TBM freqs screen) in the airport I'm making. Initially I excluded and redefined the runways and didn't exclude ILS, which is supposed to work. Then, trying this workaround, I got the default ILS XML and added it to my XML, redefining them like this. However the problem is still there, the freqs screen in TBM doesn't list those.

<Ils lon="-75.64169" lat="45.32659" alt="112.776" frequency="109.500" magvar="13.600" range="50017.000" backCourse="TRUE" heading="70.996" width="4.4" ident="IOW" name="ILS RW07">
			<GlideSlope lon="-75.66687" lat="45.31388" alt="112.776" range="50017.000" pitch="3.000" />
		</Ils>
		<Ils lon="-75.69139" lat="45.3297" alt="111.861" frequency="110.300" magvar="13.600" range="50017.000" backCourse="TRUE" heading="319.984" width="3.7" ident="IRP" name="ILS RW32">
			<GlideSlope lon="-75.65884" lat="45.31116" alt="111.861" range="50017.000" pitch="3.000" />
		</Ils>

My airport definition looks like this:

<DeleteAirport deleteAllApproaches="TRUE" deleteAllApronLights="FALSE" deleteAllAprons="TRUE" deleteAllArrivals="TRUE" deleteAllBlastFences="FALSE" deleteAllBoundaryFences="FALSE" deleteAllControlTowers="TRUE" deleteAllDepartures="TRUE" deleteAllFrequencies="TRUE" deleteAllHelipads="FALSE" deleteAllILSs="TRUE" deleteAllJetways="TRUE" deleteAllLightSupports="FALSE" deleteAllPaintedElements="TRUE" deleteAllRunways="TRUE" deleteAllStarts="TRUE" deleteAllTaxiways="TRUE" deleteAllTaxiwaySigns="TRUE" deleteAllTerminalNDBs="FALSE" deleteAllTerminalWaypoints="TRUE" />

Not sure what else to try, and why freqs are still missing...

[RaptyrOne 1,412]

This issue is prevalent on the scenery for FALE Durban King Shaka airport, South Africa. I purchased scenery from Gaffer Simulations (available in the Market Place and elsewhere) as the default airport was utter garbage, did not even have night lighting.

I have been unable to fly an ILS into this airport. I contacted the author and they advised that this is not something they can fix, all Asobo’s fault because of incorrect use of true vs magnetic.

If I read correctly what @virtuali is saying, this can actually be addressed with a work around. I have always found it odd that even freeware airports work fine, yet this payware airport ILS system is so broken.

[Farlis 2,287]

But if what Umberto found out about ILS now being magnetic heading instead of true plus magvar, then this needs to be fixed by ASOBO immidiately. 

It will turn into an absolute nightmare when the magnetic dev changes in the coming years.