Filesystem watcher fails for assets not in root path

[thargy]

Bevy version

0.5 (Confirmed code same in main branch though)

Operating system & version

Windows 11

What you did

• Loaded asset from an absolute path, which was not under the assets folder, using asset_server.load().
• Called asset_server.watch_for_changes()
• After successful initial load, changed file contents.

What you expected to happen

The asset should reload

What actually happened

Bevy panicked:

thread 'Compute Task Pool (3)' panicked at 'called `Result::unwrap()` on an `Err` value: StripPrefixError(())', ...

at https://github.com/bevyengine/bevy/blob/c5717b5a9124c7c2f7431c4be07f15243ebd60b5/crates/bevy_asset/src/io/file_asset_io.rs#L135

Additional information

The file watcher incorrectly assumes all assets must exist below the assets folder.

[cart]

This is actually an intentional restriction, and it will only get stricter over time as we expand on the asset processing pipeline. Many platforms don't support arbitrary filesystem access and many assets will require expensive pre-processing that should happen prior to app startup. A specific "asset" folder is the only place we can do this properly on all platforms.

The fact that the asset server supports arbitrary non-asset-path loading at all is surprising to me and is something we should reign in.

I do want to support arbitrary asset sources at runtime (ex: raw filesystem, http, etc), but these will not be the "default" or what we recommend to most people.

Can you share a snippet of the asset_server.load() path you're passing in?

[thargy]

The fact that the asset server supports arbitrary non-asset-path loading at all is surprising to me and is something we should reign in.

Ah, OK, I get the logic there. My use case is to allow an arbitrary path to be passed in by the command line. I probably will not use the Asset system for that case then.

Can you share a snippet of the asset_server.load() path you're passing in?

It was just a standard windows path, I have a settings.conf file one level up from assets, e.g. C:\Directory\settings.conf, instead of C:\Directory\assets\settings.conf. It's easy to see why the code panics, as the strip_prefix would always fail in that scenario.

[bjorn3]

I don't think settings should be loaded using the asset server. They are mutable, unlike assets in a production build when not watching for changes. As I understand it distill which may become the asset system of bevy in the future will post-process and pack all assets into an immutable database when building for production. This means that you can't change assets from within the game.

[thargy]

I don't think settings should be loaded using the asset server. They are mutable, unlike assets in a production build when not watching for changes. As I understand it distill which may become the asset system of bevy in the future will post-process and pack all assets into an immutable database when building for production. This means that you can't change assets from within the game.

So the hot loading is really only for development scenarios then? That's not surprising, though the desire to restrict paths during development to the assets folder seems less valid in that scenario (i.e. during development overriding the asset locations to a temporary alternate folder doesn't seem like an unusual use case)?

Anyway, I'm only just learning rust and bevy so WDIK? :shrug:

I do want to support config file loading whilst running, so it's an opportunity for me to dig further into the code. It should probably be a resource, not an asset anyway.

Thanks for the distal link 👍🏻

[cart]

Its worth pointing out that distill adoption isn't a given. I'm still considering alternatives, such as evolving the current asset system. I think "dynamic asset loading" from local filesystems, networks, and in-memory locations is a useful thing to support. Some assets shouldn't be loaded this way due to the runtime costs, but loading config via the asset system seems like a very reasonable thing to do.

We do need a proper "asset processing pipeline" to build some render features we want, so I'll be focusing moving that forward right after Bevy 0.6. Maybe we'll land on distill, maybe we won't :)

[mockersf]

if we want to support separate directory for assets / config / save files / ..., we may want to look into XD Base Directory Specification