FSDreamTeam forum
Products Support => Vancouver CYVR support MSFS => Topic started by: lonewulf47 on October 16, 2020, 09:22:51 pm
-
You might want to check variation used on the MSFS version of CYVR. I have no clue as to how variation and ILS Courses are connected (usually in other Sims LOC Courses are magnetic, here they seem to be true and added up with variation) Therefore all LOC bearings are misaligned by 18°. To clarify: the automatically selected LOC inbd courses (this very special feature of MFS, similar to X-Plane) are off by 18°. Must be connected somehow with variation. On the MSFS default airport LOC bearings are correct.
Regards
Oskar
-
+1
Running FSDT Live Update not helped.
Rolf
-
Same here actual localizers courses 26L or 26R is 263' but the localizer course showing on the PFD is 280' .... very weard when braking out of cloud no wind with good crosswind !
-
I just flew to CYVR ILS 26L and I was placed on a course like 100 feet or so to the right of the runway line.
-
Just to make it clear: this is how it looks e.g. on RWY 08L: RWY QFE is 082°, ILS (auto-) course is 100° !
-
The ILS in the scenery are surely correct, meaning:
They are inserted using True heading, as they should, with the correct indication of the Magvar. For example, RWY 8L is about 100° Deg True with -18° of Magvar for the area results in a reading of 82° on the instruments.
If the readout on the instrument needles is correct ( and it surely is ), the problem here is ONLY the wrong course automatically set by the instrument, which seems to indicate a bug in the sim ( or the instrument code ) of not taking into account the Magvar which IS correctly set in the scenery ( otherwise the needle would be wrong too ) when automatically set the CRS.
It's *possible* there's a bug in the sim not taking into account the Magvar, but I think we should stick to set the ILS correctly, meaning the heading is set to True, and the Magvar is set because, if we tried to be smart and "fix" the error, by setting the ILS to its Magnetic course and the Magvar to 0, the following will happen:
- Asobo might fix the bug in the meantime, resulting to a wrong readout.
- The Magvar might change with an update, and the readout would be again wrong.
So, I think having to check the CRS to be correct and not relying on the automatic selection is probably the best choice right now, better than purposely set the ILS wrong in the scenery to make the instrumentation happy.
-
Edit: I must stand correct: FSDT's KORD is affected by the same, but as the MAGVAR is only 4°, the error is not so obvious. IMHO this looks like design flaw, but maybe there's another explanation why all other airports are showing correct LOC inbound courses.
Clearly confirming there's a bug in the sim. If we wanted to "fix" a problem we don't have in the first place, we should have set the ILS with its heading as Magnetic and always set Magvar at 0, which is clearly against the specs since:
- Heading for an ILS is considered to True
- MagVar is a separate parameter and it's not optional
-
+1
-
Well, you might certainly also have an explanation why the LOC COURSES ARE CORRECTON ALL OTHER AIRPORTS, even when using the Asobo/MS default CYVR airport.
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.
The term "...and not relying on the automatic selection" is really a fantastic contribution to the problem. You are probably not aware of the fact that there is NO POSSIBILITY to change the inbound course manually, once you have selected the correct frequency.
Which airplane are you referring to ? If you can change the CRS on an airplane, but you cannot on another one, that's something specific for that airplane, and I'd say it's also a bug that should be fixed, since manual selection of the CRS is always possible in real life, even when the plane usually sets it automatically. Of course, the automatic selection should work in the first place and, again, this is not a scenery problem, rather the airplane code that is IGNORING an information which is PRESENT in the scenery.
I'll repeat it again, this is how CYVR ILS 8L is set in the scenery:
- True Heading 100°
- Magvar -18°
Which part of this data you find unrealistic or wrong ?
-
Which airplane are you referring to ? If you can change the CRS on an airplane, but you cannot on another one, that's something specific for that airplane, and I'd say it's also a bug that should be fixed, since manual selection of the CRS is always possible in real life, even when the plane usually sets it automatically. Of course, the automatic selection should work in the first place and, again, this is not a scenery problem, rather the airplane code that is IGNORING an information which is PRESENT in the scenery.
Well, the above is of course not a FSDT issue, as this is a design flaw of MSFS. They tried to coypy X-Plane in that respect, but kept the Auto-LOC course fixed without a possibility to change it. There is nothig wrong in your mentioned data, just the outcome that shows the LOC course at 100° MAG.
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.
-
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.
-
Ok then, let's wait for the outcome. For me at this stage of course CYVR is not useable for full IFR Approaches with a LOC standoff of 18°. Maybe someone in the whole MSFS theatre will come up with a solution. As for KORD: it is exactly the same issue, but - as you mentioned - the MagVar is only around -4° (-3.8W), the standoff is not so easily detectable, but still there.
-
I just flew to CYVR ILS 26L and I was placed on a course like 100 feet or so to the right of the runway line.
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
-
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
-
The localizers work correctly with the default airport. I am using an aircraft I am developing and I am manually setting the course and tuning the frequency, if that is any help.
As it is, the addon isn't useable as a destination.
-
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 ).
-
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.
-
...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 ;D
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
-
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
-
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:
-
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
-
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).
-
" 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.
-
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.
-
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.
-
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... :D :D I would feel like being tortured... ;)
Apart form that I have flown all 5 ILSes at CYVR to make sure the same error exists in the complete installation.
Oskar
-
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 ???
-
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.
-
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?!
-
“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:
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.
-
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.
-
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.
-
From my perspective, I would just like it to work. Suppose Asobo does nothing?
-
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.
-
OK, thank you.
-
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 !? ??? ???
-
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.
-
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
-
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.
-
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).
-
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
-
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.
-
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.
-
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
-
@Lonewolf47: To help the MSFS community, you should send your last thread to Asobo support !! ;)
-
@Lonewolf47: To help the MSFS community, you should send your last thread to Asobo support !! ;)
You bet I did !! :D ;D
-
I as a customer don't care who is wrong and who did what correct.
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.
With your scenery uninstalled needles and autopilot works, with your scenery installed only the needles do work ! You clearly never fully tested your scenery before you released it !
This thread got started over a week ago and you are still arguing you did nothing wrong (maybe you are correct, but as of now it's still not fully working) ... other developers were able to fix issues within a couple of hours and all it took me was a single post on their Facebook page !
-
With your scenery uninstalled needles and autopilot works, with your scenery installed only the needles do work ! You clearly never fully tested your scenery before you released it !
This thread got started over a week ago and you are still arguing you did nothing wrong (maybe you are correct, but as of now it's still not fully working) ... other developers were able to fix issues within a couple of hours and all it took me was a single post on their Facebook page !
Hi,
If you run the FSDT Updater, the CYVR and KORD sceneries seem to be updated to the correct standard by now. I tested the ILS'es for proper function and they are all correct. So, for me as OP everything is now perfect in this respect. For me personally it revealed a rather unpleasant side of MS/Asobo, as it became obvious that the original concept of having ONE database for the whole simluator is kinda outperformed by themselves by using an incorrect data format for this important part and it is not sure whether this will ever be corrected. Let's hope for some better qualified people at MSAsobo in this resepct.
Oskar
-
I uninstalled, reinstalled, ran the update. I don't see any difference. The autopilot still puts me in the Fraser. Surely if this was fixed, it would be announced here?
-
It's still not working for me either, I even removed everything out of my community folder except the 3 FSDT sceneries and I also did not get any updates when running the updater.
-
I have flown 3 different ILS apporaches (08R, 13, 26R) and all showed correct behaviour, including correct auto-bearing in the G1000. The C172 with conventional instruments seems to have a bug in the A/P system. It was not able to track the ILS and veered off course. This was however only with the C172 with conventional instruments.
-
I have flown 3 different ILS apporaches (08R, 13, 26R) and all showed correct behaviour, including correct auto-bearing in the G1000. The C172 with conventional instruments seems to have a bug in the A/P system. It was not able to track the ILS and veered off course. This was however only with the C172 with conventional instruments.
Which plane(s) did you try ? Even the default C172 with the G1000 has the same issues for me.
Also, I noticed something else wich is rather strange. If I select 26R for the departure I get placed at 08R but again, only if FSDT CYVR is installed.
-
There are a few renowned (without mentioning a name) Developers with the same quality level as FSDT which do not use own Airport records.
Maybe you wanted to say "Runway record", rather than "Airport record" because, according to the .BGL standard ( and this is valid and unchanged from FSX to MSFS 2020 ), almost *everything* related to an airport is inside the Airport record, parking spots, taxiways, paths, aprons, etc. So no, it's impossible to make a custom airport without redefining the airport record, and every developer, regardless of its "quality level" will surely redefined it.
The thing that contains the ILS is the *Runway* record ( which is itself a *child* of the Airport record ), and I think I explained quite clearly why we redefined: to have custom textures, with custom Canadian-style runway numbers and markings, which are not possible to do without redefining the runway record and, as I've said already, quoting information that arrived directly from Asobo, if you don't attach the ILS to a redefined runway record, the auto-tune won't just set the wrong heading, it will just not work.
It's possible you haven't seen many 3rd party airports in *MSFS* that redefined the runway record, because maybe they felt they didn't had to customize the runway aspect OR they were located in a place where the Magvar is so small that won't be enough to cause a problem to the autopilot.
In any case, the problem is now history, since we changed the ILS to use MagVar in yesterday's update. Of course, I still think storing the ILS in magnetic is wrong, for all the obvious reasons I already discussed but, if that's how the sim works now, we can only comply...
-
Just tried the update with the A320NX mod, no issues for 08R anymore, also no CTD.
Just one oddity, if I select 26R for the departure I still get placed at 26L.
-
Maybe you wanted to say "Runway record", rather than "Airport record" because, according to the .BGL standard ( and this is valid and unchanged from FSX to MSFS 2020 ), almost *everything* related to an airport is inside the Airport record, parking spots, taxiways, paths, aprons, etc. So no, it's impossible to make a custom airport without redefining the airport record, and every developer, regardless of its "quality level" will surely redefined it....
....
and thus smash the (basically perfect) priciple of having one common database to pieces... I really love that outlook... Nevertheless FSDT so far is the only Add-On designer using that. So far I have checked almost all of my 100+ AddOn airport BGLs for this Runway Record (you're right) and didn't find one single Designer using it. I keep an eye on that issue on all my new AddOn installs. No further discussion needed on this. Thanks for solving the problem on CYVR.
Oskar
-
Nevertheless FSDT so far is the only Add-On designer using that. So far I have checked almost all of my 100+ AddOn airport BGLs for this Runway Record (you're right) and didn't find one single Designer using it.
I don't think so, redefining the runway record is extremely common, and it's *required* if the developer wanted to use custom runway textures or custom runway markings.
I checked a random scenery I had, FlyTampa EKCH and, by decompiling the AF2_EKCH_FSX_ne.BGL file into XML using the BGL2XML utility, it's easy to see it HAS redefined the runway record, by replacing the default runways with runways without any markings ( all markings are set to "False" so no, I'm not looking at stock data here ), which allows to add their own. As I've said, a very common method basically *everybody* use to create custom runway textures.
FlyTampa only redefined the Runway record, without attaching an ILS because, as I also said, in FSX/P3D this wasn't an issue, since there's no "auto-tune" feature anyway, and neither the default autopilot sets the CRS automatically on its own but, as I've said ( twice ), Asobo directly confirmed if you want to have a runway with custom textures ( so you MUST have a Runway record to do that ), you MUST also include the ILS record, otherwise the auto-tune will not work at all.
-
I checked a random scenery I had, FlyTampa EKCH and, by decompiling the AF2_EKCH_FSX_ne.BGL file into XML using the BGL2XML utility, it's easy to see it HAS redefined the runway record, by replacing the default runways with runways without any markings ( all markings are set to "False" so no, I'm not looking at stock data here ), which allows to add their own. As I've said, a very common method basically *everybody* use to create custom runway textures....
You might have noticed that I was uniquely referring to MSFS AddOn airports. Believe me, I'm well aware of the systematics used in FSX/P3D, where RWY records were ALWAYS included in the AFCAD.BGLs, especially also in all default aiports. You might also have noticed that in MSFS the default aiports DO NOT have RWY records containing navaid such as LOC/ILS etc. These are - for the reason I can't stop pointing to - all collected in the AFXnnnn.BGLs, and thus updateable by either an MSFS update or replaceable by a third party Navdatabase by just transferring limited data. Look it as you like, it's just not a smashing idea to tear the updateable standard Navdatabase apart. It's after all not user friendly. You have of course the tool to update all your airports whenever an item of the RWY record will undergo a change within an AIRAC cycle. I hope you won't miss that... I'll remind you just in case... ;)
Oskar
-
You might have noticed that I was uniquely referring to MSFS AddOn airports.
Which is why I asked: was there ANY of them using a CUSTOM runway markings or textures ? If they did ( without adding an ILS too ), does the auto-tune works there ? Of course I already know the answer, and you should too, if you paid attention when I said LatinVFR found the hard way this IS a problem, and Asobo explicitly told them to add the ILS to their custom runway definition, or not redefine a runway.
That's also why I already explained, quite cleary, we HAD to redefine the runway record to allow uniquely Canadian style markings and numbers.
These are - for the reason I can't stop pointing to - all collected in the AFXnnnn.BGLs, and thus updateable by either an MSFS update or replaceable by a third party Navdatabase by just transferring limited data. Look it as you like, it's just not a smashing idea to tear the updateable standard Navdatabase apart. It's after all not user friendly. You have of course the tool to update all your airports whenever an item of the RWY record will undergo a change within an AIRAC cycle. I hope you won't miss that... I'll remind you just in case... ;)
Look, I understand that, as a developer of a navigation database related utility, you have an interested pushing your idea of the upgradable navaids database. Which sounds nice, in theory, except when it's not. And there several reasons in which is not, for example:
- A custom airport might end up with its runway *slightly* moved from its real world place, for an infinite number of reasons, like different formulas used to georeference the background image, different ellipsoids reference formats, rounding problems somewhere along the way. With an ILS, even a fraction of a degree of rotation, for example, might cause the ILS to look misaligned over its typical range. So, if you want to be sure you have the best possible precision, it's way better than an add-on airport has the runway and the ILS together. Default airport case is not really relevant here, since they are in different files, but they are surely generated by the same database, so we might assume they are coherent.
- The fact that in MSFS, if you don't add an ILS record inside a runway record, the auto-tune won't even work so, either we lost the auto-tune feature, or we lost the ability to customize the runway textures. Users hate default textures, especially in THIS case, where its look is regional specific.
- If users have a problem with an ILS in our scenery, we want to be sure what they are looking at is *our* ILS, because if there's something wrong with it, it's our fault and we can fix it, but if we just leave it out, a 3rd party update can either fix it or screw it, we don't cannot possibly know.
I really don't understand what you are getting at. You first started by saying I was posting inaccurate information, only to be shut down when I told you where I get my accuration information, now you are trying to tell us how we should design airports, so they fit in your interest in keeping the navigational database updated ?
I understand why it might be attractive to you if we didn't include any navaids, but as I've said, unless Asobo fix the auto-tune so it would work even if the runway is redefined and the ILS is in another file, we are surely not going to compromise the quality of our airports and go back to default runways even in places that screams custom runway ( exactly the case with CYVR ), just to make 3rd party navigational utilities happy, so the whole discussion is completely useless.
-
...so the whole discussion is completely useless.
Couldn't agree more.
Oskar
-
Hello,
I've just read these 4 webpages but it is still not clear to me what I should do to "have no issue" except to uninstall the FSdreamteam CYVR scenery.
Is there a nice person to explain to me what I should do to have my ProSim 737 correctly fly the 26L CYVR ILS rather than turning (mad) right then left?
I'm using ProSim 737 3.04b2 with MSFS 1.12.13.0 and FSdreamteam CYVR scenery version 1.1.0 (manifest.json states "VERSION 1.1.0 RELEASED OCTOBER 22, 2020\\nVersion 1.1" even if I was sure to have bought CYVR Vancouver V2 for MSFS on Feb 2nd ???).
Thank You ;-)
Didier
-
I've just read these 4 webpages but it is still not clear to me what I should do to "have no issue" except to uninstall the FSdreamteam CYVR scenery.
There's nothing you must do, since the problem has been fixed long ago.
Is there a nice person to explain to me what I should do to have my ProSim 737 correctly fly the 26L CYVR ILS rather than turning (mad) right then left?
I don't know what Prosim 737 is but, does it work with a default aircraft ?
I'm using ProSim 737 3.04b2 with MSFS 1.12.13.0 and FSdreamteam CYVR scenery version 1.1.0 (manifest.json states "VERSION 1.1.0 RELEASED OCTOBER 22, 2020\\nVersion 1.1" even if I was sure to have bought CYVR Vancouver V2 for MSFS on Feb 2nd ???).
The information in the manifest file is only used by the MS Markeplace but, if you bought the scenery on FSDT site, you surely have the latest version and, as you can clearly see from a previous post of another user, dated October 25th:
If you run the FSDT Updater, the CYVR and KORD sceneries seem to be updated to the correct standard by now. I tested the ILS'es for proper function and they are all correct
So yes, we HAVE updated the scenery to conform to the new (changed) standard, and nobody ever reported a problem with it ever since.