Feedback Addressables is still not production ready in 2022.

This is kind of a rant.

I've given Addressables another chance this year to see if it fits the requirements of our project. I've seen they've added the sync API finally and thought maybe I don't have to build a whole asset system by myself while we're already trying to develop a game? I was so wrong.

First, it's still the worst API I've seen from Unity. Every method takes an 'object' parameter, why are you breaking type safety so badly? You could just have method overloads instead. Why can I use 'AssetReferenceSprite' and I can call LoadAsset<GameObject> on it?

It's really clear that Unity didn't try to release anything half-serious with this. I'm trying to download catalogs but I can't get download progression or total size of the download, or any serious information about the catalog I'm downloading. This is like the most basic thing all developers need.

This system is being developed for years and if these features are still missing, we can't count on them getting released later. It's not like I'm the first person asking for 'how do I do x with catalogs?'

I wonder why is this package marked as release?

 

I saw that Unity are planning to rename the package to "Runtime Asset Management". I wouldn't mind if they completely create a new system from scratch, keep the current Addressables version so that old projects could continue to use it. As you mentioned, breaking the type safety is the first mistake, it makes the APIs very sketchy. Also, I found it hard to understand the architecture of the Addressables' source code. All methods are all mixed together. Apart from the bugs, there are also some missing features which are urgently needed, for example, the ability to abort a loading process, building only a specific group for DLC etc.

 

I don't have a single good thing to say about addressables. I'm posting out of frustration of having my project stalled to a halt for two years now because addressables get in the way, in every possible way, on every possible occasion.

- The API is a terrible, frustrating, overabstracted, unreadable, anti-KISS, anti-YAGNI, undocumented, unworkable mess.

Code (CSharp):

1. namespace UnityEngine.ResourceManagement.ResourceLocations
2. {
3.     /// <summary>
4.     /// Contains enough information to load an asset (what/where/how/dependencies)
5.     /// </summary>
6.     public interface IResourceLocation
7.     {
8.         /// <summary>
9.         /// Internal name used by the provider to load this location
10.         /// </summary>
11.         /// <value>The identifier.</value>
12.         string InternalId { get; }
13.  
14.         /// <summary>
15.         /// Matches the provider used to provide/load this location
16.         /// </summary>
17.         /// <value>The provider id.</value>
18.         string ProviderId { get; }
19.  
20.         /// <summary>
21.         /// Gets the dependencies to other IResourceLocations
22.         /// </summary>
23.         /// <value>The dependencies.</value>
24.         IList<IResourceLocation> Dependencies { get; }
25.  
26.         /// <summary>
27.         /// The hash of this location combined with the specified type.
28.         /// </summary>
29.         /// <param name="resultType">The type of the result.</param>
30.         /// <returns>The combined hash of the location and the type.</returns>
31.         int Hash(Type resultType);
32.  
33.         /// <summary>
34.         /// The precomputed hash code of the dependencies.
35.         /// </summary>
36.         int DependencyHashCode { get; }
37.  
38.         /// <summary>
39.         /// Gets the dependencies to other IResourceLocations
40.         /// </summary>
41.         /// <value>The dependencies.</value>
42.         bool HasDependencies { get; }
43.  
44.         /// <summary>
45.         /// Gets any data object associated with this locations
46.         /// </summary>
47.         /// <value>The object.</value>
48.         object Data { get; }
49.  
50.         /// <summary>
51.         /// Primary address for this location.
52.         /// </summary>
53.         string PrimaryKey { get; }
54.  
55.         /// <summary>
56.         /// The type of the resource for th location.
57.         /// </summary>
58.         Type ResourceType { get; }
59.     }
60. }

(no comment)

- The configuration is a mess. Every time they didn't know which design decision to make, they just went both ways and exposed a configuration setting. But not that you can configure it in a way that you want it to work either. Nothing works out of the box, and getting things to work is an endless struggle.
- AssetReferenceT<TObject> (what? (what? (?????)))
- The performance is a mess. On the editor/UI side, on the build side and on the runtime side. Iteration times on my tiny project are... what? Iteration times? There is no iteration with addressables. I am writing this post while my project builds; 45 minutes in so far, but no need to hurry, I have plenty of time. At least the writing experience is nice and smooth because the build process is using 1% of my CPU. (Update: my build failed with error Cannot recognize file type for entry located at..., I didn't even notice it for hours because addressables didn't clear the progress bar. I guess it's debugging time!)
- The whole thing is drowned in bugs. Don't ask me to report them, I'm convinced this mess is unfixable. The kinds of bugs I ran into here over the last two years make me want to laugh and cry at the same time. When addressables inevitably run into an unhandled exception during build, they hide the stack trace so that you can't even debug it without modifying the package. Ever heard of

Debug.LogException

? The addressables team hasn't.

At this point I'm convinced addressables are completely unusable for small teams. The only way to deal with this package is to have dedicated engineers who work exclusively on solving addressables issues. And I'm working on a simple, small, undemanding project here - I can't imagine what using addressables on a large project must be like.

I'm sorry, but this package is responsible for wasting so much of my time, I just don't have patience to play nice and pretend this is OK any more. To anyone considering addressables for their project: try reading the package code first, I think it will help you come to an informed decision.

 

I've started building my own solution on top of AssetBundles. It's very similar to Addressables actually since the initial idea is great (load Asset by address, whereever it is), but I'm building more a restrictive API (type safe AssetReferences, an address is unique and only one object can have it, no Async since it's hard to handle by developers), and of course the code is clean, unlike whatever they're trying to do with Addressables.

 

