Trait bevy_ecs::schedule::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§
sourcefn into_configs(self) -> SystemConfigs
fn into_configs(self) -> SystemConfigs
Convert into a SystemConfigs.
Provided Methods§
sourcefn in_set(self, set: impl SystemSet) -> SystemConfigs
fn in_set(self, set: impl SystemSet) -> SystemConfigs
Add these systems to the provided set.
sourcefn before<M>(self, set: impl IntoSystemSet<M>) -> SystemConfigs
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.
Note: The given set is not implicitly added to the schedule when this system set is added. It is safe, but no dependencies will be created.
sourcefn after<M>(self, set: impl IntoSystemSet<M>) -> SystemConfigs
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.
Note: The given set is not implicitly added to the schedule when this system set is added. It is safe, but no dependencies will be created.
sourcefn before_ignore_deferred<M>(self, set: impl IntoSystemSet<M>) -> SystemConfigs
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.
sourcefn after_ignore_deferred<M>(self, set: impl IntoSystemSet<M>) -> SystemConfigs
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.
sourcefn distributive_run_if<M>(
self,
condition: impl Condition<M> + Clone
) -> SystemConfigs
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.
sourcefn run_if<M>(self, condition: impl Condition<M>) -> SystemConfigs
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.
sourcefn ambiguous_with<M>(self, set: impl IntoSystemSet<M>) -> SystemConfigs
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.
sourcefn ambiguous_with_all(self) -> SystemConfigs
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.
sourcefn chain(self) -> SystemConfigs
fn chain(self) -> SystemConfigs
Treat this collection as a sequence of systems.
Ordering constraints will be applied between the successive elements.
If the preceeding 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.
sourcefn chain_ignore_deferred(self) -> SystemConfigs
fn chain_ignore_deferred(self) -> SystemConfigs
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.