 dcc03724a5
			
		
	
	
		dcc03724a5
		
	
	
	
	
		
			
			# Objective NOTE: This depends on #7267 and should not be merged until #7267 is merged. If you are reviewing this before that is merged, I highly recommend viewing the Base Sets commit instead of trying to find my changes amongst those from #7267. "Default sets" as described by the [Stageless RFC](https://github.com/bevyengine/rfcs/pull/45) have some [unfortunate consequences](https://github.com/bevyengine/bevy/discussions/7365). ## Solution This adds "base sets" as a variant of `SystemSet`: A set is a "base set" if `SystemSet::is_base` returns `true`. Typically this will be opted-in to using the `SystemSet` derive: ```rust #[derive(SystemSet, Clone, Hash, Debug, PartialEq, Eq)] #[system_set(base)] enum MyBaseSet { A, B, } ``` **Base sets are exclusive**: a system can belong to at most one "base set". Adding a system to more than one will result in an error. When possible we fail immediately during system-config-time with a nice file + line number. For the more nested graph-ey cases, this will fail at the final schedule build. **Base sets cannot belong to other sets**: this is where the word "base" comes from Systems and Sets can only be added to base sets using `in_base_set`. Calling `in_set` with a base set will fail. As will calling `in_base_set` with a normal set. ```rust app.add_system(foo.in_base_set(MyBaseSet::A)) // X must be a normal set ... base sets cannot be added to base sets .configure_set(X.in_base_set(MyBaseSet::A)) ``` Base sets can still be configured like normal sets: ```rust app.add_system(MyBaseSet::B.after(MyBaseSet::Ap)) ``` The primary use case for base sets is enabling a "default base set": ```rust schedule.set_default_base_set(CoreSet::Update) // this will belong to CoreSet::Update by default .add_system(foo) // this will override the default base set with PostUpdate .add_system(bar.in_base_set(CoreSet::PostUpdate)) ``` This allows us to build apis that work by default in the standard Bevy style. This is a rough analog to the "default stage" model, but it use the new "stageless sets" model instead, with all of the ordering flexibility (including exclusive systems) that it provides. --- ## Changelog - Added "base sets" and ported CoreSet to use them. ## Migration Guide TODO
		
			
				
	
	
		
			62 lines
		
	
	
		
			2.2 KiB
		
	
	
	
		
			Rust
		
	
	
	
	
	
			
		
		
	
	
			62 lines
		
	
	
		
			2.2 KiB
		
	
	
	
		
			Rust
		
	
	
	
	
	
| //! This example shows how you can know when a `Component` has been removed, so you can react to it.
 | |
| 
 | |
| use bevy::prelude::*;
 | |
| 
 | |
| fn main() {
 | |
|     // Information regarding removed `Component`s is discarded at the end of each frame, so you need
 | |
|     // to react to the removal before the frame is over.
 | |
|     //
 | |
|     // Also, `Components` are removed via a `Command`, which are not applied immediately.
 | |
|     // So you need to react to the removal at some stage after `apply_system_buffers` has run,
 | |
|     // and the Component` is removed.
 | |
|     //
 | |
|     // With these constraints in mind we make sure to place the system that removes a `Component` in
 | |
|     // `CoreSet::Update', and the system that reacts on the removal in `CoreSet::PostUpdate`.
 | |
|     App::new()
 | |
|         .add_plugins(DefaultPlugins)
 | |
|         .add_startup_system(setup)
 | |
|         .add_system(remove_component)
 | |
|         .add_system(react_on_removal.in_base_set(CoreSet::PostUpdate))
 | |
|         .run();
 | |
| }
 | |
| 
 | |
| // This `Struct` is just used for convenience in this example. This is the `Component` we'll be
 | |
| // giving to the `Entity` so we have a `Component` to remove in `remove_component()`.
 | |
| #[derive(Component)]
 | |
| struct MyComponent;
 | |
| 
 | |
| fn setup(mut commands: Commands, asset_server: Res<AssetServer>) {
 | |
|     commands.spawn(Camera2dBundle::default());
 | |
|     commands.spawn((
 | |
|         SpriteBundle {
 | |
|             texture: asset_server.load("branding/icon.png"),
 | |
|             ..default()
 | |
|         },
 | |
|         // Add the `Component`.
 | |
|         MyComponent,
 | |
|     ));
 | |
| }
 | |
| 
 | |
| fn remove_component(
 | |
|     time: Res<Time>,
 | |
|     mut commands: Commands,
 | |
|     query: Query<Entity, With<MyComponent>>,
 | |
| ) {
 | |
|     // After two seconds have passed the `Component` is removed.
 | |
|     if time.elapsed_seconds() > 2.0 {
 | |
|         if let Some(entity) = query.iter().next() {
 | |
|             commands.entity(entity).remove::<MyComponent>();
 | |
|         }
 | |
|     }
 | |
| }
 | |
| 
 | |
| fn react_on_removal(mut removed: RemovedComponents<MyComponent>, mut query: Query<&mut Sprite>) {
 | |
|     // `RemovedComponents<T>::iter()` returns an iterator with the `Entity`s that had their
 | |
|     // `Component` `T` (in this case `MyComponent`) removed at some point earlier during the frame.
 | |
|     for entity in &mut removed {
 | |
|         if let Ok(mut sprite) = query.get_mut(entity) {
 | |
|             sprite.color.set_r(0.0);
 | |
|         }
 | |
|     }
 | |
| }
 |