Products Support > Vancouver CYVR support MSFS

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

<< < (12/13) > >>

virtuali:

--- Quote from: lonewulf47 on October 27, 2020, 02:08:23 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.
--- End quote ---

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.

lonewulf47:

--- Quote from: virtuali on October 27, 2020, 03:34:02 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....

--- End quote ---

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

virtuali:

--- Quote from: lonewulf47 on October 27, 2020, 07:29:48 pm ---You might have noticed that I was uniquely referring to MSFS AddOn airports.
--- End quote ---

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... ;)
--- End quote ---

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.

lonewulf47:

--- Quote from: virtuali on October 27, 2020, 11:09:15 pm ---...so the whole discussion is completely useless.

--- End quote ---

Couldn't agree more.

Oskar

DaddyBoon:
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

Navigation

[0] Message Index

[#] Next page

[*] Previous page