Why doesn't IResourceLocation use uint (or similar value type) as id?

It might be too late to change this but I really think Addressable should store uint or similar value type as the unique identifier, instead of string.

There are many scenario where you would need to maintain a set of loaded assets in a Dictionary (or similarly hash table), and string is not a great key, both in terms of speed and memory: so we end up coming up with an additional uint that maps to each asset, find ways to store them on each asset, and then use them as key after load.

Note that you can still keep all these addresses as string for convenience, I am just saying internally, it should probably be a uint, and it should give us a way to read it.

My suggestion would be to implement them like an auto-increment field in a DB.

1 Like

It took me a while to realize Hash128 was actually used as underlying cache key (which is more than enough to avoid collision).

https://github.com/Unity-Technologies/UnityCsReference/blob/master/Runtime/Export/Hash128.bindings.cs

But annoyingly, it’s only available from the AssetReference, not IAsyncOperation: so if you load your assets using labels, which gives you an IAsyncOperation<IList>, I have no idea how to deduce the Hash128 for each item.

            var prefabOp = await Addressables.LoadAssets<GameObject>(
                label.labelString, null
            );