How to properly load resources on the fly with new resource-loader?

[xTiming]

As of one of the latest versions of Pixi (I'm not sure which as I just recently updated) the version of resource-loader was updated and the old loader functionality which used to just warn the developer was deprecated is now removed entirely.  

In this new version the loader now prevents you from adding new resources to the queue while the loader is running and throws this error:

Quote

Cannot add resources while the loader is running.

For the multiplayer web game I'm currently creating I need to load resources on the fly.

This pattern of loading resources is unpredictable at best as it involves multiple factors: the player changing maps, loading players currently on the map the player enters, players who are already loaded (or not) changing their appearance (the game also features custom appearance graphics the players can upload so I can't just load all appearance files at the beginning), new players entering the level and other events/effects that may result in resources being loaded.

With the previous version of resource-loader I could simply just add each resource to the queue as it is needed and load it directly, or shortly after. However now if for example, a map happens to be added (the player switches maps) as the loader was busy loading a player's appearance from the old level, I get the above error and whatever was trying to add that resource throws an exception.

What is the proper approach to unpredictably loading resources on the fly? Am I missing something and the current approach should actually work? Should I just add an onComplete callback that loops back to a method which is managing a queue of needed resources and load them in batches after each load is completed? Is there another suggested method?

 

Thanks.

[themoonrat]

There are 2 solutions, I think. 

1. Your solution... you don't add directly to the resource loader, but to your own 'queue'. When the resource loader becomes free, you start it again with anything in your existing 'queue', and starting a new queue for any other requests in the meantime.

2. Have a pool of resource loaders... you just use the first free one. They're very lightweight, so no harm having more than one, as long as you're ok with potentially more simultaneous assets being downloaded at the same time

[xTiming]

On 5/10/2017 at 1:04 PM, themoonrat said:

There are 2 solutions, I think. 

1. Your solution... you don't add directly to the resource loader, but to your own 'queue'. When the resource loader becomes free, you start it again with anything in your existing 'queue', and starting a new queue for any other requests in the meantime.

2. Have a pool of resource loaders... you just use the first free one. They're very lightweight, so no harm having more than one, as long as you're ok with potentially more simultaneous assets being downloaded at the same time

I actually like the second idea more since I can also do some scaling with that based on the user's speed/connection eventually.

My current design for my ResourceManager looks something like this, for anyone who may stumble on this looking for help:

- A queue of pending resources to be loaded.

- A statically sized pool of loaders.

- The ResourceManager has its own add and load functions. The add function simply adds the pending resource to the queue. The load function attempts to load everything in the queue with a loader from the pool.

- If no loader in the pool is currently available, a "waiting for loader" flag is set to true and pending resources wait in the queue.

- Once a loader returns from the loading process (via callback to my ResourceManager's onComplete function using loader.onComplete.add), if the flag is set to true and the queue has resources in it, the loader will immediately start the loading process again using the resources in the queue, otherwise it will set the flag to false, return to the loader pool, and await a new load call.

Seems like this should solve my problem with minimal speed issues. If I remember I may report back here after testing (I'm not sure when I'll be able to tackle this due to other obligations).

Thanks for the help @themoonrat!

[themoonrat]

Sound like a plan to me, would definitely be interested to know how it goes (if you remember )