Doable with Addressables vs AssetBundles? Some feedback and questions!

Hi, I understand that Addressables uses AssetBundles underneath currently. I'd like to switch my loading code to Addressables from AssetBundles, as it seems to be the future for asset loading, but I'm finding it difficult to do so.

I'm using AssetBundles for synchronously loading local content, not for loading assets from a server. I look for AssetBundles in a mod folder in the PersistentDataPath first and load that if it exists, otherwise I load them from StreamingAssets.

Here are my questions:
1. My main issue is how to assign the loading path for a group at runtime? The group's ScriptableObject only allows setting a LocalLoadPath which is StreamingAssets, but I'd like to be able to switch the loading path from StreamingAssets to a user-created mod folder under PersistentDataPath at runtime, per asset if necessary. I saw something on these forums about using IResourceProvider, but I'm not sure how to accomplish this.

2. When building to StreamingAssets, how do you prevent a long list of catalogs getting generated over time every time you build? I'm not using ContentUpdates, and thus no static flags. It would be cleaner if we get one catalog file, sort of how like the AssetBundle manifest file just gets replaced everytime we build.

3. Can the Build step in the Addressables window include an AssetDatabase.Refresh() so we don't have to right-click and do it manually everytime we build to StreamingAssets just to see the results of the build in the Project window?

4. This is minor, but I only need one group for local content, but when building to StreamingAssets, I can't specify anywhere that I don't want a folder created under StreamingAssets called "GroupNameHere_assets_" which the bundles get built under. Is it possible to set that somewhere?

5. When first building AssetBundles via the Addressables window, all my AssetBundle file names were getting appended with a hash. Which setting caused this?

6. Will creating custom build scripts be documented later? For example, setting bundle compression, etc. when using the Build button in the Addressables window.

7. After building AssetBundles via the Addressables Window, Fast Mode and Virtual Mode work correctly, but Packed Mode gives errors saying that there is an Invalid Path in RawDataProvider. Addressables seems to add a "com.unity.addressables" folder to the StreamingAssets path in the console error log, but that folder path is not specified in the Local Build Path. My LocalBuildPath is "Assets/StreamingAssets/", and the LocalLoadPath is "{UnityEngine.AddressableAssets.Addressables.RuntimePath}". How can I resolve this error?

8. Will the upcoming AssetBundles replacement have synchronous loading methods? Will it be usable on its own like AssetBundles, or will it only be usable under the Addressables API?

9. Curious as to why there is an Addressables.Instantiate API when it adds another level of confusion regarding whether to use ReleaseInstance vs. ReleaseAsset. After reading a bunch of forum posts about it, I now understand which to use, but wouldn't it be easier to just keep Addressables to loading and releasing and just using the regular Unity API for instantiating?

Thanks for reading.

 

1. you can use variables in the profile data to have the path be evaluated dynamically at runtime. we actually do this for StreamingAssets currently. The {} in a profile variable get evaluated at runtime. The [] get evaluated at build time.
2. we're working on improving our self-cleanup.
3. not a bad idea. we'll look into it.
4. if the group is set to pack together, you should just get the one bundle. Only if it's on pack separately should you get a folder. I think.
5. we do that on purpose to ensure unique-bundle==unique-file-name. prevents dangerous over writes on a shipped server.
6. yes, custom build scripts is a key area of future improvement. we know it's one of the larger current pain points. Many settings can be set on the group, but not enough.
7. We have some known issues regarding this provider. we'll look into this.
8. the new file format is still quite a ways out, so we don't know all the details, but it will definitely not be restricted to use inside Addressables. I cannot speak to sync/async yet.
9. that depends on your use case. If you just want to spawn something into a scene, then jumping straight to instantiate is great for two reasons: One, no need to do anything OnComplete (just instantiate and forget). Two, the items lifetime matches that of the scene, then you can just leave it, and the release will automatically happen on scene-close (this is undocumented behavior as of 0.5.3, but will be fixed in next release).

thanks for taking the time to look into addressables.
-Bill

 

@unity_bill I've edited this post many many times, so forgive me for that. I've given Addressables another go after a while and was pleasantly surprised to see some of the above issues addressed. However, after some testing, I have more feedback/questions (esp about 4 and 5 from above):

1. Can there be a bool option to not have the unique string of characters be generated at the end of the file names? For example, using the AppendHashToAssetBundleName option. I'm publishing on desktop and am not doing any remote files. With AssetBundles without Addressables, we can have the file names be clean without all the clutter, which is useful for modders and generating file names that are exactly the same as the asset address. This way, modders can create the asset using the same path name as the original, and the new asset will load.

With Addressables, the catalog will not allow loading of the new file, even if it has the exact asset address as well as the exact file name. As of now, the modder would also have to overwrite the catalog, which would mean that it would not be possible to combine different mods together if they all were to overwrite the catalog.

