Migrating to addressables

Good afternoon.

We have our own abstraction layer above assetbundles/versioning/distribution which strives for the same goals that the addressable system does, but we've been looking into migrating to addressables.

A couple of things that are still unclear to me after digging through the documentation and samples:

- Does the addressables system attempt to fix some common assetbundle culprits like loading video's on Android, or is every limitation to the assetbundle system also true for addressables.

- I don't entirely understand the purpose of the IHostingProvider, is it meant for dev-only or can this system be used to actually push generated bundles/settings to our remote servers (AWS).

- Can we have more granular control over assetbundle build settings? SBP for example allows us to define compression settings on a per bundle basis

- Can we control how downloaded bundles are stored/cached, for example, can we write them to filesystem instead of unitycache

 

Not sure about most of these things, but regarding the first point: Addressables still uses the same Asset Bundle system under the hood, it only changes how you reference assets in those bundles, so whatever problem you were having with loading videos on Android is likely to still exist.

 

dev-only.
push generated bundles/settings to our remote servers requires a custom content build script, like this one.

Code (CSharp):

1.  AddressableAssetSettings.CleanPlayerContent(
2.             AddressableAssetSettingsDefaultObject.Settings.ActivePlayerDataBuilder);
3.         AddressableAssetSettings.BuildPlayerContent();
4. // Push to server
5. ...

You can do it on a group level. So depends on how to use group.

Yes, but you need write a custom provider.

 

Thanks for the answers, any examples of custom providers? Only docs I can find is this :

https://docs.unity3d.com/Packages/c.../manual/AddressableAssetsCustomOperation.html

And there doesn't appear to be a sample for it in the github repo.

I'm somewhat confused about what the term 'static content' means. When I 'Prepare For Content Update' it only appears to look for content changes in Groups that have an update schema that has 'Static Content' enabled. The docs say that static content should apply to assets that do NOT change (and are for example in streaming assets), how would I build content for groups that aren't marked static (and are therefore expected to change)?

I watched this talk just now:

In the Q&A it briefly touches on one of the most important topics. Given that code changes from build to build. how do we offer different content versions to different builds to ensure compatability. The man in the talk says that they 'slip something extra into a build' (???) to make sure the build knows what 'build version' it is. It also says that incompatabilities will be detected at build time rather than at runtime.

However, if I make a build, and then prepare an update which contains references to monobehaviours that I added after that build, it just builds the bundles and catalog without warnings.

Is there more info on content version management? How do builds know to load the 'newest compatible' content instead of the newest content? Or do we define a different remote load path when we know scripts have changed?

 

https://forum.unity.com/threads/providers-what-are-those.690109/
I guess read source code can be the most direct way. Probably starts with AssetBundleProvider.cs by searching
UnityWebRequestAssetBundle.GetAssetBundle.

For most time it means assets ship with an app build, that not frequently get update.To update the "static content" without publishing a new build, addressable system provides the content update flow, that comparing all static contents with last build state (.bin file), find changed/new assets, move those assets into a new group, then build that group to generate one bundle. I assume it's not really a fun process when you have lots versions to take care.

Another approach is moving most your assets to dynamic assets, so they just get updated on the fly, each time you push a content build to server. (just build player content).

Based on the fact that Unity doesn't like the idea to publish code on the fly, if your new content need new script not available in old build, it may fail to load (or perhaps partial loaded, need more test).

The most easy way to avoid the issue is to go for the pure-asset approach. That means use script to construct everything else.

Some teams use a different vm inside unity (like lua), so they can ship code with asset at the same version.

Could be something to improve.

 

Thanks for the insights. Guess I'm a bit confused because some of the things in that talk apparently haven't been released yet.

I think I understand the update mechanism now, the prepare/build for content update are only used when updating content that was assumed to be 'static', if I change dynamic assets I just build player data and update the files on the server.

So there's no mechanism built in to offer different versions of content to different build versions? Because the talk mentions it. And this seems to me like the most common usecase.

 

Checkout player version override in setting file. It overrides the hash of (remote) catalog, so you can build for different versions.

You can also override remote load path in runtime to load different versions.