-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
Locals in exclusive systems #3946
Changes from 4 commits
9e67da3
3667ac4
5912dd5
b7ff9a4
87c335b
7f833c9
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -3,6 +3,7 @@ mod spawn_batch; | |
mod world_cell; | ||
|
||
pub use crate::change_detection::Mut; | ||
use bevy_ecs_macros::all_tuples; | ||
pub use entity_ref::*; | ||
pub use spawn_batch::*; | ||
pub use world_cell::*; | ||
|
@@ -1224,6 +1225,25 @@ impl<T: Default> FromWorld for T { | |
} | ||
} | ||
|
||
/// Wrapper type to enable getting multiple [`FromWorld`] types in one type. | ||
/// | ||
/// This wrapper is necessary because a [`FromWorld`] implementation for a tuple of | ||
/// [`FromWorld`] implementing types would conflict with the [`FromWorld`] impl over all | ||
/// [`Default`] type. | ||
pub struct FromWorldWrap<T>(pub T); | ||
|
||
macro_rules! impl_from_world { | ||
($($t:ident),*) => { | ||
impl<$($t: FromWorld,)*> FromWorld for FromWorldWrap<($($t,)*)> { | ||
fn from_world(_world: &mut World) -> Self { | ||
FromWorldWrap(($($t::from_world(_world),)*)) | ||
} | ||
} | ||
}; | ||
} | ||
|
||
all_tuples!(impl_from_world, 0, 12, T); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. same |
||
|
||
struct MainThreadValidator { | ||
main_thread: std::thread::ThreadId, | ||
} | ||
|
Original file line number | Diff line number | Diff line change | ||||
---|---|---|---|---|---|---|
@@ -0,0 +1,57 @@ | ||||||
use bevy::{ | ||||||
ecs::system::{lifetimeless::*, SystemState}, | ||||||
prelude::*, | ||||||
}; | ||||||
|
||||||
fn main() { | ||||||
App::new() | ||||||
.init_resource::<MyCustomSchedule>() | ||||||
.insert_resource(5u32) | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Use wrapper types, even in examples. |
||||||
.add_system(simple_exclusive_system.exclusive_system()) | ||||||
.add_system(stateful_exclusive_system.exclusive_system()) | ||||||
.run(); | ||||||
} | ||||||
|
||||||
#[derive(Default)] | ||||||
struct MyCustomSchedule(Schedule); | ||||||
|
||||||
#[derive(Component)] | ||||||
struct MyComponent; | ||||||
|
||||||
/// Just a simple exclusive system - this function will run with mutable access to | ||||||
/// the main app world. This lets it call into other schedules, or modify and query the | ||||||
TheRawMeatball marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||
/// world in hard-to-predict ways, which makes it a powerful primitive. However, because | ||||||
/// this is usually not needed, and because such wide access makes parallelism impossible, | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Explain why not -> should be avoided when not needed. |
||||||
/// it should generally be avoided. | ||||||
fn simple_exclusive_system(world: &mut World) { | ||||||
world.resource_scope(|world, mut my_schedule: Mut<MyCustomSchedule>| { | ||||||
// The resource_scope method is one of the main tools for working with &mut World. | ||||||
// This method will temporarily remove the resource from the ECS world and let you | ||||||
// access it while still keeping &mut World. A particularly popular pattern is storing | ||||||
// schedules, stages, and other similar "runnables" in the world, taking them out | ||||||
// using resource_scope, and running them with the world: | ||||||
my_schedule.0.run(world); | ||||||
// This is fairly simple, but you can implement rather complex custom executors in this manner. | ||||||
}); | ||||||
} | ||||||
|
||||||
/// While it's usually not recommended due to parallelism concerns, you can also use exclusive systems | ||||||
/// as mostly-normal systems but with the ability to change parameter sets and flush commands midway through. | ||||||
fn stateful_exclusive_system( | ||||||
world: &mut World, | ||||||
mut part_one_state: Local<SystemState<(SRes<u32>, SCommands)>>, | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Unfortunately the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Oh no. Please leave a comment explaining this then. That surprises me a lot though; I request standard There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't think the problem is the systemstate api; it's that the That is, the issue is |
||||||
mut part_two_state: Local<SystemState<SQuery<Read<MyComponent>>>>, | ||||||
TheRawMeatball marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||
) { | ||||||
let (resource, mut commands) = part_one_state.get(world); | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Oh fascinating: this "just works" without initial values because of the |
||||||
let res = *resource as usize; | ||||||
commands.spawn_batch((0..res).map(|_| (MyComponent,))); | ||||||
|
||||||
// Don't forget to apply your state, or commands won't take effect! | ||||||
part_one_state.apply(world); | ||||||
let query = part_two_state.get(world); | ||||||
let entity_count = query.iter().len(); | ||||||
// note how the entities spawned in this system are observed, | ||||||
// and how resources fetched in earlier stages can still be | ||||||
// used if they're cloned out, or small enough to copy out. | ||||||
assert_eq!(entity_count, res); | ||||||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would rather have all all_tuples work on the same maximum number of items in a tuple, so 16. It would be less surprising for users