AFCAD path

[ogeva]

I see a lot of GSX profiles for download where the creators set the AFCAD PATH to the user's GSX path, where the ini file is. But there are no BGL files in that folder.
is that supposed to work?
Other implementations refer an addon's path in the community folder, and then (with modification to match my own community folder base path) I always see the BGLs exist.

For example, this one refers:
afcad_path = \\?\C:\Users\ollie\AppData\Roaming\Virtuali\GSX\MSFS\EGLL.bgl

[olliejstacey]

I copied the bgl to the virtuali folder to overcome issues with it not being found in my community folder.

[ogeva]

Why not point the path to where the bgl is?
But how do you find it? Search for the name?

[olliejstacey]

Just look within the folder for the add on airport for it.

[ogeva]

Anyway, looks like there is no standard/accepted way. Some refer to it internally, some refer to the community folder -which depends on the maker's installation.
Installing these is too complex.
I think if the software would take a relative path to either official or community it could be idiot proof.
Or alternatively if there was an installer for configurations.

[slicker55]

OP raises the same question I was going to ask so might as well keep this post going.
I've been trying to get a definitive answer to this for a while but, generally speaking, there appears to be quite a bit of confusion and uncertainty ...
For the record, I'm on a Win 10 PC, MSFS 2020 (Store Version) using Orbx payware (installed to default MSFS library)
Whenever I download a GSX profile, I edit the AFCAD path (created by the GSX author) to point to where the .BGL is actually located inside the Community folder on my system.
As far as I am aware, this is the correct procedure and as the profiles always work, I suppose that's proof in itself.
However, lately, some people have been advising the AFCAD path is no longer used and that editing it serves no purpose?
I don't know if this advice is actually correct and if so, whether it only relates to certain installations?
Hoping someone with more experience using GSX can clarify if what I am doing is the correct procedure please

[virtuali]

Lots of creators tells you to edit the afcad_path to your own path, because they didn't read the manual, which clearly says it's NOT required, for the precise reason to ease sharing. This is what the manual says about it when sharing of profiles is explained, Page 52:

The name of the .BGL used to customize the scenery is listed in the [GENERAL] section of the GSX .INI profile. It will include the complete path valid for your system but, don’t worry, there’s no need to edit it out before sharing your work, since GSX will only use the .BGL filename, and will ignore the full path altogether, it has been designed like this exactly to facilitate sharing of GSX .INI profiles without worrying about different paths. As long the currently active .BGL matches the name referenced in the .INI file, the .INI will be loaded by GSX, no matter the path.

This is how GSX always worked by default, which means the SU10 Navdata API option is Disabled. It has been like this since FSX, nothing has changed. The only thing that has changed, perhaps, is that after I keep repeating this, finally someone must have realized how it works, and editing is not required, but it's nothing we changed, it's how GSX worked for years.

When the SU10 Navdata API option in Enabled, GSX won't even read ANY .BGL to begin with, so the whole afcad_path line is completely ignored, not just the path. In this case, only the first part of the name of the .INI itself ( the ICAO, before the dash ) matters, so it will be your responsibility to be sure:

- You only have ONE profile for a given airport.

- The profile is correct for the scenery you have installed.

This because, when the SU10 Navdata API option is Enabled, GSX is no longer able to associate a profile to the loaded BGL because...there's no "loaded .BGL" anymore, GSX will take the airport data directly from Simconnect, without any knowledge about which .BGL contains it.

Another effect of using the SU10 Navdata API option, is that airport profiles will ONLY work from GSX profiles folder:

%APPDATA%\Virtuali\GSX\MSFS

If you have a custom profile made by the scenery developer himself, located in the scenery package in the Community folder, it won't be used by GSX when the SU10 Navdata API option is Enabled, because GSX won't even read the Community in that case: it doesn't have to, because the simulator itself will provide with the airport data, so the whole scan of the Community folders for scenery files, which lead to the creation of the airport cache, is no longer done, which of course simplifies the program, make it faster and more reliable to run, since any possible issue related to reading .BGL or accessing the Community folder is completely bypassed.

The side effect of this, is if you have a 3rd party scenery that came with its own GSX .INI file in its own package, it MUST be manually copied in %APPDATA%\Virtuali\GSX\MSFS, because when the  SU10 Navdata API option is Enabled, it's the ONLY place GSX will read custom profiles from.

This also fully explained in the Manual, where the SU10 Navdata option is explained, at Page 83.

[slicker55]

Hello Umberto,
Thank you for taking the time to provide such a detailed response which is very informative. I will take another look at the manual and get back to you if necessary. Thanks again, very much appreciated... love GSX Pro 

[slicker55]

Hi Umberto, I now realise that I was not reading the latest version of the user manual as the version I was using didn’t go up to page 83

I have now enabled SU10 Navdata option which was previously ‘unchecked’… another useful thing learned from re-opening this post.

Prior to receiving your advice, after downloading a new GSX Pro profile, I would have typically opened the .BGL, edited the AFCAD path to reflect the location of the .BGL on my computer and copy the .BGL into my Community folder.

I assumed everything was OK as the profiles seem to work fine but your advice has made me see things differently.

I had already noticed that when I add a new .BGL into the Community folder, a copy automatically appears in %APPDATA%\Virtuali\GSX\MSFS

This now ties in with what you’ve said about disregarding the Community folder and placing the .BGL directly into the GSX/MSFS folder

So, to summarise:

Enable SU10 Navdata option
Copy .BGL into %APPDATA%\Virtuali\GSX\MSFS
No need to edit AFCAD path in .BGL
Ignore Community folder

Thanks again for your patience and understanding. This has been a very useful exercise which, hopefully, will enable myself and other users to get the most out of this excellent product.

[virtuali]

Enable SU10 Navdata option
Copy .BGL into %APPDATA%\Virtuali\GSX\MSFS

You should not copy the .BGL, but the .INI, since as I've said in my previous reply ( and of course as explained in the manual ), when the SU10 Navdata option is Enabled, GSX will not read ANY .BGL, no matter where it's located.

It's the .INI ( the profile itself ) that need to be copied with the SU10 Navdata API enabled, because since GSX won't even read the Community anymore, if an .INI has been supplied by the scenery developer in the scenery package, it must be manually copied to the %APPDATA%\Virtuali\GSX\MSFS, since profiles are not read from the Community too, not just .BGLs.

[slicker55]

Hello Umberto,
Thanks, once again, for clarifying...
My sincere apologies, I have been mistakenly referring to .BGL when I actually meant .INI 
Everything is now crystal clear...