Trait IntoSystemConfigs

Source

pub trait IntoSystemConfigs<Marker>where
    Self: Sized,{
    // Required method
    fn into_configs(self) -> SystemConfigs;

    // Provided methods
    fn in_set(self, set: impl SystemSet) -> SystemConfigs { ... }
    fn before<M>(self, set: impl IntoSystemSet<M>) -> SystemConfigs { ... }
    fn after<M>(self, set: impl IntoSystemSet<M>) -> SystemConfigs { ... }
    fn before_ignore_deferred<M>(
        self,
        set: impl IntoSystemSet<M>,
    ) -> SystemConfigs { ... }
    fn after_ignore_deferred<M>(
        self,
        set: impl IntoSystemSet<M>,
    ) -> SystemConfigs { ... }
    fn distributive_run_if<M>(
        self,
        condition: impl Condition<M> + Clone,
    ) -> SystemConfigs { ... }
    fn run_if<M>(self, condition: impl Condition<M>) -> SystemConfigs { ... }
    fn ambiguous_with<M>(self, set: impl IntoSystemSet<M>) -> SystemConfigs { ... }
    fn ambiguous_with_all(self) -> SystemConfigs { ... }
    fn chain(self) -> SystemConfigs { ... }
    fn chain_ignore_deferred(self) -> SystemConfigs { ... }
}

Expand description

Types that can convert into a SystemConfigs.

This trait is implemented for “systems” (functions whose arguments all implement SystemParam), or tuples thereof. It is a common entry point for system configurations.

§Examples


fn handle_input() {}

fn update_camera() {}
fn update_character() {}

app.add_systems(
    Update,
    (
        handle_input,
        (update_camera, update_character).after(handle_input)
    )
);

Required Methods§

Source

fn into_configs(self) -> SystemConfigs

Convert into a SystemConfigs.

Provided Methods§

Source

fn in_set(self, set: impl SystemSet) -> SystemConfigs

Add these systems to the provided set.

Source

fn before<M>(self, set: impl IntoSystemSet<M>) -> SystemConfigs

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.

Calling .chain is often more convenient and ensures that all systems are added to the schedule. Please check the caveats section of .after for details.

Source

fn after<M>(self, set: impl IntoSystemSet<M>) -> SystemConfigs

Run after 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.

Calling .chain is often more convenient and ensures that all systems are added to the schedule.

§Caveats

If you configure two Systems like (GameSystem::A).after(GameSystem::B) or (GameSystem::A).before(GameSystem::B), the GameSystem::B will not be automatically scheduled.

This means that the system GameSystem::A and the system or systems in GameSystem::B will run independently of each other if GameSystem::B was never explicitly scheduled with configure_sets If that is the case, .after/.before will not provide the desired behavior and the systems can run in parallel or in any order determined by the scheduler. Only use after(GameSystem::B) and before(GameSystem::B) when you know that B has already been scheduled for you, e.g. when it was provided by Bevy or a third-party dependency, or you manually scheduled it somewhere else in your app.

Another caveat is that if GameSystem::B is placed in a different schedule than GameSystem::A, any ordering calls between them—whether using .before, .after, or .chain—will be silently ignored.

Source

fn before_ignore_deferred<M>(self, set: impl IntoSystemSet<M>) -> SystemConfigs

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.

Source

fn after_ignore_deferred<M>(self, set: impl IntoSystemSet<M>) -> SystemConfigs

Run after all systems in set.

Unlike after, this will not wait for the deferred effects of systems in set to be applied.

Source

fn distributive_run_if<M>( self, condition: impl Condition<M> + Clone, ) -> SystemConfigs

Add a run condition to each contained system.

Each system will receive its own clone of the Condition and will only run if the Condition is true.

Each individual condition will be evaluated at most once (per schedule run), right before the corresponding system prepares to run.

This is equivalent to calling run_if on each individual system, as shown below:

schedule.add_systems((a, b).distributive_run_if(condition));
schedule.add_systems((a.run_if(condition), b.run_if(condition)));

§Note

Because the conditions are evaluated separately for each system, there is no guarantee that all evaluations in a single schedule run will yield the same result. If another system is run inbetween two evaluations it could cause the result of the condition to change.

Use run_if on a SystemSet if you want to make sure that either all or none of the systems are run, or you don’t want to evaluate the run condition for each contained system separately.

Source

fn run_if<M>(self, condition: impl Condition<M>) -> SystemConfigs

Run the systems 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 prepares to run.

If this set contains more than one system, calling run_if is equivalent to adding each system to a common set and configuring the run condition on that set, as shown below:

§Examples

schedule.add_systems((a, b).run_if(condition));
schedule.add_systems((a, b).in_set(C)).configure_sets(C.run_if(condition));

§Note

Because the condition will only be evaluated once, there is no guarantee that the condition is upheld after the first system has run. You need to make sure that no other systems that could invalidate the condition are scheduled inbetween the first and last run system.

Use distributive_run_if if you want the condition to be evaluated for each individual system, right before one is run.

Source

fn ambiguous_with<M>(self, set: impl IntoSystemSet<M>) -> SystemConfigs

Suppress warnings and errors that would result from these systems having ambiguities (conflicting access but indeterminate order) with systems in set.

Source

fn ambiguous_with_all(self) -> SystemConfigs

Suppress warnings and errors that would result from these systems having ambiguities (conflicting access but indeterminate order) with any other system.

Source

fn chain(self) -> SystemConfigs

Treat this collection as a sequence of systems.

Ordering constraints will be applied between the successive elements.

If the preceding node on a edge has deferred parameters, a apply_deferred will be inserted on the edge. If this behavior is not desired consider using chain_ignore_deferred instead.

Source