Trait bevy::ecs::schedule::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<In = (), Out = ()>>> { ... }
}
Expand description

Types that can convert into a SystemSetConfigs.

Provided Methods§

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>>

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>>

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>>

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>>

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>>

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>>

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>>

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>>

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<In = (), Out = ()>>>

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.

Implementations on Foreign Types§

§

impl<S0> IntoSystemSetConfigs for (S0,)

§

impl<S0, S1> IntoSystemSetConfigs for (S0, S1)

§

impl<S0, S1, S2> IntoSystemSetConfigs for (S0, S1, S2)

§

impl<S0, S1, S2, S3> IntoSystemSetConfigs for (S0, S1, S2, S3)

§

impl<S0, S1, S2, S3, S4> IntoSystemSetConfigs for (S0, S1, S2, S3, S4)

§

impl<S0, S1, S2, S3, S4, S5> IntoSystemSetConfigs for (S0, S1, S2, S3, S4, S5)

§

impl<S0, S1, S2, S3, S4, S5, S6> IntoSystemSetConfigs for (S0, S1, S2, S3, S4, S5, S6)

§

impl<S0, S1, S2, S3, S4, S5, S6, S7> IntoSystemSetConfigs for (S0, S1, S2, S3, S4, S5, S6, S7)

§

impl<S0, S1, S2, S3, S4, S5, S6, S7, S8> IntoSystemSetConfigs for (S0, S1, S2, S3, S4, S5, S6, S7, S8)

§

impl<S0, S1, S2, S3, S4, S5, S6, S7, S8, S9> IntoSystemSetConfigs for (S0, S1, S2, S3, S4, S5, S6, S7, S8, S9)

§

impl<S0, S1, S2, S3, S4, S5, S6, S7, S8, S9, S10> IntoSystemSetConfigs for (S0, S1, S2, S3, S4, S5, S6, S7, S8, S9, S10)

§

impl<S0, S1, S2, S3, S4, S5, S6, S7, S8, S9, S10, S11> IntoSystemSetConfigs for (S0, S1, S2, S3, S4, S5, S6, S7, S8, S9, S10, S11)

§

impl<S0, S1, S2, S3, S4, S5, S6, S7, S8, S9, S10, S11, S12> IntoSystemSetConfigs for (S0, S1, S2, S3, S4, S5, S6, S7, S8, S9, S10, S11, S12)

§

impl<S0, S1, S2, S3, S4, S5, S6, S7, S8, S9, S10, S11, S12, S13> IntoSystemSetConfigs for (S0, S1, S2, S3, S4, S5, S6, S7, S8, S9, S10, S11, S12, S13)

§

impl<S0, S1, S2, S3, S4, S5, S6, S7, S8, S9, S10, S11, S12, S13, S14> IntoSystemSetConfigs for (S0, S1, S2, S3, S4, S5, S6, S7, S8, S9, S10, S11, S12, S13, S14)

§

impl<S0, S1, S2, S3, S4, S5, S6, S7, S8, S9, S10, S11, S12, S13, S14, S15> IntoSystemSetConfigs for (S0, S1, S2, S3, S4, S5, S6, S7, S8, S9, S10, S11, S12, S13, S14, S15)

§

impl<S0, S1, S2, S3, S4, S5, S6, S7, S8, S9, S10, S11, S12, S13, S14, S15, S16> IntoSystemSetConfigs for (S0, S1, S2, S3, S4, S5, S6, S7, S8, S9, S10, S11, S12, S13, S14, S15, S16)

§

impl<S0, S1, S2, S3, S4, S5, S6, S7, S8, S9, S10, S11, S12, S13, S14, S15, S16, S17> IntoSystemSetConfigs for (S0, S1, S2, S3, S4, S5, S6, S7, S8, S9, S10, S11, S12, S13, S14, S15, S16, S17)

§

impl<S0, S1, S2, S3, S4, S5, S6, S7, S8, S9, S10, S11, S12, S13, S14, S15, S16, S17, S18> IntoSystemSetConfigs for (S0, S1, S2, S3, S4, S5, S6, S7, S8, S9, S10, S11, S12, S13, S14, S15, S16, S17, S18)

§

impl<S0, S1, S2, S3, S4, S5, S6, S7, S8, S9, S10, S11, S12, S13, S14, S15, S16, S17, S18, S19> IntoSystemSetConfigs for (S0, S1, S2, S3, S4, S5, S6, S7, S8, S9, S10, S11, S12, S13, S14, S15, S16, S17, S18, S19)

Implementors§