#![no_std]12//! In Bevy, states are app-wide interdependent, finite state machines that are generally used to model the large scale structure of your program: whether a game is paused, if the player is in combat, if assets are loaded and so on.3//!4//! This module provides 3 distinct types of state, all of which implement the [`States`](state::States) trait:5//!6//! - Standard [`States`](state::States) can only be changed by manually setting the [`NextState<S>`](state::NextState) resource.7//! These states are the baseline on which the other state types are built, and can be used on8//! their own for many simple patterns. See the [states example](https://github.com/bevyengine/bevy/blob/latest/examples/state/states.rs)9//! for a simple use case.10//! - [`SubStates`](state::SubStates) are children of other states - they can be changed manually using [`NextState<S>`](state::NextState),11//! but are removed from the [`World`](bevy_ecs::prelude::World) if the source states aren't in the right state. See the [sub_states example](https://github.com/bevyengine/bevy/blob/latest/examples/state/sub_states.rs)12//! for a simple use case based on the derive macro, or read the trait docs for more complex scenarios.13//! - [`ComputedStates`](state::ComputedStates) are fully derived from other states - they provide a [`compute`](state::ComputedStates::compute) method14//! that takes in the source states and returns their derived value. They are particularly useful for situations15//! where a simplified view of the source states is necessary - such as having an `InAMenu` computed state, derived16//! from a source state that defines multiple distinct menus. See the [computed state example](https://github.com/bevyengine/bevy/blob/latest/examples/state/computed_states.rs)17//! to see usage samples for these states.18//!19//! Most of the utilities around state involve running systems during transitions between states, or20//! determining whether to run certain systems, though they can be used more directly as well. This21//! makes it easier to transition between menus, add loading screens, pause games, and more.22//!23//! Specifically, Bevy provides the following utilities:24//!25//! - 3 Transition Schedules - [`OnEnter<S>`](crate::state::OnEnter), [`OnExit<S>`](crate::state::OnExit) and [`OnTransition<S>`](crate::state::OnTransition) - which are used26//! to trigger systems specifically during matching transitions.27//! - A [`StateTransitionEvent<S>`](crate::state::StateTransitionEvent) that gets fired when a given state changes.28//! - The [`in_state<S>`](crate::condition::in_state) and [`state_changed<S>`](crate::condition::state_changed) run conditions - which are used29//! to determine whether a system should run based on the current state.30//!31//! Bevy also provides ("state-scoped entities")[`crate::state_scoped`] functionality for managing the lifetime of entities in the context of game states.32//! This, especially in combination with system scheduling, enables a flexible and expressive way to manage spawning and despawning entities.3334#![cfg_attr(35any(docsrs, docsrs_dep),36expect(37internal_features,38reason = "rustdoc_internals is needed for fake_variadic"39)40)]41#![cfg_attr(any(docsrs, docsrs_dep), feature(rustdoc_internals))]4243#[cfg(feature = "std")]44extern crate std;4546extern crate alloc;4748// Required to make proc macros work in bevy itself.49extern crate self as bevy_state;5051#[cfg(feature = "bevy_app")]52/// Provides [`App`](bevy_app::App) and [`SubApp`](bevy_app::SubApp) with state installation methods53pub mod app;54/// Provides extension methods for [`Commands`](bevy_ecs::prelude::Commands).55pub mod commands;56/// Provides definitions for the runtime conditions that interact with the state system57pub mod condition;58/// Provides definitions for the basic traits required by the state system59pub mod state;6061/// Provides tools for managing the lifetime of entities based on state transitions.62pub mod state_scoped;63#[cfg(feature = "bevy_app")]64/// Provides [`App`](bevy_app::App) and [`SubApp`](bevy_app::SubApp) with methods for registering65/// state-scoped events.66pub mod state_scoped_events;6768#[cfg(feature = "bevy_reflect")]69/// Provides definitions for the basic traits required by the state system70pub mod reflect;7172/// The state prelude.73///74/// This includes the most common types in this crate, re-exported for your convenience.75pub mod prelude {76#[cfg(feature = "bevy_app")]77#[doc(hidden)]78pub use crate::{app::AppExtStates, state_scoped_events::StateScopedEventsAppExt};7980#[cfg(feature = "bevy_reflect")]81#[doc(hidden)]82pub use crate::reflect::{ReflectFreelyMutableState, ReflectState};8384#[doc(hidden)]85pub use crate::{86commands::CommandsStatesExt,87condition::*,88state::{89last_transition, ComputedStates, EnterSchedules, ExitSchedules, NextState, OnEnter,90OnExit, OnTransition, State, StateSet, StateTransition, StateTransitionEvent, States,91SubStates, TransitionSchedules,92},93state_scoped::{DespawnOnEnter, DespawnOnExit},94};95}9697#[cfg(test)]98mod tests {99use bevy_app::{App, PreStartup};100use bevy_ecs::{101resource::Resource,102system::{Commands, ResMut},103};104use bevy_state_macros::States;105106use crate::{107app::{AppExtStates, StatesPlugin},108state::OnEnter,109};110111#[test]112fn state_transition_runs_before_pre_startup() {113// This test is not really a "requirement" of states (we could run state transitions after114// PreStartup), but this is the current policy and it is useful to ensure we are following115// it if we ever change how we initialize stuff.116117let mut app = App::new();118app.add_plugins(StatesPlugin);119120#[derive(States, Default, PartialEq, Eq, Hash, Debug, Clone)]121enum TestState {122#[default]123A,124#[expect(125dead_code,126reason = "This struct is used as a compilation test to test the derive macros, and as such is intentionally never constructed."127)]128B,129}130131#[derive(Resource, Default, PartialEq, Eq, Debug)]132struct Thingy(usize);133134app.init_state::<TestState>();135136app.add_systems(OnEnter(TestState::A), move |mut commands: Commands| {137commands.init_resource::<Thingy>();138});139140app.add_systems(PreStartup, move |mut thingy: ResMut<Thingy>| {141// This system will fail if it runs before OnEnter.142thingy.0 += 1;143});144145app.update();146147// This assert only succeeds if first OnEnter(TestState::A) runs, followed by PreStartup.148assert_eq!(app.world().resource::<Thingy>(), &Thingy(1));149}150}151152153