FSDreamTeam forum
December 02, 2020, 08:49:29 PM *
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 1193 times)
virtuali
Administrator
Hero Member
*****
Posts: 40174



WWW
« Reply #15 on: October 20, 2020, 12:32:50 AM »

Quote
The localizers work correctly with the default airport.

I already provided some ideas why they might not work with an addon which, I'll repeat it again, has the CORRECT data.

As it is, the addon isn't useable as a destination.

It obviously is, just select the CRS manually. If the airplane automatically select the wrong one because it has decided to ignore the CORRECT Magvar the scenery is provided with, it's a bug of the airplane.

I'll repeat it again: do you think it's a sensible idea to purposely include WRONG data in the scenery, just because the sim has a bug that seems to ignore the ILS Magvar ? There are clearly issues with this, some developers are reporting to Asobo a CTD if the scenery includes ILS data, so they ARE looking into that.

If a solution ( or a workaround ) doesn't come up shortly, we MIGHT decide to do the wrong data on the scenery, just to overcome the simulator bug with those airplanes that set course automatically with no chance to change it ( which they should, since it's clearly possible in real life ).
Logged

BPieke
Newbie
*
Posts: 1


« Reply #16 on: October 20, 2020, 01:23:27 AM »

I also can report that not only is the Course off by 18 degrees, but the glideslope is off to the side.

This is flying a C172.. nothing "addon" there.

The original airport was correct, the addon airport incorrect..

Indeed, suggest you check with Asobo.. it makes your (otherwise nice) product look bad.
Logged
lonewulf47
Newbie
*
Posts: 30


« Reply #17 on: October 20, 2020, 05:25:27 AM »


...It obviously is, just select the CRS manually. If the airplane automatically select the wrong one because it has decided to ignore the CORRECT Magvar the scenery is provided with, it's a bug of the airplane.

Well, it should be clear by now that MSFS does NOT ALLOW to select a LOC course manually ! It's as simple as that. So with all MSFS aircraft using this standard feature it is simply not possible to change a course and therefore the airport at it's present state is not useable for ILS/LOC approaches. No problem with all other such as RNAV/RNP, as they are not ground based. I have reported this somewhat unpleasant feature as a bug to Zendesk long, long ago... Asobo simply copied it from Laminar's X-Plane but due to lack of any airmanship they thought that it was a good idea to make the figures rock steady  Grin

I should nevertheless add again that so far ALL OTHER AddOn airports (and I have lots of them, in fact all that are available at present, adding up to around 150) do not show this discrepancy. So, your assumption that only AddOn airports may be affected, may not be true. I'm presently checking with the SDK to find out what could be happening there. One idea might be that the MSFS database contains LOC data which are aligned to the magnetic bearing, which would be an unusual way. OTOH it would explain why the present LOC bearings are adding up the local variation -> +18° at CYVR, -4° at KORD.

Oskar
Logged
romoni
Newbie
*
Posts: 7


« Reply #18 on: October 20, 2020, 11:05:42 AM »

Quote
The localizers work correctly with the default airport.

I already provided some ideas why they might not work with an addon which, I'll repeat it again, has the CORRECT data.

As it is, the addon isn't useable as a destination.

It obviously is, just select the CRS manually. If the airplane automatically select the wrong one because it has decided to ignore the CORRECT Magvar the scenery is provided with, it's a bug of the airplane.

I'll repeat it again: do you think it's a sensible idea to purposely include WRONG data in the scenery, just because the sim has a bug that seems to ignore the ILS Magvar ? There are clearly issues with this, some developers are reporting to Asobo a CTD if the scenery includes ILS data, so they ARE looking into that.

If a solution ( or a workaround ) doesn't come up shortly, we MIGHT decide to do the wrong data on the scenery, just to overcome the simulator bug with those airplanes that set course automatically with no chance to change it ( which they should, since it's clearly possible in real life ).
Test this by Your self. Take a Cessna Caravan 208 with Garmin G1000 and see about what happening. Land to RWY 8L ILS 110.55 HDG 083° and explain to me that about how I set the Course to correct numbers.

