Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handle multiple loaders with the same filetype when loads disambiguate by asset type parameter #2680

Closed
Neurrone opened this issue Aug 18, 2021 · 4 comments
Labels
A-Assets Load files from disk to use for things like images, models, and sounds C-Feature A new feature, making something new possible

Comments

@Neurrone
Copy link

Bevy version

0.5

Operating system & version

Windows 10

What you did

I'm working on integrating Bevy with the Synthizer audio library. I have 2 assets which I'm creating custom asset loaders for:

  • Buffer for representing buffers of audio data, these are decoded upon load
  • Stream for audio streams. These are decoded on demand, useful for long music tracks and the like

What you expected to happen

Both asset loaders return the same file extensions, because I figured that as long as I disambiguated which one I wanted to use by providing a type parameter to load that it would use the right one.

What actually happened

I registered the asset loader for loading buffers first, then streams. The second one was always chosen.

let h: Handle<Buffer> = asset_server.load("music/main menu.mp3");

I would expect this to correctly use the asset loader for buffers, as the type parameter provides enough information to disambiguate.

Additional information

Any additional information you would like to add such as screenshots, logs, etc.

@Neurrone Neurrone added C-Bug An unexpected or incorrect behavior S-Needs-Triage This issue needs to be labelled labels Aug 18, 2021
@alice-i-cecile alice-i-cecile added A-Assets Load files from disk to use for things like images, models, and sounds and removed S-Needs-Triage This issue needs to be labelled labels Aug 18, 2021
@Neurrone
Copy link
Author

I realized this is the same as #367.

@NiklasEi
Copy link
Member

Looking at #378 (which would have closed this issue), would we still hold off on a merge like that because of a potential move to atelier?

@Neurrone
Copy link
Author

Neurrone commented Aug 19, 2021

It looks like PRs have been raised and not merged due to concerns of building on top of the current system pending an overhaul / migration to a different assets system. However, its already been at least a year since this problem has been reported. So if an overhaul of the assets system is not going to be done soon, I'd appreciate a not ideal but workable solution being available in the meantime.

@alice-i-cecile alice-i-cecile moved this to Wishlist in Asset Pipeline Jul 17, 2022
@alice-i-cecile alice-i-cecile removed the C-Bug An unexpected or incorrect behavior label Jul 17, 2022
@alice-i-cecile
Copy link
Member

Closing in favor of #367 :)

Repository owner moved this from Wishlist to Blocked by a real asset solution in Asset Pipeline Jul 17, 2022
@alice-i-cecile alice-i-cecile added the C-Feature A new feature, making something new possible label Jul 17, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Assets Load files from disk to use for things like images, models, and sounds C-Feature A new feature, making something new possible
Projects
None yet
Development

No branches or pull requests

3 participants