pub trait IntoScheduleConfigs<T, Marker>: Sized{
Show 15 methods
// 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 before_weak<M>(self, set: impl IntoSystemSet<M>) -> ScheduleConfigs<T> { ... }
fn after_weak<M>(self, set: impl IntoSystemSet<M>) -> ScheduleConfigs<T> { ... }
fn distributive_run_if<M>(
self,
condition: impl SystemCondition<M> + Clone,
) -> ScheduleConfigs<T> { ... }
fn run_if<M>(self, condition: impl SystemCondition<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> { ... }
fn chain_weak(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 before_weak<M>(self, set: impl IntoSystemSet<M>) -> ScheduleConfigs<T>
fn before_weak<M>(self, set: impl IntoSystemSet<M>) -> ScheduleConfigs<T>
Run before the systems in set that self actually conflicts with, leaving the rest
unordered.
Like before, this requests that self run before set. Unlike
before, the ordering is kept only between systems whose data accesses
conflict, where a system’s run conditions (and those of its sets) count toward its access.
Systems that don’t conflict are left unordered and may run in any order,
including in parallel. This is useful for ordering against large groups of systems (such
as system sets) without serializing systems that don’t actually depend on each other.
A self that produces deferred effects such as Commands
(with an ApplyDeferred inserted as usual) and
exclusive systems are treated as always conflicting, so their ordering is always kept.
Dependencies the scheduler can’t see (interior mutability on read-only accesses, global state, etc.) are not respected, so only use this when the systems don’t rely on such hidden data dependencies.
A weak ordering cannot be combined with an
ignore_deferred one on a single edge. Configuring both
for the same pair adds a strict ordering alongside the weak one, and a strict ordering
always wins: the ordering is kept even between systems that don’t conflict, just without
the sync point.
Sourcefn after_weak<M>(self, set: impl IntoSystemSet<M>) -> ScheduleConfigs<T>
fn after_weak<M>(self, set: impl IntoSystemSet<M>) -> ScheduleConfigs<T>
Run after the systems in set that self actually conflicts with, leaving the rest
unordered.
Like after, this requests that self run after set. Unlike
after, the ordering is kept only between systems whose data accesses
conflict, where a system’s run conditions (and those of its sets) count toward its access.
Systems that don’t conflict are left unordered and may run in any order,
including in parallel. This is useful for ordering against large groups of systems (such
as system sets) without serializing systems that don’t actually depend on each other.
A system in set that produces deferred effects such as Commands
(with an ApplyDeferred inserted as usual) and exclusive
systems are treated as always conflicting, so their ordering is always kept.
Dependencies the scheduler can’t see (interior mutability on read-only accesses, global state, etc.) are not respected, so only use this when the systems don’t rely on such hidden data dependencies.
A weak ordering cannot be combined with an
ignore_deferred one on a single edge. Configuring both
for the same pair adds a strict ordering alongside the weak one, and a strict ordering
always wins: the ordering is kept even between systems that don’t conflict, just without
the sync point.
Sourcefn distributive_run_if<M>(
self,
condition: impl SystemCondition<M> + Clone,
) -> ScheduleConfigs<T>
fn distributive_run_if<M>( self, condition: impl SystemCondition<M> + Clone, ) -> ScheduleConfigs<T>
Add a run condition to each contained system.
Each system will receive its own clone of the SystemCondition and will only run
if the SystemCondition 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 SystemCondition<M>) -> ScheduleConfigs<T>
fn run_if<M>(self, condition: impl SystemCondition<M>) -> ScheduleConfigs<T>
Run the systems only if the SystemCondition is true.
The SystemCondition 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.
Sourcefn chain_weak(self) -> ScheduleConfigs<T>
fn chain_weak(self) -> ScheduleConfigs<T>
Treat this collection as a sequence, but only order successive systems that actually conflict and leave the rest unordered.
Like chain, this requests an ordering between the successive elements.
Unlike chain, the ordering is kept only between systems whose data
accesses conflict, where a system’s run conditions (and those of its sets) count toward
its access. Systems that don’t conflict are left unordered and may run in any
order, including in parallel. Two systems that conflict only through a non-conflicting
system between them in the chain are still ordered. This is useful for ordering large
groups of systems (such as system sets) without serializing systems that don’t actually
depend on each other.
An earlier system that produces deferred effects such as Commands
(with an ApplyDeferred inserted as usual) and exclusive
systems are treated as always conflicting, so their ordering is always kept.
Dependencies the scheduler can’t see (interior mutability on read-only accesses, global state, etc.) are not respected, so only use this when the systems don’t rely on such hidden data dependencies.
A weak ordering cannot be combined with an
ignore_deferred one on a single edge. Configuring both
for the same pair adds a strict ordering alongside the weak one, and a strict ordering
always wins: the ordering is kept even between systems that don’t conflict, just without
the sync point.
Dyn Compatibility§
This trait is not dyn compatible.
In older versions of Rust, dyn compatibility was called "object safety".