Scenery creators: please move or rename your modelLib.BGL

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?

1 Like

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.

1 Like

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.

Yeah I didn’t like that it rewrote the layout.json, as a developer, so I preferred not to use it…

Although it DID find something that I missed, so :man_shrugging:

It probably won’t harm it, but sometimes there are files present that the developer doesn’t want the sim to know are there…

Yeah, I didn’t want to change anything other than what I was trying to fix! But seems no harm was done by renaming all the modelLibs it pointed out.

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.

10 Likes

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.

2 Likes

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)

2 Likes

So with Sim Update 5.

If you export your scenery and rename the modellib.BGL none of your model assets will load in.

You may want to test this on your end if this same result happens. If this happens, change it back to ‘modellib.’

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

The issue is not about the name of the file, but the name in a specific path .
If both condition are not met at the same time, no issue will happen

I’ve never had any issue with renaming modellib.bgl files. You have to make sure to update the layout.json when you do 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?
image
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?

The problem is, so many authors still put their modellib.bgl in scenery\global, even after all this time I still have to fix scenery all the time.

So, Should I place the modellibchanger to change that? or will it create conflict with the addons[gsx per example…]

I have no idea about GSX and what it has to do with modellib.bgl files in scenery, and, I’m sorry… “change isso?”? What are you asking?

1 Like

sorry!! I meant “change that?”

So, I don’t know what the “modellibchanger” is.

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 hope what I wrote makes sense.

1 Like

thanks for your words, having that I think I won’t need to rename, since the directory is “exclusive”…
thank you!!

I am in need of some help.

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?