dcc03724a5
# Objective NOTE: This depends on #7267 and should not be merged until #7267 is merged. If you are reviewing this before that is merged, I highly recommend viewing the Base Sets commit instead of trying to find my changes amongst those from #7267. "Default sets" as described by the [Stageless RFC](https://github.com/bevyengine/rfcs/pull/45) have some [unfortunate consequences](https://github.com/bevyengine/bevy/discussions/7365). ## Solution This adds "base sets" as a variant of `SystemSet`: A set is a "base set" if `SystemSet::is_base` returns `true`. Typically this will be opted-in to using the `SystemSet` derive: ```rust #[derive(SystemSet, Clone, Hash, Debug, PartialEq, Eq)] #[system_set(base)] enum MyBaseSet { A, B, } ``` **Base sets are exclusive**: a system can belong to at most one "base set". Adding a system to more than one will result in an error. When possible we fail immediately during system-config-time with a nice file + line number. For the more nested graph-ey cases, this will fail at the final schedule build. **Base sets cannot belong to other sets**: this is where the word "base" comes from Systems and Sets can only be added to base sets using `in_base_set`. Calling `in_set` with a base set will fail. As will calling `in_base_set` with a normal set. ```rust app.add_system(foo.in_base_set(MyBaseSet::A)) // X must be a normal set ... base sets cannot be added to base sets .configure_set(X.in_base_set(MyBaseSet::A)) ``` Base sets can still be configured like normal sets: ```rust app.add_system(MyBaseSet::B.after(MyBaseSet::Ap)) ``` The primary use case for base sets is enabling a "default base set": ```rust schedule.set_default_base_set(CoreSet::Update) // this will belong to CoreSet::Update by default .add_system(foo) // this will override the default base set with PostUpdate .add_system(bar.in_base_set(CoreSet::PostUpdate)) ``` This allows us to build apis that work by default in the standard Bevy style. This is a rough analog to the "default stage" model, but it use the new "stageless sets" model instead, with all of the ordering flexibility (including exclusive systems) that it provides. --- ## Changelog - Added "base sets" and ported CoreSet to use them. ## Migration Guide TODO
106 lines
3.5 KiB
Rust
106 lines
3.5 KiB
Rust
use std::marker::PhantomData;
|
|
|
|
use bevy_app::{App, CoreSet, Plugin};
|
|
use bevy_core::Name;
|
|
use bevy_ecs::prelude::*;
|
|
use bevy_log::warn;
|
|
use bevy_utils::{get_short_name, HashSet};
|
|
|
|
use crate::Parent;
|
|
|
|
/// When enabled, runs [`check_hierarchy_component_has_valid_parent<T>`].
|
|
///
|
|
/// This resource is added by [`ValidParentCheckPlugin<T>`].
|
|
/// It is enabled on debug builds and disabled in release builds by default,
|
|
/// you can update this resource at runtime to change the default behavior.
|
|
#[derive(Resource)]
|
|
pub struct ReportHierarchyIssue<T> {
|
|
/// Whether to run [`check_hierarchy_component_has_valid_parent<T>`].
|
|
pub enabled: bool,
|
|
_comp: PhantomData<fn(T)>,
|
|
}
|
|
|
|
impl<T> ReportHierarchyIssue<T> {
|
|
/// Constructs a new object
|
|
pub fn new(enabled: bool) -> Self {
|
|
ReportHierarchyIssue {
|
|
enabled,
|
|
_comp: Default::default(),
|
|
}
|
|
}
|
|
}
|
|
|
|
impl<T> PartialEq for ReportHierarchyIssue<T> {
|
|
fn eq(&self, other: &Self) -> bool {
|
|
self.enabled == other.enabled
|
|
}
|
|
}
|
|
|
|
impl<T> Default for ReportHierarchyIssue<T> {
|
|
fn default() -> Self {
|
|
Self {
|
|
enabled: cfg!(debug_assertions),
|
|
_comp: PhantomData,
|
|
}
|
|
}
|
|
}
|
|
|
|
/// System to print a warning for each `Entity` with a `T` component
|
|
/// which parent hasn't a `T` component.
|
|
///
|
|
/// Hierarchy propagations are top-down, and limited only to entities
|
|
/// with a specific component (such as `ComputedVisibility` and `GlobalTransform`).
|
|
/// This means that entities with one of those component
|
|
/// and a parent without the same component is probably a programming error.
|
|
/// (See B0004 explanation linked in warning message)
|
|
pub fn check_hierarchy_component_has_valid_parent<T: Component>(
|
|
parent_query: Query<
|
|
(Entity, &Parent, Option<&Name>),
|
|
(With<T>, Or<(Changed<Parent>, Added<T>)>),
|
|
>,
|
|
component_query: Query<(), With<T>>,
|
|
mut already_diagnosed: Local<HashSet<Entity>>,
|
|
) {
|
|
for (entity, parent, name) in &parent_query {
|
|
let parent = parent.get();
|
|
if !component_query.contains(parent) && !already_diagnosed.contains(&entity) {
|
|
already_diagnosed.insert(entity);
|
|
warn!(
|
|
"warning[B0004]: {name} with the {ty_name} component has a parent without {ty_name}.\n\
|
|
This will cause inconsistent behaviors! See https://bevyengine.org/learn/errors/#b0004",
|
|
ty_name = get_short_name(std::any::type_name::<T>()),
|
|
name = name.map_or("An entity".to_owned(), |s| format!("The {s} entity")),
|
|
);
|
|
}
|
|
}
|
|
}
|
|
|
|
/// Run criteria that only allows running when [`ReportHierarchyIssue<T>`] is enabled.
|
|
pub fn on_hierarchy_reports_enabled<T>(report: Res<ReportHierarchyIssue<T>>) -> bool
|
|
where
|
|
T: Component,
|
|
{
|
|
report.enabled
|
|
}
|
|
|
|
/// Print a warning for each `Entity` with a `T` component
|
|
/// whose parent doesn't have a `T` component.
|
|
///
|
|
/// See [`check_hierarchy_component_has_valid_parent`] for details.
|
|
pub struct ValidParentCheckPlugin<T: Component>(PhantomData<fn() -> T>);
|
|
impl<T: Component> Default for ValidParentCheckPlugin<T> {
|
|
fn default() -> Self {
|
|
Self(PhantomData)
|
|
}
|
|
}
|
|
|
|
impl<T: Component> Plugin for ValidParentCheckPlugin<T> {
|
|
fn build(&self, app: &mut App) {
|
|
app.init_resource::<ReportHierarchyIssue<T>>().add_system(
|
|
check_hierarchy_component_has_valid_parent::<T>
|
|
.run_if(resource_equals(ReportHierarchyIssue::<T>::new(true)))
|
|
.in_base_set(CoreSet::Last),
|
|
);
|
|
}
|
|
}
|