What are people’s experiences with ModelLibChanger?? I only rarely get a CTD, but I have tons of random addons and I’d like to feel confident they are not causing problems.
But when I run ModelLibChanger 0.9.4.1 it list a lot of “file count difference” and seems like it’s going to rebuild the json files for a lot of add on that are from credible devs and I have no reason to think are a problem. I only want to fix the modelLib.bgl issues. This app give no option about which to fix or not? I don’t like making changes I don’t understand nor think I need. I have backed up my entire 40+ GB community folder, but I still don’t want to deal with cleaning a mess up if this “experimental” utility messes up countless add ons that are not giving me any troubles as far as I know?
ModelLibChanger simply changes all ModelLib.bgl name and then scans the files in each folder in Community and rewrites the layout.json - for every folder.
Are you sure that’s all it does? It lists a bunch of add ons and mentions the renaming the ModelLib.bgl, but just as many add ons are listed, without a mention of the modelLib, but does mention the file count in the json and offers to correct that?
I was able to figure out how to choose which add ons to fix by simply selecting them. So I left them all alone unless it mentioned the modelLib name.
All seems well, nothing bad has happened! I few out of one airport it renamed the modelLib for and it seemed unharmed.
This issue came out several months ago, when some users reported conflicts between sceneries and/or missing objects, so we asked Asobo about this, and they confirmed which cases can be considered conflicts and which aren’t so:
CASE 1
Scenery A installed in Community\SceneryA with a modelLib-SceneryA.BGL located in the following folder inside its package: scenery\MyCompany-SceneryA\modelLib-SceneryA.BGL
Scenery B installed in Community\SceneryB with a modelLib-SceneryB.BGL located in the following folder inside its package: scenery\MyCompany-SceneryB\modelLib-SceneryB.BGL
THIS IS THE BEST SOLUTION, because by giving both the pathname and the filename unique names, it’s very unlikely we’ll end up with a name clash.
CASE 2
Scenery A installed in Community\SceneryA with a modelLib-SceneryA.BGL located in the following folder inside its package: scenery\global\modelLib-SceneryA.BGL
Scenery B installed in Community\SceneryB with a modelLib-SceneryB.BGL located in the following folder inside its package: scenery\global\modelLib-SceneryB.BGL
This is NOT a conflict, although some care should be taken on the filename, to be sure it’s not used by something else.
CASE 3
Scenery A installed in Community\SceneryA with a modelLib.BGL located in the following folder inside its package: scenery\MyCompany-SceneryA\modelLib.BGL
Scenery B installed in Community\SceneryB with a modelLib.BGL located in the following folder inside its package: scenery\MyCompany-SceneryB\modelLib.BGL
This is NOT a conflict, since the pathname is different so, even if the filename is the same, it doesn’t matter.
CASE 4
Scenery A installed in Community\SceneryA with a modelLib.BGL located in the following folder inside its package: scenery\global\modelLib.BGL
Scenery B installed in Community\SceneryB with a modelLib.BGL located in the following folder inside its package: scenery\global\modelLib.BGL
THIS IS A CONFLICT, because both the pathname and the filename are identical so, depending on the scenery loading order, objects from either A or B might show, so it better be fixed.
How to fix conflicts depends if you are users of the scenery, or developers:
USERS
Rename the modelLib.BGL file inside the package AND update the layout.json file with the new name, or use utilities to do that.
DEVELOPERS
Edit the <OutputDir> path in the .XML file in the Package Definitions folder of your project, and replace the path, for example changing it from Scenery\Global\Scenery\ to Scenery\MyCompany-MyScenery, and rebuild the project.
This will only affect the pathname ( which is enough to prevent conflicts ), because the filename of the resulting .BGL is controlled by the name of the folder in the PackageSources which contains the source .GLTF/.XML files for the models so, if you also want an unique filename, you must also rename the PackageSources\modelLib folder in your project AND edit the path in the <AssetDir> tag to match the new folder name.
GUID Conflicts - Developers
Even if your pathname and filename are unique, there’s still a chance for a conflict, which might be caused by GUIDs reused by you or other developers. Every 3D object in the sim must have an unique GUID, a common error is to copy the .XML file of the SDK sample and changing the name of the .GLTF without generating a new GUID for it.
One of the easiest way to generate GUIDs is using this free app on the Windows Store:
Be sure the .XML file located in the same folder of the .GLTF file has a unique GUID and, if you changed it, be sure you also changed it in the airport .XML source file to match, the Rebuild the project.
There still are a lot of airport designers using modelLib.BGL.
For those of you who have MSFS Addons Linker, there is an automatic filename updater that takes care of this.
Correct. The community folder names don’t matter at all. What is within the Scenery or SimObject folders all must be unique (and then correctly referenced in the layout.json)
Is renaming still a thing? So many payware airports have still same modellib.BGL names. Frustrating.
If you use the addonlinker once and then the airport get updated, the addonlinker will not work because it already founds a renamed valid modellib.bgl and could not overwrite it.
The simulator should be hardened more to handle it
Does this addon still have use?
I used it a lot as soon as it was released, but since SU11 I haven’t used it anymore, is it still necessary?
I did a check, but I was afraid of what it did, maybe there is a problem with GSX and I have to reinstall it, however, is it still necessary to use this addon?
Personally, I just fix packages myself by renaming the modellib.bgl file to something unique, or, in the case where I find a “mycompany” directory, renaming that directory to something unique. In both situations, the layout.json file needs to be updated to reflect the new paths and filenames. I do this for all files that look like somebody else might use the same name in the same path.
The main thing to remember is the path to the information has to be unique when viewed by the Virtual File System. You can have a modellib.bgl file and not have issues as long as it exists in a unique path. So if you find “mycompany\modellib.bgl”, if you just rename the “mycompany” directory to something unique that no other package will use, you can leave the filename of the modellib.bgl alone.
But, if you find modellib.bgl in scenery\global then it needs to be renamed.
For instance, in the Orbx YRED airport, all the files can be found in scenery\pushbackstudio\airport-yred. No other package will ever use this path, and it’s unique for pushbackstudio, too, as they’ll use a separate pushbackstudio\airport-xxx directory for each of their releases. So it’s ok that they have a modellib.bgl file in that location.
I see a lot of vendors who put their files in their company name directory (not mycompany, which sooooo many developers don’t bother to change; drives me totally batty), but then have several different packages that have the same filename files across multiple packages in that same directory path in several different packages. That’s just going to cause problems.
I don’t know how GSX works, but, hopefully it doesn’t hard code paths to files to work. Otherwise, you should not have any issues with any packages if you follow these rules.
BTW, I even found several issues within the “Misty Fjords” package I had to go through and fix. I reported them, I don’t know if they ever fixed them.
I have read this thread, multiple times, and it may as well be in an alien language. I don’t have a clue what a good 1/3 of what people are describing is. All the screenshots don’t look how i expect.
I stopped creating content for MSFS back in 2020… so a while back. I have since been told that my airport mods might have this conflict and would like to fix this but, I don’t have a clue how.
I know there have been a lot of helpful people in this thread, but right now im not even sure how to open and edit my scenery.
The only thing i can thin is, would my content really be causing this conflict, as none of it uses custom assets, it is all created with the in-game assets, buildings, etc?