Trait bevy::prelude::IntoSystemSetConfigs
source · 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§
sourcefn 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
.
sourcefn 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.
sourcefn 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.
sourcefn 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.
sourcefn 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.
sourcefn 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.
sourcefn 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
.
sourcefn 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.
sourcefn 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?
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();
}
sourcefn 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.