Allow "named" assets and overriding "names"

[huhlig]

What problem does this solve or what need does it fill?

Currently only assets loaded by AssetServer::load have names and it's fixed as the name of the path. Looking up a loaded assets is as simple as calling load a second time. However assets that are created don't have this luxury thus requiring custom cataloging of handles to provide lookup.

What solution would you like?

Add new methods

AssetServer::get_handle_by_name(name: &str) -> Option<Handle<T>>;
Assets::get_handle_by_name(name: &str) -> Option<Handle<T>>;
Assets::add_as(name: &str, asset: T) -> Handle<T>;

What alternative(s) have you considered?

Adding custom catalog for assets. This while doable seems like an anti-pattern as all handles will need to be cloned into the catalog.

[mockersf]

The way it's down to get the same handle from a path is that the handle is derived from the path directly.

If we add handle-derived-from-name, what happens if I use the same name for different assets? New one rejected, or old ones now point to new asset?

Should a named asset be cleaned if there are no current strong handle to it, even though the user could still recreate an handle?

[huhlig]

Currently we already have handles by name, the name is just fixed from the path when it's loaded, and technically if we have multiple asset packs we would have the same issue.

[mockersf]

Path are specials in that they represent a link to the original file, so:

• If hot reloading is enable, asset change with the file. if not, it doesn't. Do we want to mimic hot reloading with names?
• If we don't have a strong handle to an asset, it is cleaned, but we can recreate it the next time the game tries to load it by path, as it has the path. that's not possible by name, unless we keep all named asset around and disable cleanup for them

Also, for the method on asset server: AssetServer::get_handle_by_name(name: &str) -> Handle<T>;: if the user never adds the name through the Assets::add_as methods, it will returns an handle that will never resolve.

[huhlig]

You're right, it should return Option::None