LOC Courses at CYVR (MSFS) are misaligned **SOLVED**

[earnorbust]

FSTramp gave me a clearer answer later on: In the BGL files of FSX the numerical value for the direction of the ILS is given as true heading. Asobo changed this by mistake, in the BGL files of MSFS magnetic heading is used.

Hope that helps you guys.

[virtuali]

Asobo changed this by mistake, in the BGL files of MSFS magnetic heading is used.

That's what I said: it's not as if we don't "understand" how the ILS *should* work, it's just that Asobo didn't fixed what he rightly reported as a bug so, in order to have his map showing the correct data, he decided to play along with it.

So yes, it's a very easy fix to do to change the scenery, it's just wrong, and we hope they'll fix it, because it doesn't make any sense.

[Michael2]

From my perspective, I would just like it to work.  Suppose Asobo does nothing?

[virtuali]

From my perspective, I would just like it to work.  Suppose Asobo does nothing?

I already confirmed we'll DO the change...it's just we are finishing a huge update, that will bring CYVR 100% updated to the current airport.

[Michael2]

OK, thank you. 

[earnorbust]

I just purchased your airport Chicago O'Hare (KORD) in MSFS "Market Place" and checked the ILS-binding. The binding is correct!
So, the one thing I don't understand is, why is the ILS runway-binding in your product KORD correct - but not in your product CYVR !?   

[virtuali]

I just purchased your airport Chicago O'Hare (KORD) in MSFS "Market Place" and checked the ILS-binding. The binding is correct! So, the one thing I don't understand is, why is the ILS runway-binding in your product KORD correct - but not in your product CYVR !?   

Have you read this thread ? It provides plenty of information about this, the ILS in CYVR has always been *CORRECT*, perfectly aligned with the runway True heading, and with the correct indication of the Magnetic variation.

One would assume ( and it has been like this since FSX and all versions of P3D ) the reason why you have a separate (non optional ) MagVar field in the ILS means its Heading is meant to be True, otherwise it wouldn't be required to use the MagVar. This made a sense for plenty of reasons, with the most obvious being that, when during the years the MagVar changes, if you have all the ILS in the database stored as True heading, it would be enough to update the small single .BGL with the updated Magar. Instead, if you store the headings as Magnetic, when the variations changes, you'll have to update all thousands of .BGLs containing ILS that might have been affected. That's why both FSX and P3D used that method, because it made sense.

It seems the default MSFS database contains ILS with Magnetic heading instead, even if nowhere in the SDK documentation it says that. In fact, there's NO documentation at all to create ILS, and the included Scenery Editor doesn't even allow to add an ILS so, the general rule so far has been that, when there's no documentation, the SDK says you can refer to the FSX ( or ESP, which is the latest SDK published by Microsoft before MSFS ), assuming nothing has changed. So, we followed that rule, without having any reason to suspect they changed it, and I'm not even sure the change was intended, it can possibly be a bug.

In fact, this bug has been reported to Microsoft during the Alpha by FsTramp author ( I linked a post of his in a previous post ), in which he also said storing the ILS heading as Magnetic is wrong and it's a bug but, apparently, since it hasn't changed, he probably updated his software to take that into account.

And yes, there's same "problem" at KORD, but the Magnetic variation there is way smaller than CYVR ( 3.5 compare to 17 ), so it's not enough to cause the autopilot to miss the approach because the CRS is not exactly matching the ILS heading.

We'll obviously "fix" both sceneries, since we asked Asobo about this, but haven't got a reply so far. I'll keep using double quotes for fix, since I firmly believe storing the ILS headings as Magnetic, with the runway heading still in True, is at the very least weird, but if this is what's required to make the default autopilot happy, so be it.

Note that, the problem is only a problem for those planes in which you cannot manually set the CRS. The default C172 with the analog instrumentation works just fine as it is now, because there you always set the CRS manually.

[lonewulf47]

I already confirmed we'll DO the change...it's just we are finishing a huge update, that will bring CYVR 100% updated to the current airport.