Rolf
Logged
GeoNau
Newbie
*
Posts: 15


« Reply #19 on: October 20, 2020, 05:01:05 PM »

There definately seems something to be wrong on Asobo's end as you already know as the wrong course is set at f.e. the A320 where we can't change it.

But even if I use the default Cessna or Carenado's M20R where I can set freq. and course on my own the plane flies to the side of the runways, I'm not sure if it's a parallel course to the runway or just a wrong course to the localizer beacon (or however it's called) ... because, even if I continue with the M20R on that bogus 100 or so degree course for 08R MSFS will crash short before I have the start of the runway to my left. This happens with the A320 as well as with the M20R.

I'm wondering if it will be the same for you as well ... and maybe that explains why some report CTD when flying around your CYVR. For me it's like hitting some invisble wall or something like this.

And BTW, even the default A320 works perfectly fine with the default CYVR, even although it still has the same preset 100° ILS course:



* Default CYVR Default A320.jpg (236.19 KB, 1920x1080 - viewed 46 times.)
« Last Edit: October 20, 2020, 05:42:38 PM by GeoNau » Logged
lonewulf47
Newbie
*
Posts: 30


« Reply #20 on: October 20, 2020, 05:14:36 PM »

After analyzing the respective BGLs I see that there is no solution to this problem, as long as FSDT and MS/Asobo cannot decide on a common line. The main problem stems from the fact, that FSDT uses its own ILS data (=airport records) although all such data is available in the basic dataset (which of course should be complete as it is derived from the NavBlue ARINC file). The basic idea of MSFS was to use the standard (updateable) AIRAC datacylce provided by NavBlue. Therefore no airport designer needs to add his own airport records. This rule must of course be set apart if an airport is NOT contained in the standard Airac cycle (a prominent example for this would be EDDS Stuttgart).

We as the users are now confronted with the by far not ideal situation that (again like in FSX/P3D) airport designers continue to use their own data outside the regular AIRAC updates. As it seems MSFS prioritizes the airport record used by the AddOn over the main Navdatabase. Furthermore there is obviously a miscalculation regarding Variation leading to the result we all are faced with. It should also be noted that using such Navdata which are already available in the main Navadtabase undermines the basic concept of MSFS having ONE COMMON Navdatabase. In that respect Laminar's X-Plane is managing this basic concept in a perfect manner and I do not see any reason why this should not be maintained throughout MSFS!

There is actually only one conclusion for me: FSDT Airports are not considered useable as long as this discrepancy exists. Who is actually resonsible for this chaos is difficult to determine. In any case any AddOn developers using again (like in the old FSX/P3D days) their own airport records outside the regular AIRAC cycle are a no-go for me. To have a simple solution for this "problem", it could be adviseable that FSDT offers an ALTERNATIVE installer WITHOUT own airport records (aka ILS DATA among other data). This would also again offer the possibility that changes within the ILS data can (again) regularly be updated by future AIRAC updates. All said here also applies to KORD Chicago, althoug there the LOC offset is "ony" in the magnitude of 4°...

Oskar
« Last Edit: October 21, 2020, 03:01:34 AM by lonewulf47 » Logged
GeoNau
Newbie
*
Posts: 15


« Reply #21 on: October 20, 2020, 05:39:41 PM »

I just want to add something regarding the CTD. I was just doing the same approach to 08R with the A320NX latest development mod and default CYVR.

The A320 was still on the correct 83° course onto 08R but MSFS crashed to desktop when I still was 500ft above the runway, still perfectly lined up with the runway so the CTD might not simply due to the installed FSDT CYVR (it just happened with the default CYVR).

Maybe it only happens with installed aircrafts/mods (my other 2 CTD have been with the Carenado M20R).
Logged
Michael2
Newbie
*
Posts: 18


