ID:1378946
 
Applies to:DM Language
Status: Open

Issue hasn't been assigned a status value.
I would like a way to effectively tell clients to prepare resources for gameplay with a way to report back to the server that the resources are ready. Sending feedback to the server is a critical part of this feature, something I don't think is currently possible with browse_rsc().


What I propose are two procs to get the job done.

client/CacheRsc(resource)
This proc is used to inform clients of any resources which are about to be used. CacheRsc('fireball.dmi') would cause the client to load a fireball icon so it will instantly be displayed on the map when it's used as part of a spell a short time later.

client/CachedRsc(resource)
This is the followup proc, it is similar to a proc like MouseDown() where the developer may passively wait for input from the client and react to it. Each time resources are passed through CacheRsc() they are reported back to the server through CachedRsc() once they are loaded.

Use case example:
- Player is moving from one region to another and is sent to a loading screen.
- A list of resources is prepared, each file is fed through CacheRsc() so the player will load everything.
- As the resources are loaded, they are reported to CachedRsc() while the developer removes each completed resource from the list.
- Once the list of resources to be loaded is empty, the player is moved from the loading screen to the region they were originally moving to.
There's currently no way to report it back, but hide an output panel in the interface somewhere, just make sure it's visible.

send the client the resource via << output(). Honestly, an asyncrhonous method of doing this that causes no stutter though, would be awesome.

This will cut down on stutter later when a large appearance would normally be registered on the client's machine.
There are already many different tricks to loading resources behind the scenes, but that's not what I'm asking for. I want a solid, reliable way of knowing when a client has certain resources loaded and ready.
Definitely, just wanted to offer an immediately available workaround.
This makes a lot of sense, I'd say. When generating new icons on the fly, I think the only way of having the client download it is to display it to them (via the map, output, etc...). If you think about it, this is not the most efficient way to handle it.

In a game, you want the resources that are gonna be displayed to be available before they can possibly appear, to avoid invisible objects, or possibly lag. Imagine an action game where you could get hit with a ball of fire before seeing it?

So yeah, I think this makes sense.
I like this.
The callback approach here is pretty important, and I kind of wish BYOND did it a little more actually.

As a question of usefulness, would you only expect that stuff cached via CacheRsc() triggers CachedRsc(), or would you want other things like browse_rsc() to do so also?
In response to Stephen001
Just for consistency's sake it may be a good idea to only have CacheRsc() report back to the server. Having browse_rsc() do the same probably wouldn't break CachedRsc() as in my example I would just ignore files which aren't in my list of files to be checked, but it's still extra bandwidth and probably an unintended effect for people who don't want to use the feature.
Seems fair, and what I was expecting also.