TLDR; How do you handle that Addressables is able to check for catalog updates when using “New Build > Default Build Script”? Do you patch the catalog filename as shown at the end in the video?
I did experiment with Addressables content updates during the past days too and it’s been a nightmare so far. The required functionality is so trivial, yet it’s so utterly complicated with Addressables.
I’m using Unity 2019.4.20f1 and Addressables 1.18.4.
What I found is when using “Update a previous build” with the addressables_content_state.bin
file, Addressables is able to detect if a new catalog is available on a remote location.
However, if I use “New Build > Default Build Script”, then Addressables generates a new catalog and stores it under an unique new filename, causing the existing Player to no longer detect any catalog changes, because the player still points to the old catalog under the old filename.
I found the Player (Build) stores the catalog URL in the file StreamingAssets\aa\settings.json
, here is the relevant snippet from that file:
{ ... "m_InternalId":"http://YourServerAddress/catalog_2021.06.07.13.01.40.hash", ...
Using “Update a previous build” makes sure the new catalog is saved using the same name as before. The catalog name is also stored in the addressables_content_state.bin file. Using “New Build > Default Build Script” on the other hand saves the catalog under a new name.
I found addressables_content_state.bin being really fragile, because once you trigger a “New Build > Default Build Script” by accident (which I did during tests), you break the entire update forever and cannot go back, because the new catalog name is stored in addressables_content_state.bin. Adding addressables_content_state.bin to version control would be very important to be able to go back in this case.
Anyway, I really don’t like the addressables_content_state.bin workflow, because it adds so much overhead. We create builds on a build server, which would then need to backup/restore or version control the addressables_content_state.bin file, while nobody on the team wants to deal with it locally. Well, nobody else must ever deal with this file, because it would break future content updates.
I would really want to simply use “New Build > Default Build Script” for every build. As you wrote earlier, bundles with no content changes are not rebuilt, so that’s expected what’s needed.
The issue that persists is the catalog URL. How do you handle that Addressables is able to check for catalog updates when using “New Build > Default Build Script”? Do you patch the catalog filename as shown at the end in the video?
https://www.youtube.com/watch?v=XMtyihUZY0k
PS: Sorry for bad English and accent in the video.