Closed stinkytoe closed 9 months ago
It sounds very reasonable to wait for dependencies to load.
I shortly looked into this and it seems I do not have access to the dependencies where I would need to. The only place I could find that makes use of them is the asset server itself.
Honestly when compiled with --release there is very little time between when my custom ldtk loader finishes, and the images finish loading. In debug builds, it takes like five seconds though (on my system without dynamically linking bevy).
So I think it would be a great feature to have, and could also be argued to be the "correct" way. But, considering the unsupported and undocumented nature of custom asset loaders, I could totally understand if this was a low priority at this time.
Thanks for looking into it!
In my opinion the priority is pretty high. There is just little I can do in the plugin itself, since Bevy does not expose the dependencies.
Without bevyengine/bevy#5297 I can only think of ugly workarounds, that would require the asset loaders to somehow tell bevy_asset_loader about their dependencies. And those wouldn't even work with "standard" loaders like Bevy's GLTF loader.
This can be implemented as soon as bevyengine/bevy#8624 lands (Bevy 0.12
in around 3 months).
The latest version waits until a handle and all it's dependencies are loaded.
Here's an example: I use a custom loader for ldtk map files which loads and parses the ldtk file, and provides it as an asset to Bevy. I also load all of the images used for sprites/backgrounds/tiles/etc when I do this, and use the LoadedAsset::with_dependencies(...) member to add them as dependencies to my ldtk asset.
When I register this asset using an AssetCollection, as described in your readme, it seems to be correctly waiting on the ldtk file itself to load. However, it does not wait on all of the referenced images.
I will look at creating a dynamic asset description when constructing the asset, or simply adding the images separately. It would be a nice feature if your crate could detect this, however, due to the fact that the ldtk user could change what images they utilize at any time.
I don't know of other examples of assets with dependencies, but I imagine they could take advantage of this feature as well.