#Generic Addressable Loading and Operation Handles

1 messages · Page 1 of 1 (latest)

tough ridge
#

Heyo, trying to create a generic assetDatabase / addressables loading scheme, where i can give the loader a type that extends a interface, and stores the handles generated for unloading. Problem is that the handles given back dont seem to be able to be cast as the type, or added to any list of handles, even a <object> list. How do you store generic handles so you can dispose of them later?

i do understand that you cant have a type of IList<T>, but to be able to load a certain type, i cannot just pass IData, i need to pass the specific class implementing IData. when I use a class T implementing IData, the Async returns a concrete IList<T> that cannot be casted and cannot be used as a type either lol

Just Looking for a way to have a single handle for a list/group of assets, then be able to store that handle with other, related handles to be able to dispose of them together.

Code: https://paste.ofcode.org/PRsaH3SWE9dR79mPrtumHP

#

as a second consideration, i could load the entire label group as 1 handle, but that wastes memory, since i dont always need all parts of the label group at one time.

daring ocean
#

The rules for when we can cast generic types are defined by covariance and contravariance:
https://learn.microsoft.com/en-us/dotnet/standard/generics/covariance-and-contravariance

However why make a pointless layer on top of addressables? You should just load assets where needed and release them there to.

Covariance and Contravariance in Generics - .NET

Learn about covariance, which allows you to use a more derived type, and contravariance, which allows you to use a less derived type, in .NET generics.

#

And to expand on this. IList<T> is covariant because it provides read only access.
A List or other collection cannot safely do this as it is mutable

tough ridge
#

The layer is so i'm able to reference the loaded assets by a SerializableGUID, as its baked data that other places can all acess. the layer isnt to override the addressables, but just to make them acessable to different areas that all need them.

#

its the same idea as an item database, the items are loaded into a dictionary, and the things that need them ask for them by SerializableGUID.

#

the assets are grouped by a label, which is for all data related to a certain entity, and theres a couple different loaded SOs that are used for different purposes related to the entity.

#

I want to be able to assign procedurally an id for each loadable asset when making the data, but if using them directly is the way to go, then i might need to redesign how i store the info to be able to get the data from addressables.

daring ocean
#

I myself in quite a few projects did just fine configuring the address of some asset with my data

#

You can access and modify addressable entries in editor code so its not hard to automatically change this data both sides

tough ridge
#

I did not know the addresses for the addressables were able to be gotten / modified. i will look into the addressable as a storage.

i know i want the handles to be loaded by a parent object that activates when the player is in a stage where the data may be used soon, and the handles are disposed by the parent when it deactivates, and the uses can rely on the data being already present. but i may need to switch stuff up a bit myself.

daring ocean
#

e.g.

Sprite s = await Addressables.LoadAssetAsync<Sprite>("CoolSprites[foo]");
Addressables.Release(s);
tough ridge
#

Thats great! i was worried about having to store the handles. Now that i look at how im creating the assetEntries, i can defo assign a string address. i'm still a bit, annoyed, at having to use string ids, even though under the hood they probably use guids/ 128-bit ints, but I wont take anymore of your time, and figure out a compromise.