I struggled with Addressables for about a year too. Didn't see Unity Technologies being able to resolve those issues.

It was a very frustrating situation. We're using it for a commercial game where paying customers had significant issues caused by Addressables. Beside submitting many bug-reports, they didn't tackle the real problems

I believe Addressables is pretty much broken beyond repair. I also believe the developers don't even understand the overly complex code-base anymore, otherwise I can't explain of why it's not production ready.

In the end we dropped the entire "remote functionality" from Addressables and use it for basic loading only.

https://forum.unity.com/threads/my-...nd-questions-collection.1135966/#post-8246757

 

The "local functionality" is also not entirely safe as well... As you mentioned in other thread, the local setting.json file sometimes fails to be loaded, which causes the player not able to play the game. We cannot reproduce it, we can only stare at those 1-star reviews.

 

If anyone is reading this in the future, we've finished our custom solution a long time ago, and it was definitely worth it. If your project is serious and has complicated asset requirements I'd recommend building a system on top of asset bundles.

 

Yeah i decided to use addressables in a mobile app im building, its really put a lot of stress on the project and its hard to undo now as we have already put a release out using it. We use it for DLC, but it doesnt actually work at all, it seems to just brake the project whenever we build new remote addressables. Im constantly having to find solutions/workarounds for it. I honestly wish i hadnt used it at all, but its too late now.

 

My recommendation when it comes to Addressables is: If it is suitable enough for you in its current form and you are capable of digging in and modifying it, either to fix issues or just to customise it to your needs, you can consider it. Otherwise, don't use it.

 

Thank you for this! After reading the Unity manual, API docs and this thread, I was still unsure about integrating Addressables into my project, not knowing if it would later come back and bite me... Especially since I do not have time to create dummy projects just for stress-testing engine features. We shouldn't have to test engine features...

You helped me decide the most, as your comment seems to come very heartfelt. Of course I am very sorry to read that you are struggling like that, and wish you only the best for your project nonetheless! But surely I'll now skip on Addressables altogether. Cheers, and have a great summer everyone!

 

Hi, just wanted to be clear about something, addressables for simple stuff can be great. I think the system is actually a step in the right direction, the issue is with the implementation. If your use case is Remote Content which is nothing more than a 3D Object or Mp3 that works as a standalone thing, then you are absolutely fine.

My main issue with the way addressables works is the catalog situaction. Addressables gets built into a single catalog that your app loads, if your app contains local addressables and remote addressables and you need to add a new DLC to the mix, but you have made a bunch of app changes also, you might think your okay just to simple add a new addressables into the existing catalog easilly. This is not an option, all addressables are required to be rebuilt. So if you have made other changes aside from the DLC you are adding, your going to hit a wall as it does NOT work this way. You would have to have a repo for each release. Otherway of doing is to have your DLC in a seperate Unity project so you can built multiple catalogs and load each one is, but this does not work for us as our Prefabs (DLC) contains scripts which dont exist in the 2nd project and im having difficulty loading them like this. So its all down to use case, i dont have the time to develop on top of the system. So my solution now is im actually reworking my entire app so it can use addressables in its simplest way and have all DLC in its own unity project so i can update all previous versions of my app with same DLC and not have to produce DLC for each version out there. It becomes a mess.

 

Thanks! It's true, on top of the sheer complexity of Addressables it doesn't help that the big topic of versioning comes creeping in...
It would probably be healthy to know most of the data structures early in a project and extract those into ScriptableObjects, but then again... Not everyone is lucky enough to have stable data schemas and method signatures throughout the entirety of a development lifecycle. Thanks again for your comment and good luck with your project!

 

Perhaps it might not fully cover your usecase, but I maintain a repo that extends Addressables with the option of external catalogs, which is ideal for traditional DLC purposes. It does, however, explicitly not cover remote catalog/assets. If you require that in your app, then it's still not usable unfortunately.

Link to repo: https://github.com/juniordiscart/com.unity.addressables

 

Entities package has its own content management system which will likely waste the effort we put on this time-consuming management of Addressables meshes, materials, textures, prefabs, and shaders in 3D environment.