Shared State for System Param
- Dominant language
- Rust
- Stars
- 48.2k
- Forks
- 4.8k
- Avg merge
- 3d 16h
- Merged PRs (30d)
- 171
Description
## What problem does this solve or what need does it fill?
Some system params may want to share their state if there are multiple instances of them in the same system.
## What solution would you like?
There should be a way for system params to declare that it wants to share one instance of its state per system.
## What alternative(s) have you considered?
A system param that wants this behavior can implement it on its own without general support for this from bevy itself.
## Additional context
In the upcoming assets-as-entities there is an `AssetCommands` `SystemParam` that wraps `Commands`. If user-code has an `AssetCommands` and a `Commands` in the same system, the order of the commands will not be synced. The general push for things-as-entities will make this problem grow.
```rust
fn system(mut commands: Commands, mut asset_commands: AssetCommands) {
let handle = asset_commands.spawn_asset(/*snip*/);
commands.queue(|world: &mut World| {
use_handle(handle);
// there is currently no guarantee that the asset was actually spawned at this point
});
}
```
A caveat of this is that `Commands` will have to be `!Send` and `!Sync` or take a performance hit by locking a mutex each time a command is queued.
Contributor guide
Research direction
Start by reading the SystemParam and Commands implementations, then inspect how AssetCommands wraps Commands and how World is used in queued commands. Determine the design needed for multiple system-param instances to share one state per system and preserve command ordering. Done means the behavior is supported generally without requiring each system param to implement it independently.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- game-dev
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100