Could you be a bit more specific as to what change you intend to introduce? Will you change the bearings (not a good idea, because Asobo ULTIMATELY NEEDS to correct this bug) or will you just delete your own airport records (which would be more reasonable as they don't need to be in an airport BGL a long as they exist in the standard Navdatabase). This would also relieve you from constanty checking your airport records against any changes in ILS frequencies... This would also be interesting for me personally as I have altered (for my private use only of course) the bearings in the airport BGL.

Oskar

[virtuali]

Could you be a bit more specific as to what change you intend to introduce? Will you change the bearings (not a good idea, because Asobo ULTIMATELY NEEDS to correct this bug) or will you just delete your own airport records (which would be more reasonable as they don't need to be in an airport BGL a long as they exist in the standard Navdatabase).

We don't have much choice other than set the heading as Magnetic. The whole issue is the auto-tune CRS is wrong but ( and this HAS been confirmed by Asobo ), if we don't attach an ILS to a runway, the auto-tune won't work at all, it won't even find the ILS.

[GeoNau]

Note that, the problem is only a problem for those planes in which you cannot manually set the CRS. The default C172 with the analog instrumentation works just fine as it is now, because there you always set the CRS manually.

This is NOT correct, not sure if you have read our other posts but it also DOES NOT WORK with the default C172. See the attached picture, I would not call this working correctly.

The needles are correct but the autopilot will not follow the needles as you can see .. and BTW, that picture is taken at the point where some seconds later MSFS will crash every time (at least for me).

[lonewulf47]

We don't have much choice other than set the heading as Magnetic. The whole issue is the auto-tune CRS is wrong but ( and this HAS been confirmed by Asobo ), if we don't attach an ILS to a runway, the auto-tune won't work at all, it won't even find the ILS.

Sorry Umberto, may I ask you where you REALLY got this information from? Did you ever check what you are publishing here? There are already quite a number (many dozens at least if not already over 100) of airports around which do NOT have airport records in their airport BGLs. None of them show what you are publishing here. If you don't include the ILSes in the aiport records, then MSFS simply uses the data from the standard Navdatabase. I still can tune ANY ILS in ANY other AddOn airport. This statement is simply not true and you could verify it instantly by doing a respective trial.

Oskar

[virtuali]

Sorry Umberto, may I ask you where you REALLY got this information from? Did you ever check what you are publishing here?

There's a restricted developer forum on the MS Forum in which we can ask things to Asobo directly. There, Ricardo from LatinVFR asked why many customers couldn't auto-tune their ILS, which he hasn't touched or added, and an Asobo developer replied with the following:

you have two solutions to solve your issue:

1 Don’t override runway, and use default runway

2 Modify the xml to add ILS data

So, he likely re-defined the runway, but didn't add the ILS record, and that resulted in failing auto-tune, which Asobo confirmed to be an issue.

There are already quite a number (many dozens at least if not already over 100) of airports around which do NOT have airport records in their airport BGLs. None of them show what you are publishing here.

Did ALL these airport without ILS had a runway too ? See the above reply, if you don't redefine the runway, the default ILS will work. We had to redefine the runway, because CYVR has custom Canadian-style number and markings, so we choose solution 2, assuming the heading format was True, as it should be.

[virtuali]

This is NOT correct, not sure if you have read our other posts but it also DOES NOT WORK with the default C172. See the attached picture, I would not call this working correctly. The needles are correct but the autopilot will not follow the needles as you can see .. and BTW, that picture is taken at the point where some seconds later MSFS will crash every time (at least for me).

Which confirms exactly what I said: the needles ARE CORRECT, hence the ILS IS correct, because if you hand-fly the approach and the the CRS manually, it will work perfectly. The problem is the autopilot code in the sim, which seems to ignore the MagVar, only relies on the Heading, which it assumes to be Magnetic instead of True.

[lonewulf47]

Did ALL these airport without ILS had a runway too ? See the above reply, if you don't redefine the runway, the default ILS will work. We had to redefine the runway, because CYVR has custom Canadian-style number and markings, so we choose solution 2, assuming the heading format was True, as it should be.

There are a  few renowned (without mentioning a name) Developers with the same quality level as FSDT which do not use own Airport records. Whether they use redefined runways or "just" resurfaced is not easily detectable by the user. In any case the runways look exactly the way the aerials in Google or Bing Maps show including Markings and Numbers. So, whether a RWY needs to be redefined or not is of course the Developer's choice. It seems however that resurfacing with correct numbers (31 iso 30 ) seems a possible solution. I'm not into airport design, but I'm strongly related to the field of Aerial Navigation. I therefore am not happy when Airport Designers use their own Airport Records. This contradicts the original concept (by Asobo/MS) to have ONE common updateable Navigation Database. Laminar's X-Plane is a perfect example for this. There's just ONE database for all with no exception. Everything else is weakening this concept and leads to the unpleasant fact that changes within the ARINC dataset will not automatically show up on such airports but need to be updated by the Dev. Even more so as we have the chance by now to REALLY have regular updates available by Navigraph (still in beta).

One of the main troubles with MS/Asobo is that obvioulsy noone of their staff has thorough knowledge of Aerial Navigation. This is among other things easily visible if your look at the way they are parsing ARINC data. Someone there had the brilliant idea to generally aligning LOC bearings to the RWY QFU, without ever considering the fact that there are airports with LOC offsets for various reasons. This is far below what I consider professional data handling. At least thanks to the Navigraph (beta) update those errors are corrected and the LOC offsets are back to where they belong. Asobo's idea however to use MAGNETIC Bearings for LOCs ist outstandingly stupid. I don't think that this can be corrected so easily if ever. One more proof of what I said above about Aerial Navigation Knowledge of Asobo's Staff...

Oskar

[earnorbust]

@Lonewolf47: To help the MSFS community, you should send your last thread to Asobo support !!