Trait bevy::prelude::IntoSystemSetConfigs
pub trait IntoSystemSetConfigs: Sized {
// Provided methods
fn in_set(self, set: impl SystemSet) -> NodeConfigs<Interned<dyn SystemSet>> { ... }
fn before<M>(
self,
set: impl IntoSystemSet<M>
) -> NodeConfigs<Interned<dyn SystemSet>> { ... }
fn after<M>(
self,
set: impl IntoSystemSet<M>
) -> NodeConfigs<Interned<dyn SystemSet>> { ... }
fn before_ignore_deferred<M>(
self,
set: impl IntoSystemSet<M>
) -> NodeConfigs<Interned<dyn SystemSet>> { ... }
fn after_ignore_deferred<M>(
self,
set: impl IntoSystemSet<M>
) -> NodeConfigs<Interned<dyn SystemSet>> { ... }
fn run_if<M>(
self,
condition: impl Condition<M>
) -> NodeConfigs<Interned<dyn SystemSet>> { ... }
fn ambiguous_with<M>(
self,
set: impl IntoSystemSet<M>
) -> NodeConfigs<Interned<dyn SystemSet>> { ... }
fn ambiguous_with_all(self) -> NodeConfigs<Interned<dyn SystemSet>> { ... }
fn chain(self) -> NodeConfigs<Interned<dyn SystemSet>> { ... }
fn chain_ignore_deferred(
self
) -> NodeConfigs<Box<dyn System<Out = (), In = ()>>> { ... }
}Expand description
Types that can convert into a SystemSetConfigs.
Provided Methods§
fn in_set(self, set: impl SystemSet) -> NodeConfigs<Interned<dyn SystemSet>>
fn in_set(self, set: impl SystemSet) -> NodeConfigs<Interned<dyn SystemSet>>
Add these system sets to the provided set.
fn before<M>(
self,
set: impl IntoSystemSet<M>
) -> NodeConfigs<Interned<dyn SystemSet>>
fn before<M>( self, set: impl IntoSystemSet<M> ) -> NodeConfigs<Interned<dyn SystemSet>>
Runs before all systems in set. If self has any systems that produce Commands
or other Deferred operations, all systems in set will see their effect.
If automatically inserting apply_deferred like
this isn’t desired, use before_ignore_deferred instead.
fn after<M>(
self,
set: impl IntoSystemSet<M>
) -> NodeConfigs<Interned<dyn SystemSet>>
fn after<M>( self, set: impl IntoSystemSet<M> ) -> NodeConfigs<Interned<dyn SystemSet>>
Runs before all systems in set. If set has any systems that produce Commands
or other Deferred operations, all systems in self will see their effect.
If automatically inserting apply_deferred like
this isn’t desired, use after_ignore_deferred instead.
fn before_ignore_deferred<M>(
self,
set: impl IntoSystemSet<M>
) -> NodeConfigs<Interned<dyn SystemSet>>
fn before_ignore_deferred<M>( self, set: impl IntoSystemSet<M> ) -> NodeConfigs<Interned<dyn SystemSet>>
Run before all systems in set.
Unlike before, this will not cause the systems in set to wait for the
deferred effects of self to be applied.
fn after_ignore_deferred<M>(
self,
set: impl IntoSystemSet<M>
) -> NodeConfigs<Interned<dyn SystemSet>>
fn after_ignore_deferred<M>( self, set: impl IntoSystemSet<M> ) -> NodeConfigs<Interned<dyn SystemSet>>
Run after all systems in set.
Unlike after, this may not see the deferred
effects of systems in set to be applied.
fn run_if<M>(
self,
condition: impl Condition<M>
) -> NodeConfigs<Interned<dyn SystemSet>>
fn run_if<M>( self, condition: impl Condition<M> ) -> NodeConfigs<Interned<dyn SystemSet>>
Run the systems in this set(s) only if the Condition is true.
The Condition will be evaluated at most once (per schedule run),
the first time a system in this set(s) prepares to run.
fn ambiguous_with<M>(
self,
set: impl IntoSystemSet<M>
) -> NodeConfigs<Interned<dyn SystemSet>>
fn ambiguous_with<M>( self, set: impl IntoSystemSet<M> ) -> NodeConfigs<Interned<dyn SystemSet>>
Suppress warnings and errors that would result from systems in these sets having ambiguities
(conflicting access but indeterminate order) with systems in set.
fn ambiguous_with_all(self) -> NodeConfigs<Interned<dyn SystemSet>>
fn ambiguous_with_all(self) -> NodeConfigs<Interned<dyn SystemSet>>
Suppress warnings and errors that would result from systems in these sets having ambiguities (conflicting access but indeterminate order) with any other system.
fn chain(self) -> NodeConfigs<Interned<dyn SystemSet>>
fn chain(self) -> NodeConfigs<Interned<dyn SystemSet>>
Treat this collection as a sequence of system sets.
Ordering constraints will be applied between the successive elements.
Examples found in repository?
examples/ecs/ecs_guide.rs (line 291)
251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319
fn main() {
// Bevy apps are created using the builder pattern. We use the builder to add systems,
// resources, and plugins to our app
App::new()
// Resources that implement the Default or FromWorld trait can be added like this:
.init_resource::<GameState>()
// Plugins are just a grouped set of app builder calls (just like we're doing here).
// We could easily turn our game into a plugin, but you can check out the plugin example for
// that :) The plugin below runs our app's "system schedule" once every 5 seconds.
.add_plugins(ScheduleRunnerPlugin::run_loop(Duration::from_secs(5)))
// `Startup` systems run exactly once BEFORE all other systems. These are generally used for
// app initialization code (ex: adding entities and resources)
.add_systems(Startup, startup_system)
// `Update` systems run once every update. These are generally used for "real-time app logic"
.add_systems(Update, print_message_system)
// SYSTEM EXECUTION ORDER
//
// Each system belongs to a `Schedule`, which controls the execution strategy and broad order
// of the systems within each tick. The `Startup` schedule holds
// startup systems, which are run a single time before `Update` runs. `Update` runs once per app update,
// which is generally one "frame" or one "tick".
//
// By default, all systems in a `Schedule` run in parallel, except when they require mutable access to a
// piece of data. This is efficient, but sometimes order matters.
// For example, we want our "game over" system to execute after all other systems to ensure
// we don't accidentally run the game for an extra round.
//
// You can force an explicit ordering between systems using the `.before` or `.after` methods.
// Systems will not be scheduled until all of the systems that they have an "ordering dependency" on have
// completed.
// There are other schedules, such as `Last` which runs at the very end of each run.
.add_systems(Last, print_at_end_round)
// We can also create new system sets, and order them relative to other system sets.
// Here is what our games execution order will look like:
// "before_round": new_player_system, new_round_system
// "round": print_message_system, score_system
// "after_round": score_check_system, game_over_system
.configure_sets(
Update,
// chain() will ensure sets run in the order they are listed
(MySet::BeforeRound, MySet::Round, MySet::AfterRound).chain(),
)
// The add_systems function is powerful. You can define complex system configurations with ease!
.add_systems(
Update,
(
// These `BeforeRound` systems will run before `Round` systems, thanks to the chained set configuration
(
// You can also chain systems! new_round_system will run first, followed by new_player_system
(new_round_system, new_player_system).chain(),
exclusive_player_system,
)
// All of the systems in the tuple above will be added to this set
.in_set(MySet::BeforeRound),
// This `Round` system will run after the `BeforeRound` systems thanks to the chained set configuration
score_system.in_set(MySet::Round),
// These `AfterRound` systems will run after the `Round` systems thanks to the chained set configuration
(
score_check_system,
// In addition to chain(), you can also use `before(system)` and `after(system)`. This also works
// with sets!
game_over_system.after(score_check_system),
)
.in_set(MySet::AfterRound),
),
)
// This call to run() starts the app we just built!
.run();
}fn chain_ignore_deferred(
self
) -> NodeConfigs<Box<dyn System<Out = (), In = ()>>>
fn chain_ignore_deferred( self ) -> NodeConfigs<Box<dyn System<Out = (), In = ()>>>
Treat this collection as a sequence of systems.
Ordering constraints will be applied between the successive elements.
Unlike chain this will not add apply_deferred on the edges.
Object Safety§
This trait is not object safe.