Remote Catalog Path linked to addressables bin

So I noticed that if I want to change the remote catalog path in the editor and do a "build for content update", I will not be allowed because the path has changed from what it was originally (I assume unity looks at the path saved in the bin file created when I did a "Build player content").

So I am trying to have a build system that does this:

First build - setup path for addressables and catalog to be bucket/0 then run "Build player content" and build the client with a remote profile.

Next builds - setup path for addressables and catalog to be bucket/<buildNumber> then run "Build for content update" (FAILS) and build the client with a remote profile.

ERROR "Current 'Remote Catalog Load Path' does not match load path of original player. Player will only know to look up catalog at original location."

Is there a way to fix this so I can have a new catalog path for every update on every build?

I do this so each client has its own set of data and catalog in a different path.
If we decide to release build 24 and we have build 10 live we can test build 24 against the updated data (separate from other build's data) and also if we want to test the live build (10) without disturbing the current build 10 data we just override the catalog path of 10 with a cheat and make it point to the catalog path of build 24.

Hope it makes sense lol, thank you.
Lars

 

no. or yes. depending on what you are asking. Two points...

1. the path for the catalog is set on the main AddressableAssetSettings object, so if you want to make updates where your content is in different places you can create extra profile variables (RemoteLoadPath, RemoteCatalogLoadPath, etc.). This way you can change where your content is being built without changing your catalog. If this is what you're actually after (moving content) then, yes, you can do this.
2. If what you want to do is actually have your catalog somewhere new, then no, you cannot currently do this. And I don't think you'd want to. The key is that in your description you say "build content for bucket/0" then next "build content for bucket/n". I'm not sure exactly what situation you're in, but it's one of these two...
   1. You skipped the middle step of "build and ship a player". In this case, the player knows to look for it's remote catalog in bucket/0. If you move the catalog, then the shipped player has no idea where to find it.
   2. Or these are your exact steps. In which case, just do a new fresh build. The point of "update" is that you have some player to update. If you just want to do a build to one server, then for some reason do another build to another server, the update flow is completely disconnected from this. Also, I don't really know why you'd do this. Unless your steps were actually "build for bucket/0, then build player0 that looks there, then build for bucket/n, then build playerN..."

or you're after some other workflow that I'm not following.

 

Thank you for the fast reply.

The previous reason to change the catalog path is for having an incremental jenkins build pipeline where we can check any new client with a new updated content without messing up with previous or new builds.

So what you are saying is that we cannot change the catalog load path when we build for content update, how about changing it at runtime.

Here is a reason I have to change it at runtime.

-We have 10 QA testers each one with a client using catalog v1 which is in url X, the asset bundles are in url A
-We have a content update coming, we create the content update, this creates a new catalog v2 and new bundles for the assets updated, we place this new catalog in url Y and the bundles needed in url B.
-The 10 clients are still pointing to url X to get the catalog v1.
-Now I want 2 QA testers to test the new update without affecting the other 8 testers.
-I think a solution is to change the catalog load path in 2 clients (maybe with a cheat or config file) at runtime to point to catalog v2 in url Y. these 2 clients pick up catalog v2 from url Y and this points to updated assets in url B.
-If everything passes testing I can deploy catalog V2 in url X, and now all clients point to the new assets in url B.

Is this possible at the moment in Unity?
Are there plans to let you change the catalog load path when you do a build for content update in future Unity updates?.
Is there a workaround to force a different catalog load path when we build for content update?.

Thank you

 

Hi! We have around the same workflow as yours. My questions are here: https://forum.unity.com/threads/versioning-of-features-dynamic-content.712394/.

We need the same possibility. Like Feature one with different versions for different clients and even more.

 

Hi, I got an answer for this issue in my other post which I cannot link because I get a spam warning, I will try to post again the link later. Thank you

 

Waiting for link. Thanks!

 

Still does not let me post links, look in the forums for change-remote-catalog-load-path-at-runtime.
We cannot change the path for the catalog, but we can set it to be a runtime variable using something like {MyApp.MyConfig.MyCatalogPathVariable}.
In my case I can have our build pipeline script update a default configuration to point the client to any place for the catalog.
In the same way I can implement a cheat that will update the configuration and override the default value (once I restart the correct catalog will be loaded).
Finally I could set the catalog path using a server value when I login.

 

Okeeey, we have ONE catalog and ONE .bin file for whole project. That is really not nice. That goes to huge coupling between different features. If I have 500GB of content, and want to add some new level pack (~30MB) I need to have all 500GB + 30MB of my new feature. I can't build project just with 30MB feature... Moreover addressable settings file will be just HUGE and coupled. @unity_bill what do you recommend? This is connected to my other topic (Versioning of features dynamic content).

 

This is what he's trying to link: https://forum.unity.com/threads/change-remote-catalog-load-path-at-runtime.712052/

no idea why it blocks him.

For now, you'd have to create a custom build script to make multiple catalogs. For testing (and maybe for shipping) we do have the ability to turn groups on and off (using the "include in build" checkbox on each group's settings). If you tried to do this as a way to ship multiple features, you'd just need a custom loader to handle the mutliple catalogs you'd make.

Of note, if you build by disabling some groups, you can wind up with some duplicated data, or weird dependency issues.

 

If I create multiple catalogs like this, how do I get the project to look for them all? Doesn't it only keep a reference to the last catalog created?

 

Same question from my side. How can I specify multiple remote catalogs?