FSDreamTeam forum
December 02, 2020, 08:56:32 AM *
Welcome, Guest. Please login or register.

Login with username, password and session length
News:
 
   Home   Help Login Register  
Pages: 1 2 [3] 4
  Print  
Author Topic: LOC Courses at CYVR (MSFS) are misaligned **SOLVED**  (Read 1191 times)
earnorbust
Jr. Member
**
Posts: 55


« Reply #30 on: October 22, 2020, 10:54:10 PM »

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.
Logged
virtuali
Administrator
Hero Member
*****
Posts: 40166



WWW
« Reply #31 on: October 22, 2020, 11:02:43 PM »

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.
Logged

Michael2
Newbie
*
Posts: 18


« Reply #32 on: October 23, 2020, 01:33:02 AM »

From my perspective, I would just like it to work.  Suppose Asobo does nothing?
Logged
virtuali
Administrator
Hero Member
*****
Posts: 40166



WWW
« Reply #33 on: October 23, 2020, 05:29:01 AM »

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.
Logged

Michael2
Newbie
*
Posts: 18


« Reply #34 on: October 23, 2020, 05:42:00 AM »

OK, thank you. 
Logged
earnorbust
Jr. Member
**
Posts: 55


« Reply #35 on: October 23, 2020, 10:08:40 AM »

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 !?  Huh  Huh
Logged
virtuali
Administrator
Hero Member
*****
Posts: 40166



WWW
« Reply #36 on: October 23, 2020, 12:58:37 PM »

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 !?  Huh  Huh

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.
Logged

lonewulf47
Newbie
*
Posts: 30


« Reply #37 on: October 23, 2020, 01:39:11 PM »

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... Smiley 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
« Last Edit: October 23, 2020, 01:42:56 PM by lonewulf47 » Logged
virtuali
Administrator
Hero Member
*****
Posts: 40166



WWW
« Reply #38 on: October 23, 2020, 01:46:25 PM »

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.
Logged

GeoNau
Newbie
*
Posts: 15


« Reply #39 on: October 23, 2020, 02:08:26 PM »

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).


* 2020-10-23_140314.jpg (465.88 KB, 1920x1080 - viewed 15 times.)
Logged
lonewulf47
Newbie
*
Posts: 30


« Reply #40 on: October 23, 2020, 03:11:28 PM »

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
Logged
virtuali
Administrator
Hero Member
*****
Posts: 40166



WWW
« Reply #41 on: October 23, 2020, 06:25:28 PM »

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:

Quote
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.

Quote
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.
« Last Edit: October 23, 2020, 06:30:32 PM by virtuali » Logged

virtuali
Administrator
Hero Member
*****
Posts: 40166



WWW
« Reply #42 on: October 23, 2020, 06:25:46 PM »

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.
« Last Edit: October 23, 2020, 06:29:06 PM by virtuali » Logged

lonewulf47
Newbie
*
Posts: 30


« Reply #43 on: October 24, 2020, 01:02:05 PM »

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 Wink ) 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
« Last Edit: October 24, 2020, 10:37:11 PM by lonewulf47 » Logged
earnorbust
Jr. Member
**
Posts: 55


« Reply #44 on: October 24, 2020, 06:09:43 PM »

@Lonewolf47: To help the MSFS community, you should send your last thread to Asobo support !! Wink
« Last Edit: October 25, 2020, 12:17:01 AM by earnorbust » Logged
Pages: 1 2 [3] 4
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Valid XHTML 1.0! Valid CSS!