pub trait Condition<Marker, In: SystemInput = ()>: Condition<Marker, In> {
// Provided methods
fn and<M, C: Condition<M, In>>(self, and: C) -> And<Self::System, C::System> { ... }
fn and_then<M, C: Condition<M, In>>(
self,
and_then: C,
) -> And<Self::System, C::System> { ... }
fn nand<M, C: Condition<M, In>>(
self,
nand: C,
) -> Nand<Self::System, C::System> { ... }
fn nor<M, C: Condition<M, In>>(self, nor: C) -> Nor<Self::System, C::System> { ... }
fn or<M, C: Condition<M, In>>(self, or: C) -> Or<Self::System, C::System> { ... }
fn or_else<M, C: Condition<M, In>>(
self,
or_else: C,
) -> Or<Self::System, C::System> { ... }
fn xnor<M, C: Condition<M, In>>(
self,
xnor: C,
) -> Xnor<Self::System, C::System> { ... }
fn xor<M, C: Condition<M, In>>(self, xor: C) -> Xor<Self::System, C::System> { ... }
}
Expand description
A system that determines if one or more scheduled systems should run.
Implemented for functions and closures that convert into System<Out=bool>
with read-only parameters.
§Marker type parameter
Condition
trait has Marker
type parameter, which has no special meaning,
but exists to work around the limitation of Rust’s trait system.
Type parameter in return type can be set to <()>
by calling IntoSystem::into_system
,
but usually have to be specified when passing a condition to a function.
fn not_condition<Marker>(a: impl Condition<Marker>) -> impl Condition<()> {
IntoSystem::into_system(a.map(|x| !x))
}
§Examples
A condition that returns true every other time it’s called.
fn every_other_time() -> impl Condition<()> {
IntoSystem::into_system(|mut flag: Local<bool>| {
*flag = !*flag;
*flag
})
}
schedule.add_systems(my_system.run_if(every_other_time()));
A condition that takes a bool as an input and returns it unchanged.
fn identity() -> impl Condition<(), In<bool>> {
IntoSystem::into_system(|In(x)| x)
}
app.add_systems(my_system.run_if(always_true.pipe(identity())));
Provided Methods§
Sourcefn and<M, C: Condition<M, In>>(self, and: C) -> And<Self::System, C::System>
fn and<M, C: Condition<M, In>>(self, and: C) -> And<Self::System, C::System>
Returns a new run condition that only returns true
if both this one and the passed and
return true
.
The returned run condition is short-circuiting, meaning
and
will only be invoked if self
returns true
.
§Examples
use bevy_ecs::prelude::*;
#[derive(Resource, PartialEq)]
struct R(u32);
app.add_systems(
// The `resource_equals` run condition will fail since we don't initialize `R`,
// just like if we used `Res<R>` in a system.
my_system.run_if(resource_equals(R(0))),
);
Use .and()
to avoid checking the condition.
app.add_systems(
// `resource_equals` will only get run if the resource `R` exists.
my_system.run_if(resource_exists::<R>.and(resource_equals(R(0)))),
);
Note that in this case, it’s better to just use the run condition resource_exists_and_equals
.
Sourcefn and_then<M, C: Condition<M, In>>(
self,
and_then: C,
) -> And<Self::System, C::System>
👎Deprecated: Users should use the .and(condition)
method in lieu of .and_then(condition)
fn and_then<M, C: Condition<M, In>>( self, and_then: C, ) -> And<Self::System, C::System>
.and(condition)
method in lieu of .and_then(condition)
Returns a new run condition that only returns true
if both this one and the passed and_then
return true
.
The returned run condition is short-circuiting, meaning
and_then
will only be invoked if self
returns true
.
§Examples
use bevy_ecs::prelude::*;
#[derive(Resource, PartialEq)]
struct R(u32);
app.add_systems(
// The `resource_equals` run condition will fail since we don't initialize `R`,
// just like if we used `Res<R>` in a system.
my_system.run_if(resource_equals(R(0))),
);
Use .and_then()
to avoid checking the condition.
app.add_systems(
// `resource_equals` will only get run if the resource `R` exists.
my_system.run_if(resource_exists::<R>.and_then(resource_equals(R(0)))),
);
Note that in this case, it’s better to just use the run condition resource_exists_and_equals
.
Sourcefn nand<M, C: Condition<M, In>>(self, nand: C) -> Nand<Self::System, C::System>
fn nand<M, C: Condition<M, In>>(self, nand: C) -> Nand<Self::System, C::System>
Returns a new run condition that only returns false
if both this one and the passed nand
return true
.
The returned run condition is short-circuiting, meaning
nand
will only be invoked if self
returns true
.
§Examples
use bevy::prelude::*;
#[derive(States, Debug, Clone, PartialEq, Eq, Hash)]
pub enum PlayerState {
Alive,
Dead,
}
#[derive(States, Debug, Clone, PartialEq, Eq, Hash)]
pub enum EnemyState {
Alive,
Dead,
}
app.add_systems(
// The game_over_credits system will only execute if either the `in_state(PlayerState::Alive)`
// run condition or `in_state(EnemyState::Alive)` run condition evaluates to `false`.
game_over_credits.run_if(
in_state(PlayerState::Alive).nand(in_state(EnemyState::Alive))
),
);
Equivalent logic can be achieved by using not
in concert with and
:
app.add_systems(
game_over_credits.run_if(
not(in_state(PlayerState::Alive).and(in_state(EnemyState::Alive)))
),
);
Sourcefn nor<M, C: Condition<M, In>>(self, nor: C) -> Nor<Self::System, C::System>
fn nor<M, C: Condition<M, In>>(self, nor: C) -> Nor<Self::System, C::System>
Returns a new run condition that only returns true
if both this one and the passed nor
return false
.
The returned run condition is short-circuiting, meaning
nor
will only be invoked if self
returns false
.
§Examples
use bevy::prelude::*;
#[derive(States, Debug, Clone, PartialEq, Eq, Hash)]
pub enum WeatherState {
Sunny,
Cloudy,
}
#[derive(States, Debug, Clone, PartialEq, Eq, Hash)]
pub enum SoilState {
Fertilized,
NotFertilized,
}
app.add_systems(
// The slow_plant_growth system will only execute if both the `in_state(WeatherState::Sunny)`
// run condition and `in_state(SoilState::Fertilized)` run condition evaluate to `false`.
slow_plant_growth.run_if(
in_state(WeatherState::Sunny).nor(in_state(SoilState::Fertilized))
),
);
Equivalent logic can be achieved by using not
in concert with or
:
app.add_systems(
slow_plant_growth.run_if(
not(in_state(WeatherState::Sunny).or(in_state(SoilState::Fertilized)))
),
);
Sourcefn or<M, C: Condition<M, In>>(self, or: C) -> Or<Self::System, C::System>
fn or<M, C: Condition<M, In>>(self, or: C) -> Or<Self::System, C::System>
Returns a new run condition that returns true
if either this one or the passed or
return true
.
The returned run condition is short-circuiting, meaning
or
will only be invoked if self
returns false
.
§Examples
use bevy_ecs::prelude::*;
#[derive(Resource, PartialEq)]
struct A(u32);
#[derive(Resource, PartialEq)]
struct B(u32);
app.add_systems(
// Only run the system if either `A` or `B` exist.
my_system.run_if(resource_exists::<A>.or(resource_exists::<B>)),
);
Sourcefn or_else<M, C: Condition<M, In>>(
self,
or_else: C,
) -> Or<Self::System, C::System>
👎Deprecated: Users should use the .or(condition)
method in lieu of .or_else(condition)
fn or_else<M, C: Condition<M, In>>( self, or_else: C, ) -> Or<Self::System, C::System>
.or(condition)
method in lieu of .or_else(condition)
Returns a new run condition that returns true
if either this one or the passed or
return true
.
The returned run condition is short-circuiting, meaning
or
will only be invoked if self
returns false
.
§Examples
use bevy_ecs::prelude::*;
#[derive(Resource, PartialEq)]
struct A(u32);
#[derive(Resource, PartialEq)]
struct B(u32);
app.add_systems(
// Only run the system if either `A` or `B` exist.
my_system.run_if(resource_exists::<A>.or(resource_exists::<B>)),
);
Sourcefn xnor<M, C: Condition<M, In>>(self, xnor: C) -> Xnor<Self::System, C::System>
fn xnor<M, C: Condition<M, In>>(self, xnor: C) -> Xnor<Self::System, C::System>
Returns a new run condition that only returns true
if self
and xnor
both return false
or both return true
.
§Examples
use bevy::prelude::*;
#[derive(States, Debug, Clone, PartialEq, Eq, Hash)]
pub enum CoffeeMachineState {
Heating,
Brewing,
Inactive,
}
#[derive(States, Debug, Clone, PartialEq, Eq, Hash)]
pub enum TeaKettleState {
Heating,
Steeping,
Inactive,
}
app.add_systems(
// The take_drink_orders system will only execute if the `in_state(CoffeeMachineState::Inactive)`
// run condition and `in_state(TeaKettleState::Inactive)` run conditions both evaluate to `false`,
// or both evaluate to `true`.
take_drink_orders.run_if(
in_state(CoffeeMachineState::Inactive).xnor(in_state(TeaKettleState::Inactive))
),
);
Equivalent logic can be achieved by using not
in concert with xor
:
app.add_systems(
take_drink_orders.run_if(
not(in_state(CoffeeMachineState::Inactive).xor(in_state(TeaKettleState::Inactive)))
),
);
Sourcefn xor<M, C: Condition<M, In>>(self, xor: C) -> Xor<Self::System, C::System>
fn xor<M, C: Condition<M, In>>(self, xor: C) -> Xor<Self::System, C::System>
Returns a new run condition that only returns true
if either self
or xor
return true
, but not both.
§Examples
use bevy::prelude::*;
#[derive(States, Debug, Clone, PartialEq, Eq, Hash)]
pub enum CoffeeMachineState {
Heating,
Brewing,
Inactive,
}
#[derive(States, Debug, Clone, PartialEq, Eq, Hash)]
pub enum TeaKettleState {
Heating,
Steeping,
Inactive,
}
app.add_systems(
// The prepare_beverage system will only execute if either the `in_state(CoffeeMachineState::Inactive)`
// run condition or `in_state(TeaKettleState::Inactive)` run condition evaluates to `true`,
// but not both.
prepare_beverage.run_if(
in_state(CoffeeMachineState::Inactive).xor(in_state(TeaKettleState::Inactive))
),
);
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.