Using same objects for different airports/packages

By now I have quite a large number of objects that I use in all my sceneries. I want to include them in every package and not as a separate library, for convenience and ease of distribution.

Can I just include the same objects with the same names and GUID in different packages? Will MSFS just use the latest one or will this create a conflict or a potential crash?
Do I have to change both the name and GUID for every object? I have a couple of hundreds by now, and it’s extremely cumbersome to do it for all of them.

I couldn’t find clear information on that anywhere…

1 Like

You can use the same GUIDs…

Just keep in mind that if you update an object, the last one loaded wins and applies everywhere.

2 Likes

uhm objects with the same guid will have duplicate guid warning in the console,
not professional :smiley:

the library option seems the most efficient way, less disk space, less stuff for the game to handle
and a RomanDesign user will likely have multiple RomanDesign products, so imho that’s the way to go

how to handle them in a marketplace environment is a whole different story, however there are already some relevant example (e.g. emerald library)

1 Like

Yes, that’s the whole thing - for the Marketplace there’s only one package, and making people download another free library will inevitably result in hundreds of support emails asking why things don’t work, with I don’t have resources to handle.
Some stores also don’t have an easy way to handle libraries.

1 Like

Of course, the Microsoft custom airports often reuse GUIDs and duplicate objects…

1 Like

I think a lot of users are familiar with the idea of libraries now. I went through this support phase as well. Luckily I rarely get this question anymore, but maybe it’s because my library is used quite a bit for freewares outside of my own now.

The biggest change I made on Marketplace to limit confusion was to disclose that a library is needed in the first heading. Make it the first thing they have to read.

Though, even with that added chance of support (which I’m one person handling as well), I personally don’t ever see myself moving away from a separate library. It’s just the smart way to do things, at least in my situation. Less disk space and since I improve my models frequently, it makes the workflow so much more efficient.

I did my Forwood Farm collaboration with Got Friends as as all-in-one and I hate it. I have to keep track of all of my model changes when I do a library update and make sure I am bringing the updated models over to the Forwood package as soon as I complete them.

Though, if you are not planning to touch the models again, it wouldn’t be a huge deal. Just more complex if you update a few models and have to do that across x amount of products.

I also pay for CDN bandwidth on my own web store, so it’s nice not having to pay for that extra duplicate fluff every time I do a product update. You only make that sale one time, and everything else after that comes out of pocket. Though, luckily it’s not a worry if you are just going through vendors.

1 Like

How do you handle submitting your library as a product to Marketplace? Is it a separate free product, and the only indication of the dependency is to say it in the description, i.e. not a “Pack” or any bundle? Then I suppose you have to make sure your library makes it through the submission process before your actual product that uses it.

I produce paid scenery - airports mostly, and release the same package to the MSFS in-game Marketplace and several stores.

I know, I bought some of your scenery. :slight_smile:

I was asking generally about how a dev submits a library to Marketplace. Is it submitted as a separate product with price $0.00 but otherwise it goes through the same approval and test process?

I don’t know, probably yes. AFAK there is no way to automatically link a library as required so it automatically installs. That means people would have to find and install a free library separately, and just being the scenery won’t work.

Maybe setting up the

<Dependencies> 

can lead customers to the right way?

Disclaimer, Never had a.chance to experiment with them

E.g. Some of Microsoft’s package (world update and such) need something else as, and you get a warning if the installation doesn’t meet requirements

I notified the Marketplace team on my Teams chat that I intended to release a library as a requirement for all of my future addons and first got their OK. Then I just submitted it like I would any other product for marketplace, but at $0, and then dropped a reminder to them that I had submitted the library and that it would be a requirement for X product that I was publishing at the same time.

If I ever add a new product or update a product that requires an update to the library to function, then I will mention it in the changelog/notes section of the Marketplace Content Portal when I upload the airport package and just say something like: “this requires the latest version of Emerald Object Library and needs to be published after or at the same time as the library.”

I’ve never ran into any release timeline issues and typically I will submit the library before or at the same time as the airport(s), as well as the testing, so they release on the same day.

There is no way to force the library as a dependency (where it is redeemed/downloaded with another product purchase), that’s why I mention it first thing in my airport description. I have also had this conversation with the marketplace team and and they have only said that it is something they are discussing for the future (That was October 2022).

As far as I know the “Dependencies” section in the json is not something that we can set up as packages going to marketplace shouldn’t be altered after export.

2 Likes