« Reply #22 on: October 20, 2020, 06:43:39 PM »

" It obviously is, just select the CRS manually. If the airplane automatically select the wrong one because it has decided to ignore the CORRECT Magvar the scenery is provided with, it's a bug of the airplane."

My post indicated that I am using an addon aircraft I am developing.  It's an L1011 which has no nav database and does not auto select a course.  I set the course and frequency manually.  When I tried to land on 8R (the only runway I tried) using the autopilot approach hold, the aircraft appeared to fly the correct course parallel to the actual runway path, but laterally offset.  Again, it works OK with the default airport.

There is an assumption throughout the thread the the problem is related to magnetic declination -- could it not be the location of the localizer transmitters?

I will try to look at it again when able, I have my hands pretty full with the aircraft development.

I should add that when flying the parallel course, the HSI needle shows the aircraft is well to the right of the correct path.  But the autopilot seems not to think so.
« Last Edit: October 20, 2020, 07:21:36 PM by Michael2 » Logged
GeoNau
Newbie
*
Posts: 15


« Reply #23 on: October 20, 2020, 07:40:35 PM »

FWIW I'm just trying the payware addon for Kelowna CYLW, which has a 16°E variant and it works perfectly fine with the FlyByWire A32NX. Even although the MCDU has a fixed 175° course for ILS16's 159° runway the plane is perfectly lined up.

The MFD also shows a course of 159° even although the MCDU has 175, contrary to CYVR where MCDU AND MFD has the 100° for 08R.

So whatever they did, it works and it can be done.

Logged
Manny
Jr. Member
**
Posts: 53


« Reply #24 on: October 20, 2020, 07:47:40 PM »

Runway ILS 26L is a different issue. My heading seem right on the A320. I am parallel to the runway way to the right almost over the Terminal building

https://ibb.co/tHFRd61
I don't think so. Unfortunately your screenshot is of no great value as there is no view to the PFD and ND. For proper judgement the view to the instruments is essential.

Oskar

OK..so take an aircraft and fly the ILS 26L yourself and see.
Logged
lonewulf47
Newbie
*
Posts: 30


« Reply #25 on: October 21, 2020, 03:12:32 AM »

OK..so take an aircraft and fly the ILS 26L yourself and see.
No, and I hate to say that: after having flown Airbuses in real life for many thousand hours (totalling some +20'000 hrs...) it might be quite understandable that I will keep my fingers far off anything that looks like an Airbus, as long as it is based on MSFS default aircraft... Cheesy Cheesy I would feel like being tortured... Wink

Apart form that I have flown all 5 ILSes at CYVR to make sure the same error exists in the complete installation.

Oskar
« Last Edit: October 21, 2020, 03:16:24 AM by lonewulf47 » Logged
GeoNau
Newbie
*
Posts: 15


« Reply #26 on: October 21, 2020, 05:33:42 PM »

Quote
The localizers work correctly with the default airport.

I already provided some ideas why they might not work with an addon which, I'll repeat it again, has the CORRECT data.

As it is, the addon isn't useable as a destination.

It obviously is, just select the CRS manually. If the airplane automatically select the wrong one because it has decided to ignore the CORRECT Magvar the scenery is provided with, it's a bug of the airplane.

I'll repeat it again: do you think it's a sensible idea to purposely include WRONG data in the scenery, just because the sim has a bug that seems to ignore the ILS Magvar ? There are clearly issues with this, some developers are reporting to Asobo a CTD if the scenery includes ILS data, so they ARE looking into that.

If a solution ( or a workaround ) doesn't come up shortly, we MIGHT decide to do the wrong data on the scenery, just to overcome the simulator bug with those airplanes that set course automatically with no chance to change it ( which they should, since it's clearly possible in real life ).

Correct data or not, your scenery does NOT work, not even with a default Cessna where we CAN set freq. and course on our own.

