FSDreamTeam forum
December 02, 2020, 07:37:02 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 1188 times)
lonewulf47
Newbie
*
Posts: 30


« Reply #45 on: October 25, 2020, 05:18:20 AM »

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

You bet I did !! Cheesy Grin
Logged
GeoNau
Newbie
*
Posts: 15


« Reply #46 on: October 25, 2020, 10:17:59 AM »

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 !
Logged
lonewulf47
Newbie
*
Posts: 30


« Reply #47 on: October 25, 2020, 12:21:45 PM »

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
« Last Edit: October 26, 2020, 07:54:57 AM by lonewulf47 » Logged
Michael2
Newbie
*
Posts: 18


« Reply #48 on: October 26, 2020, 02:02:17 AM »

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?
Logged
GeoNau
Newbie
*
Posts: 15


« Reply #49 on: October 26, 2020, 05:29:36 PM »

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.



* 2020-10-26_162512.jpg (404.25 KB, 1920x1080 - viewed 12 times.)
Logged
lonewulf47
Newbie
*
Posts: 30


« Reply #50 on: October 26, 2020, 08:46:47 PM »

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.
Logged
GeoNau
Newbie
*
Posts: 15


« Reply #51 on: October 26, 2020, 10:00:46 PM »

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



WWW
« Reply #52 on: October 27, 2020, 12:43:10 PM »

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

GeoNau
Newbie
*
Posts: 15


« Reply #53 on: October 27, 2020, 01:37:19 PM »

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.
Logged
lonewulf47
Newbie
*
Posts: 30


« Reply #54 on: October 27, 2020, 03:08:23 PM »

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



WWW
« Reply #55 on: October 27, 2020, 04:34:02 PM »

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.
« Last Edit: October 27, 2020, 04:35:35 PM by virtuali » Logged

lonewulf47
Newbie
*
Posts: 30


« Reply #56 on: October 27, 2020, 08:29:48 PM »

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

Oskar
Logged
virtuali
Administrator
Hero Member
*****
Posts: 40165



WWW
« Reply #57 on: October 28, 2020, 12:09:15 AM »

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.

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

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

lonewulf47
Newbie
*
Posts: 30


« Reply #58 on: October 28, 2020, 04:48:48 PM »

...so the whole discussion is completely useless.

Couldn't agree more.

Oskar
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!