An option to remove the hash would make it a lot easier, as well as the ability for the one catalog to allow loading a replaced Addressable AssetBundle that has the exact same asset address and filename.

2. If a group is set to "pack separately", can we get an option to not have the extra SomeNameHere_assets_ folder generated as a parent to all the files?

3 Can we specify where the catalog.json, link.xml, and settings.json file get copied to when the player is built, rather than for example the aa/Windows folder on Windows?

4. With AssetBundles, we can designate one or many assets to be in the same AssetBundle, but it's more complicated with Addressables. We have to use labels and "pack together by label", which ends up generating files with the name of the group, even for those assets without a label, making it hard to identify what the file contains in a built game. One way around this is creating a lot of groups (like a group for all PBR textures per asset), but with a ton of assets, this gets tedious, especially if you want to change the location of the group (doing it in the group asset rather than in the Addressables window directly). The AssetBundle Browser is more convenient in this respect.

5. I'm getting the impression that while Addressables solves some problems, it introduces more complexity in areas that used to be simple, especially for desktop games that don't access files remotely but have everything in StreamingAssets. Primarily Async only for local desktop introduces more code complexity for little gain, but I guess I can understand the reasoning if this is directed more towards mobile development and hosting assets online. However, there seems to be more ease of customizability using the AssetBundles API directly for local desktop rather than having to use Addressables as a layer on top of it. Even if Unity seems to be pushing towards Addressables for the future, for non-remote local desktop development, would you suggest sticking with AssetBundles only or its eventual replacement? Or do you believe there are advantages to Addressables for this use case?

Edit: 6. The Addressables Profiler seems a little buggy currently. Nothing shows on the profiler unless the "Clear" button is pushed AFTER some Addressables have been loaded.

Edit Again: 7. When setting local build path to Assets/StreamingAssets, let's say I have a texture with some properties getting built there when in the editor and building player content . If I now change a property on the texture, and build player content again, a new file gets created with a different name, whereas I would expect the older one to get overridden as it's not needed. This is how the AssetBundle API works currently, is it possible to do this with Addressables?

Edit A Third Time: 8. It seems like 1, 2, 3, 4, and 7 could all be handled in BundledAssetGroupSchema and BuildScriptPackedMode, is that right? Creating customized versions of each would up the complexity even more as they're not small scripts, especially if the original scripts were to be updated with future versions of Addressables. I'm curious how Addressables developers envision all of this to be handled. The following line of code addresses all the above concerns in one line of code with the AssetBundles API:

BuildPipeline.BuildAssetBundles(Application.streamingAssetsPath, BuildAssetBundleOptions.UncompressedAssetBundle, BuildTarget.StandaloneWindows64);

I'm not sure how to solve the issues without touching schemas and build scripts with Addressables.

 

1. that feature is on our to-do (append hash, no hash, only hash).
2. seems reasonable to have a simplified naming option here. Or perhaps to help with 1 and 2, allow an optional per-bundle callback for you to write your own naming function.
3. Out of curiosity, what do you want this for? Right now you could do it with a custom (inherited) build script.
4. For managing assets, this should be equally easy/painful to the bundle browser. It only breaks down once you want to edit group properties. Right? We do have it on our to-do to support multi-edit of groups. Perhaps that addresses this problem?
5. For one, we will probably not have an AssetBundle file format replacement before DOTS. So it's really a question of pure AssetBundles or the Addressables layer. It sounds like your specific issue is in being async. I will say that we are exploring making a supported sync interface for addressables. I can't promise it yet, but we are exploring it.
6. Thanks for the info. we'll look into that. also, please comment on https://forum.unity.com/threads/what-would-you-like-the-profiler-to-show.712085/
7. So, are you actually setting the path to "Assets/StreamingAssets" or to "[UnityEngine.AddressableAssets.Addressables.BuildPath]/[BuildTarget]"? If it's the first, you shouldn't do that. If it's the latter, I think we clean things up properly there. Maybe we don't. hmm. as I type this I'm having doubts.
8. Now that I've gotten to #8 I realize there's a key detail when talking about "asset bundles" vs "addressables". I've been saying "addressables uses AssetBundles under the hood". But the more apt description is "addressables builds AssetBundles under the hood, using the new scriptable build pipeline, whereas if you've used AssetBundles before, they were built by the engine". So two things. One, if you want to make a custom build script, it should be doable via inheritance to minimize code duplication or lack of future support. Two, SBP significantly improves the asset bundle build. If you did ever decide you didn't want to use addressables, I'd still suggest using SBP. It has a
CompatibilityBuildPipeline that you can use to build bundles the old way, but with the new code.

hope this helps.

 

Hi Bill,

Do you have a timeline on the feature to turn off the hash? This is detrimental on systems that use diff patches.

 

it's been out for a while i think. a month? it's in 1.2.x