How about a scenery that does work ... how did you test you scenery if it works Huh
Logged
jcallum
Newbie
*
Posts: 13


« Reply #27 on: October 21, 2020, 11:27:52 PM »

I had this problem flying the Bonanza A36 into ils 11. Was not able to adjust the course. Was about 20 degrees off course. Has not happened at any other airports.

John.
Logged
earnorbust
Jr. Member
**
Posts: 56


« Reply #28 on: October 22, 2020, 03:58:05 PM »

But still I would be interested in an explanation as to why on all other aiports (e.g. also Asobos own KJFK) the LOC Courses are depicted correctly.

I already offered some possible explanations:
There might be several explanations:

- The bug might only happen in add-on airports

- The default ILS database might not include Magvar in ILS and the airplane might use just the Magvar of the *airport* and assume it's the same for all ILS ( a reasonable assumption, yet the .BGL format requires to have Magvar for individual ILS too )

- Some add-on developer decided to purposely set the Magvar to 0. I believe we had 0 at KORD, but the Magvar there is very small ( I think it's 3 deg or so ), so you might not notice a problem like at CYVR.

But we'll surely ask Asobo about this. I really don't feel comfortable feeding wrong data on purpose, just to overcome a simulator bug that might be fixed at any time.

I informed FSTramp and asked them, if they had a program bug, because their ILS paths to Vancouver airport didn't show correctly on their map . They answered:

“FSTramp shows the ILS as it is contained in the scenery. The author of the scenery has probably not understood that the direction of the ILS is a true heading for FSX, but the magnetic heading for MSFS. That makes a difference of 18 degrees in CYVR.“

Maybe this is the problem?!
Logged
virtuali
Administrator
Hero Member
*****
Posts: 40174



WWW
« Reply #29 on: October 22, 2020, 10:43:11 PM »

“FSTramp shows the ILS as it is contained in the scenery. The author of the scenery has probably not understood that the direction of the ILS is a true heading for FSX, but the magnetic heading for MSFS. That makes a difference of 18 degrees in CYVR.“

It's possible. Asobo might have decided to change a standard that hasn't changed since FSX, with no indication of that anywhere in the SDK. The thing that doesn't make any sense is:

- The ILS data file has two separate records for an ILS: heading and MagVar. Both are flagged as MANDATORY, the compiler won't even compile the scenery if you don't supply both.

So, what's would be the point of requiring *both* Heading and a MagVar, other than implying the Heading is meant to be True ?

So, I'm still convinced this is a bug, and FsTramp author is probably assuming the rule has changed, so he adapted is program to the bug. Want some proof ? See a post he made on MSFS forum back in March, during the Alpha ( FsNav user IS FsTramp author, you can see it in his profile )

https://forums.flightsimulator.com/t/all-ils-have-wrong-heading/49029

Of course, back then he was entirely right saying the simulator had a bug if the default files really stored the headings as Magnetic:

Quote
The heading value in the BGL files is the magnetic heading. But this is wrong and does not correspond to the standard of FSX. All ILS heading must be entered as true heading

The are so many reasons why it doesn't make any sense to have Magnetic headings in the scenery database:

- The runways (and everything else that has an heading) use True heading too. This make it easier to align ILS and Runway, if they are supposed to be aligned. The only place in which you can choose to use True or Magnetic are the Approaches section.

- The Magnetic variation changes over time, if you store the headings as True ( as you should ), it would be enough to just update the MagVar .BGL, and all headings readout will now match current charts automatically, worldwide. Instead, by storing ILS data as Magnetic, when something change, you must update each and every .BGL for each and every airport that was affected.

- It defies the purpose of having a MagVar record for both the airport and the ILS.

So, what is probably happening here, is FsTramp author must have been frustrated the bug he reported hasn't been fixed, and the default ILS database is all Magnetic now, so he adapted his code to get around to it.

No problem, we can do the same, at least it would work until we'll get a clear answer from Asobo about this and if it's expected to change in the future.
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!