Because unfortunately, the scenery creator support is notoriously non existing.
Sometimes I wonder what will happen if
we released a scenery with such obvious problems...in any case, let's see:
I see that GSX sees the correct airport (TNCC) and that it is referencing the exact same .ini file I have edited.
Let's clarify this first: how the whole thing will work depends if you have GSX Navdata enabled or not. In almost all situation, it should be Enabled, which is the default after SU12, which means:
- GSX will not even try reading a certain .BGL anymore. It will just ASK the simulator, using the Simconnect Navdata API "which parking spots you have for this ICAO" ? This means, what GSX will get, is exactly what you are seeing in the sim in the World Map. Good and bad, conflicts included.
- The GSX .INI. You said you edited it as well, but that might have not been necessary if the problem was "just" fixing the isolated parking in the .BGL. If this is all you changed in the scenery, the .INI should work but, instead, if you made other changes like renaming parking spots, the GSX .INI file would have to be fixed as well and, in fact, when this happens, when you open the customization page, GSX will check if all parking spots in the .INI match the ones in the scenery, reporting possible issues and giving the option to either remove just the not-matching spots, or start from scratch with a brand new .INI file. If you haven't renamed any spots (moving them it's ok, renaming them it's not), you shouldn't worry about this.
Note that, when the Navdata is in use, GSX can't automatically switch profiles for a certain ICAO automatically, like it did when it read the .BGL (before, the .INI was associated to a specific .BGL), because when the Navdata is in use, we don't have any idea where the data is coming from: it can even come from multiple .BGLs at once, which can be either correct or wrong (=conflict), we don't know.
Because of this, the only thing that matters for an .INI to be loaded is the ICAO, so if you have multiple .INI for the same ICAO, it's your responsibility to be sure you are using the correct one and remove the others.
Also, what .INI is being used for a certain airport is *saved* in the GSX preferences. In the file named %APPDATA%\Virtuali\Couatladdons.ini, in the [GSX] section, there will be some keys with a name starting with "profile_", then some random characters linking the ICAO to the profile in use so, for example, if you see this line:
profile_kclt = 8zvi_4
It means GSX knows that, at KCLT, the last profile I used/edited was an .INI named kclt-8zvi_4.ini, so you might want to check there as well.
So that's all the possible background about the relationship between the original .BGL and the GSX .INI, when the Navdata is in use, which is the normal situation now. When troubleshooting something, it's best to start with NO .INI at all so, try removing or moving away all .INI you have for that airport first, and ensure GSX is getting the right data from the sim first.
First thing to check would be:
is MSFS using my fixed .BGL ? because what MSFS is seeing, is what will give back to GSX, and the best way to check this going to the Airport with the Developer Mode enabled and use the "Debug Airports" feature to check if your data has been loaded:
https://docs.flightsimulator.com/html/Developer_Mode/Menus/Debug/Airports.htmIf they aren't, the most common cause is a loading order problem, the loading rules are as follows:
1) The package loaded last, will have a priority over the ones loaded before it.
2) Packages are loaded in this order:
- first the ones in the Official folder, in alphabetical order by package name
- then the ones in the Community folder, in alphabetical order by package name
This means, if you are trying to override something in the Official folder, it's very easy because, it's enough you place it in the Community folder, and that's it. However, if both are in the Community folder, the
package name matters, so you need to be sure yours is loaded later, for example by placing it in a package with a name starting with something like "zzz".
That is if you are creating a new package that is supposed to override some files in another package, which is the "proper" and "clean" way.
You might get away with a more hacky way, and JUST replace the scenery .BGL in the original package. But that might be risky because, it depends what was in the original .BGL and what is being saved back after editing it with .ADE, so you might end up losing lots of things, because ADE might not preserve everything that was in the original .BGL, that's why it's best to create a "proper" override package, and respect all the priorities.
Note that, in order to make replacement .BGL, it's best to:
- Use a different filename, which will prevent your overriding .BGL to remove things from the original, because if you do a "virtual" override, meaning a scenery with the same virtual path located in another package ( that is loaded after ), it will have the same effect AS IF you replaced the actual file in the original package! That is a file override, so it comes with the risk of losing parts of the scenery, depending on what ADE preserves from the original .BGL
- When you use a different filename, which is safer, you MUST add your own Exclusions, which will work ONLY if your package is loaded AFTER the one you are trying to modify. For example, if your new ADE file includes again parking spots and taxiways, you MUST add an Exclusion rectangle in it to Exclude parking spots and taxiways, otherwise you'll end up with double parking spots.
A common mistake, seen in many freeware, are add-on sceneries that change parking spots, exclude the taxiways, and share a .BGL that excludes taxiways without providing a replacement, causing ALL parking spots to end up isolated.
