pub trait IntoScheduleConfigs<T, Marker>: Sized{
// Required method
fn into_configs(self) -> ScheduleConfigs<T>;
// Provided methods
fn in_set(self, set: impl SystemSet) -> ScheduleConfigs<T> { ... }
fn before<M>(self, set: impl IntoSystemSet<M>) -> ScheduleConfigs<T> { ... }
fn after<M>(self, set: impl IntoSystemSet<M>) -> ScheduleConfigs<T> { ... }
fn before_ignore_deferred<M>(
self,
set: impl IntoSystemSet<M>,
) -> ScheduleConfigs<T> { ... }
fn after_ignore_deferred<M>(
self,
set: impl IntoSystemSet<M>,
) -> ScheduleConfigs<T> { ... }
fn distributive_run_if<M>(
self,
condition: impl Condition<M> + Clone,
) -> ScheduleConfigs<T> { ... }
fn run_if<M>(self, condition: impl Condition<M>) -> ScheduleConfigs<T> { ... }
fn ambiguous_with<M>(self, set: impl IntoSystemSet<M>) -> ScheduleConfigs<T> { ... }
fn ambiguous_with_all(self) -> ScheduleConfigs<T> { ... }
fn chain(self) -> ScheduleConfigs<T> { ... }
fn chain_ignore_deferred(self) -> ScheduleConfigs<T> { ... }
}Expand description
Types that can convert into a ScheduleConfigs.
This trait is implemented for “systems” (functions whose arguments all implement
SystemParam), or tuples thereof.
It is a common entry point for system configurations.
§Usage notes
This trait should only be used as a bound for trait implementations or as an
argument to a function. If system configs need to be returned from a
function or stored somewhere, use ScheduleConfigs instead of this trait.
§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) -> ScheduleConfigs<T>
fn into_configs(self) -> ScheduleConfigs<T>
Convert into a ScheduleConfigs.
Provided Methods§
Sourcefn in_set(self, set: impl SystemSet) -> ScheduleConfigs<T>
fn in_set(self, set: impl SystemSet) -> ScheduleConfigs<T>
Add these systems to the provided set.
Sourcefn before<M>(self, set: impl IntoSystemSet<M>) -> ScheduleConfigs<T>
fn before<M>(self, set: impl IntoSystemSet<M>) -> ScheduleConfigs<T>
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 ApplyDeferred 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.
Sourcefn after<M>(self, set: impl IntoSystemSet<M>) -> ScheduleConfigs<T>
fn after<M>(self, set: impl IntoSystemSet<M>) -> ScheduleConfigs<T>
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 ApplyDeferred 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.
Sourcefn before_ignore_deferred<M>(
self,
set: impl IntoSystemSet<M>,
) -> ScheduleConfigs<T>
fn before_ignore_deferred<M>( self, set: impl IntoSystemSet<M>, ) -> ScheduleConfigs<T>
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>,
) -> ScheduleConfigs<T>
fn after_ignore_deferred<M>( self, set: impl IntoSystemSet<M>, ) -> ScheduleConfigs<T>
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,
) -> ScheduleConfigs<T>
fn distributive_run_if<M>( self, condition: impl Condition<M> + Clone, ) -> ScheduleConfigs<T>
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>) -> ScheduleConfigs<T>
fn run_if<M>(self, condition: impl Condition<M>) -> ScheduleConfigs<T>
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>) -> ScheduleConfigs<T>
fn ambiguous_with<M>(self, set: impl IntoSystemSet<M>) -> ScheduleConfigs<T>
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) -> ScheduleConfigs<T>
fn ambiguous_with_all(self) -> ScheduleConfigs<T>
Suppress warnings and errors that would result from these systems having ambiguities (conflicting access but indeterminate order) with any other system.
Sourcefn chain(self) -> ScheduleConfigs<T>
fn chain(self) -> ScheduleConfigs<T>
Treat this collection as a sequence of systems.
Ordering constraints will be applied between the successive elements.
If the preceding node on an edge has deferred parameters, an ApplyDeferred
will be inserted on the edge. If this behavior is not desired consider using
chain_ignore_deferred instead.
Sourcefn chain_ignore_deferred(self) -> ScheduleConfigs<T>
fn chain_ignore_deferred(self) -> ScheduleConfigs<T>
Treat this collection as a sequence of systems.
Ordering constraints will be applied between the successive elements.
Unlike chain this will not add ApplyDeferred on the edges.
Dyn Compatibility§
This trait is not dyn compatible.
In older versions of Rust, dyn compatibility was called "object safety", so this trait is not object safe.