Caching the remote build catalog

Currently this is the way our project is built:

• I set "Build Remote Catalog" to true and set the Catalog build and load paths to remote.
• Set the "Player Version Override" to "0.0.0.1"
• I set the asset groups to build and load local
• Build player content
• Create the build proper
• Then I set the asset groups to build and load remote
• Build player content

This all works good and proper when the build is connected to the internet. When it is not, I assume it relies on the local build catalog and uses the bundles included in the build since it can't reach the catalog on the server.

My question is that since the bundles that are fetched are cached, is there a way of caching the remote catalog so we can used the cached assets?

 

It sounds like you want to have bundles both locally (step 4) and on a remote server (step 7). This won't actually work. The catalog will only ever point to one thing. So if you are offline from the get-go, then your catalog will be the initial local one, and will point to the local assets. As soon as you are online at startup, you'll get the new catalog, which will make your player forget all about the stuff that was local and point to the server.

This catalog is cached, as are all the bundles on the server you download. So if you connect at startup, get the new catalog, then go offline, your game won't work. It'll be looking for <whatever> on the server and not know you have a local copy.

So,

I don't think it does work "good and proper". You are creating a build with all your content, then immediately telling your build that the local content is invalid and the server should be used.

Let me ask you this, is this the user experience you actually want:

1. Say your game has a tank and a boat. both ship locally.
2. user installs game, can get tank and boat while offline
3. you update both tank and boat, putting new versions on server
4. user launches game, while online, gets to the tank level, and gets the new tank downloaded
5. user goes offline
6. user gets to boat level.
7. --> here's where things go off the rails, but I'm guessing what you want is for some system to figure out that the new awesome boat is unavailable, so the user should get the old one.

Is that right?

If that's the case, you actually need to build a wrapper around addressables that handles fallbacks. I'd recommend using labels. you can label a forever-local "boat" "backup" and a someday remote one "primary". Then write a wrapper around addressables that loads "backup" when "primary" fails for everything.

 

Sorry for the late reply,

You are correct, that happens for sure and that is our use case.
That's a good idea, thanks for the help!