How to convert Resources.LoadAll to Addressables?

Question

I have been advised to move away from the Resources system to the new Addressables system, which seems to have many advantages.

I need to convert the following code to use the Addressables:

public static void LoadDefs()
{
    foreach (var baseTileType in Resources.LoadAll(Settings.BASE_TILES_PATH, typeof(TextAsset)))
    {
        var baseTile = Deserializer.Deserialize<BaseTile.Initializer>(((TextAsset) baseTileType).text);
        BaseTileInstances.Add(baseTile.Name, baseTile.CreateInstance());
    }

}

It is important for me to detect the type of TextAsset because those are .yaml files that I need to load the information from. Then, derived from information in that YAML file, I load sprites that I need with Resources.Load<Sprite>(path) later, but that should be simple.

The documentation is pretty unclear on how to do this. It mentions labels, but not much else.

How can I achieve a similar result with this new system?

Answer 1

I've managed to come up with a basic solution for the following problem. Here's an example of needing to load and store sprites:

1. Add your addressables into a group and label them accordingly. In my case, "pictures".

2. Add the code.

   public static readonly Dictionary<string, Sprite> AllSprites = new Dictionary<string, Sprite>();
   
   public static async Task InitSprites(string assetLabel)
   {
       var locations = await Addressables.LoadResourceLocationsAsync(assetLabel, typeof(Sprite)).Task;
       List<Task<Sprite>> tasks = new List<Task<Sprite>>();
   
       foreach (var location in locations)
       {
           tasks.Add(Addressables.LoadAssetAsync<Sprite>(location).Task);
       }
   
       var loadedSprites = await Task.WhenAll(tasks);
   
       foreach (var sprite in loadedSprites)
       {
           AllSprites.Add(sprite.name, sprite);
       }
   }
   

You may call InitSprites from any async method. For example, you can define a public static async void Load() method, which you call from the Start() method in your GameManager singleton.

Then, inside of that, call await InitSprites("pictures"). This will asynchronously load and store your sprites wherever you need (in my case, a dictionary).

3. Modify

You can get this code to work with any asset type. All you have to do is to replace the typeof() parameter with your desired type. You can even write typeof(object) and then store it into a List<object>. That way, one list can hold ALL of your assets of various types, which you can then use however you like.

Answer 2

No idea if this is more or less efficient than the OPs solution, but here is my take on the same problem. In my case, I have lots of different data types that derive from scriptable objects that I loaded by type into lists at runtime using Resources.LoadAll(). Some have prefabs which means they have dependencies thus making the main data payload quite large (project is WebGL), so moving these out of resources to load from addressables was critical. Like OP, I organize the Addressable assets with labels and groups. Instead of using System.Threads.Task I'm using the familiar Monobehaviour Coroutine, because, well, I'm familiar with it :)

IEnumerator  LoadAssetsAsync<T>(string label, List<T> list, System.Type type)
    {
        yield return null;
        AsyncOperationHandle<IList<IResourceLocation>> handle = Addressables.LoadResourceLocationsAsync(label, type);
        yield return handle;

        for(int i = 0; i < handle.Result.Count; i++)
        {
            StartCoroutine (LoadAssetAsync<T>(handle.Result[i], list));
        }
        Addressables.Release(handle);
    }

    IEnumerator LoadAssetAsync<T>(IResourceLocation location, List<T> list)
    {
        var handle = Addressables.LoadAssetAsync<T>(location);
        yield return handle;
        list.Add(handle.Result);
    }

And it gets called like so:

List<Foo> foos = new List<Foo>(); //Foo can be anything

void OnGameAwake()
    {
        StartCoroutine(LoadAssetsAsync<Foo>("Foo", foos, typeof(Foo)));
    }

Probably just a dumber way of restating the OPs solution, but it works...