Check for Content Update Restrictions adding all dependent assets when UniqueBundleID disabled

(reposting in better place)

Addressable system is almost great, but appears to be unusable for console platform patches/DLC (the reason we started using it). Am really hoping I am doing something wrong.. (am on 1.7.5)

Am using static groups (can not change post release) and Build Remote Catalog ticked.

I also have Unique Bundle ID's Unticked. but have tried both ticked and unticked.

If I change a texture and run tools/Check for Content Update Restrictions, it doesnt just put the texture in the content update, but also everything that depends on that texture, that appears to not just include the material, but also the prefab and even the fbx. So potentially changing 1 small asset can bring in a ton of content that hasnt actually changed. causing you to easily break the 500MB patch/dlc update limit on one console platform. Imagine changing a widely shared shader it could cause half our project to be put in the patch!

I tried moving each asset type to its own group ( so shader,material,texture,prefab,fbx) but had the same result.

Note I am copying the addressables_content_state.bin file to the build folder with the built asset bundles and it does correctly produce a build with the old identical asset bundle and a new content update bundle, and running does load the new texture. its just has a much bigger than expected asset bundle for the update.

I notice in the documentation DevelopmentCycle/UniqueBundleID's it states

"The downside of this option is that it requires bundles to be rebuilt up the dependency chain. Meaning if you changed a material in one group, by default only the material's bundle would be rebuilt. With "Unique Bundle IDs" on, any asset that references that material would also need rebuilding." (form https://docs.unity3d.com/Packages/c...manual/AddressableAssetsDevelopmentCycle.html)

I have tried turning this option on and off and it appears to make no difference and its still trying to place all upchain dependencies in the Content Update bundle.

Am hoping this is just a bug or user error some how..



BTW all the above was done on a windows test scene

 

Thanks for reaching out. Let me give you some context. There are two ways objects in bundles can be referenced.

1. explicitly included items can be loaded from a bundle via their file name. This is what addressables uses under the hood to load something (you say load "tree", we use our catalog to know that''s actually "whatever/tree.prefab" from "whatever.bundle"). Pre-addressables, this is how a user would load some asset out of a bundle
2. all items (explicit and implicit) have a "local identifier in file", and all bundles have an "internal file id". This is how the engine references items.

If ever one item in a bundle needs to depend on another, it uses the second method: internal file id + local identifier in file. Which means, when your prefab is built, it knows it depends on "identifier XYZ inside bundle 123".


So, let's walk through your update scenario. A prefab has a direct dependency on a material. So the prefab knows it needs to load "id M1 from bundle X". Now, you do a content update, moving that material to a new bundle. In order for the prefab to reference it, the prefab needs to be rebuilt so it now knows "id M1 from bundle Z"

This is how asset bundles work in the underlying engine. Addressables is a wrapper for this system, but this is how bundles have been for many years.


Now with that context, there are two ways you can solve this problem....

1. don't use content update workflow. If you are not downloading things, there's a good chance you could just do a clean rebuild every time. This is the case for most console & pc games. This way, the material that was in bundleX stays in bundleX. With the newest versions of the engine, bundles should be properly byte aligned, so you can change a material in a big bundle, and the console's patching system will handle it gracefully. If you aren't able to get that working, the alternative is to stick with many small bundles. Either way, the material change is isolated to the bundle the material is in.
2. don't use direct engine references. If your prefab had a script attached that on-load asked for a material via addressable name, and then attached it, then you could update/move/whatever that material, and the prefab bundle wouldn't care.

 

I see, its good to know the content update system is not meant for console patches/dlc I can stop pursuing this avenue.

In option 2 above I assume Direct Engine references means using things like meshfilter and meshrenderer? all the existing stuff that our prefabs are 99% made of?

My understanding of the catalog system was clearly wrong.

I thought the catalog system was a way of remapping any asset to load from a different place, so if the material changed it could be in its own bundle, when the original prefab is loaded from its original asset bundle its dependencies are loaded and a request for the material that changed it would check the catalog see this material is now in another bundle and load it from there, the runtime ID's would be the same, it would just load off disk from new location, ie just the off disk load comes from a different place.

Our goal here is to be able to provide console dlc/patches without breaking the 500 Meg download limit on one console.

I will have to investigate the other options.