Asset V2 log path not reflects custom asset source

[lewiszlw]

Bevy version

5eb292d

What you did

Run cargo run --features="filesystem_watcher" --example asset_processing

What went wrong

I must manually create imported_assets dir in project root then example works.

[cart]

I was wondering why people were hitting this when I never did during development. Its because the ProcessorTransactionLog "imported_assets" path always matched the configured "imported_assets" path for the AssetWriter (which creates this folder automatically).

The asset_processing example changes that path for the AssetWriter, but it doesn't do the same for the ProcessorTransactionLog.

@mockersf it is worth ensuring we create the path if it doesn't exist in the ProcessorTransactionLog, but there is a bigger problem here (a mismatch in configured paths for the imported_assets folder). Currently the fix results in two different imported_assets folders (one at the root of the project and one as a sibling of processing.rs).

We'll want a way to ensure these line up appropriately. I intentionally didn't use the AssetWriter::write API because that is intended for asset storage specifically and the log file is not an asset.

I'll give this some thought. I think the solution is either to couple processor logging to AssetWriter (to ensure things are synced up there), or to have a higher level path interface that feeds into both AssetWriter and some ProcessorTransactionLogWriter interface (or just ProcessorTransactionLog directly in the short term). The former is simpler but increases the scope of AssetWriter beyond assets. The latter adds more abstraction.

[mockersf]

@mockersf it is worth ensuring we create the path if it doesn't exist in the ProcessorTransactionLog, but there is a bigger problem here (a mismatch in configured paths for the imported_assets folder). Currently the fix results in two different imported_assets folders (one at the root of the project and one as a sibling of processing.rs).

Yup, that's why I didn't mark #9716 as fixing this bug. That seemed a much larger fix needed...