
This adds support for one-to-many non-fragmenting relationships (with planned paths for fragmenting and non-fragmenting many-to-many relationships). "Non-fragmenting" means that entities with the same relationship type, but different relationship targets, are not forced into separate tables (which would cause "table fragmentation"). Functionally, this fills a similar niche as the current Parent/Children system. The biggest differences are: 1. Relationships have simpler internals and significantly improved performance and UX. Commands and specialized APIs are no longer necessary to keep everything in sync. Just spawn entities with the relationship components you want and everything "just works". 2. Relationships are generalized. Bevy can provide additional built in relationships, and users can define their own. **REQUEST TO REVIEWERS**: _please don't leave top level comments and instead comment on specific lines of code. That way we can take advantage of threaded discussions. Also dont leave comments simply pointing out CI failures as I can read those just fine._ ## Built on top of what we have Relationships are implemented on top of the Bevy ECS features we already have: components, immutability, and hooks. This makes them immediately compatible with all of our existing (and future) APIs for querying, spawning, removing, scenes, reflection, etc. The fewer specialized APIs we need to build, maintain, and teach, the better. ## Why focus on one-to-many non-fragmenting first? 1. This allows us to improve Parent/Children relationships immediately, in a way that is reasonably uncontroversial. Switching our hierarchy to fragmenting relationships would have significant performance implications. ~~Flecs is heavily considering a switch to non-fragmenting relations after careful considerations of the performance tradeoffs.~~ _(Correction from @SanderMertens: Flecs is implementing non-fragmenting storage specialized for asset hierarchies, where asset hierarchies are many instances of small trees that have a well defined structure)_ 2. Adding generalized one-to-many relationships is currently a priority for the [Next Generation Scene / UI effort](https://github.com/bevyengine/bevy/discussions/14437). Specifically, we're interested in building reactions and observers on top. ## The changes This PR does the following: 1. Adds a generic one-to-many Relationship system 3. Ports the existing Parent/Children system to Relationships, which now lives in `bevy_ecs::hierarchy`. The old `bevy_hierarchy` crate has been removed. 4. Adds on_despawn component hooks 5. Relationships can opt-in to "despawn descendants" behavior, meaning that the entire relationship hierarchy is despawned when `entity.despawn()` is called. The built in Parent/Children hierarchies enable this behavior, and `entity.despawn_recursive()` has been removed. 6. `world.spawn` now applies commands after spawning. This ensures that relationship bookkeeping happens immediately and removes the need to manually flush. This is in line with the equivalent behaviors recently added to the other APIs (ex: insert). 7. Removes the ValidParentCheckPlugin (system-driven / poll based) in favor of a `validate_parent_has_component` hook. ## Using Relationships The `Relationship` trait looks like this: ```rust pub trait Relationship: Component + Sized { type RelationshipSources: RelationshipSources<Relationship = Self>; fn get(&self) -> Entity; fn from(entity: Entity) -> Self; } ``` A relationship is a component that: 1. Is a simple wrapper over a "target" Entity. 2. Has a corresponding `RelationshipSources` component, which is a simple wrapper over a collection of entities. Every "target entity" targeted by a "source entity" with a `Relationship` has a `RelationshipSources` component, which contains every "source entity" that targets it. For example, the `Parent` component (as it currently exists in Bevy) is the `Relationship` component and the entity containing the Parent is the "source entity". The entity _inside_ the `Parent(Entity)` component is the "target entity". And that target entity has a `Children` component (which implements `RelationshipSources`). In practice, the Parent/Children relationship looks like this: ```rust #[derive(Relationship)] #[relationship(relationship_sources = Children)] pub struct Parent(pub Entity); #[derive(RelationshipSources)] #[relationship_sources(relationship = Parent)] pub struct Children(Vec<Entity>); ``` The Relationship and RelationshipSources derives automatically implement Component with the relevant configuration (namely, the hooks necessary to keep everything in sync). The most direct way to add relationships is to spawn entities with relationship components: ```rust let a = world.spawn_empty().id(); let b = world.spawn(Parent(a)).id(); assert_eq!(world.entity(a).get::<Children>().unwrap(), &[b]); ``` There are also convenience APIs for spawning more than one entity with the same relationship: ```rust world.spawn_empty().with_related::<Children>(|s| { s.spawn_empty(); s.spawn_empty(); }) ``` The existing `with_children` API is now a simpler wrapper over `with_related`. This makes this change largely non-breaking for existing spawn patterns. ```rust world.spawn_empty().with_children(|s| { s.spawn_empty(); s.spawn_empty(); }) ``` There are also other relationship APIs, such as `add_related` and `despawn_related`. ## Automatic recursive despawn via the new on_despawn hook `RelationshipSources` can opt-in to "despawn descendants" behavior, which will despawn all related entities in the relationship hierarchy: ```rust #[derive(RelationshipSources)] #[relationship_sources(relationship = Parent, despawn_descendants)] pub struct Children(Vec<Entity>); ``` This means that `entity.despawn_recursive()` is no longer required. Instead, just use `entity.despawn()` and the relevant related entities will also be despawned. To despawn an entity _without_ despawning its parent/child descendants, you should remove the `Children` component first, which will also remove the related `Parent` components: ```rust entity .remove::<Children>() .despawn() ``` This builds on the on_despawn hook introduced in this PR, which is fired when an entity is despawned (before other hooks). ## Relationships are the source of truth `Relationship` is the _single_ source of truth component. `RelationshipSources` is merely a reflection of what all the `Relationship` components say. By embracing this, we are able to significantly improve the performance of the system as a whole. We can rely on component lifecycles to protect us against duplicates, rather than needing to scan at runtime to ensure entities don't already exist (which results in quadratic runtime). A single source of truth gives us constant-time inserts. This does mean that we cannot directly spawn populated `Children` components (or directly add or remove entities from those components). I personally think this is a worthwhile tradeoff, both because it makes the performance much better _and_ because it means theres exactly one way to do things (which is a philosophy we try to employ for Bevy APIs). As an aside: treating both sides of the relationship as "equivalent source of truth relations" does enable building simple and flexible many-to-many relationships. But this introduces an _inherent_ need to scan (or hash) to protect against duplicates. [`evergreen_relations`](https://github.com/EvergreenNest/evergreen_relations) has a very nice implementation of the "symmetrical many-to-many" approach. Unfortunately I think the performance issues inherent to that approach make it a poor choice for Bevy's default relationship system. ## Followup Work * Discuss renaming `Parent` to `ChildOf`. I refrained from doing that in this PR to keep the diff reasonable, but I'm personally biased toward this change (and using that naming pattern generally for relationships). * [Improved spawning ergonomics](https://github.com/bevyengine/bevy/discussions/16920) * Consider adding relationship observers/triggers for "relationship targets" whenever a source is added or removed. This would replace the current "hierarchy events" system, which is unused upstream but may have existing users downstream. I think triggers are the better fit for this than a buffered event queue, and would prefer not to add that back. * Fragmenting relations: My current idea hinges on the introduction of "value components" (aka: components whose type _and_ value determines their ComponentId, via something like Hashing / PartialEq). By labeling a Relationship component such as `ChildOf(Entity)` as a "value component", `ChildOf(e1)` and `ChildOf(e2)` would be considered "different components". This makes the transition between fragmenting and non-fragmenting a single flag, and everything else continues to work as expected. * Many-to-many support * Non-fragmenting: We can expand Relationship to be a list of entities instead of a single entity. I have largely already written the code for this. * Fragmenting: With the "value component" impl mentioned above, we get many-to-many support "for free", as it would allow inserting multiple copies of a Relationship component with different target entities. Fixes #3742 (If this PR is merged, I think we should open more targeted followup issues for the work above, with a fresh tracking issue free of the large amount of less-directed historical context) Fixes #17301 Fixes #12235 Fixes #15299 Fixes #15308 ## Migration Guide * Replace `ChildBuilder` with `ChildSpawnerCommands`. * Replace calls to `.set_parent(parent_id)` with `.insert(Parent(parent_id))`. * Replace calls to `.replace_children()` with `.remove::<Children>()` followed by `.add_children()`. Note that you'll need to manually despawn any children that are not carried over. * Replace calls to `.despawn_recursive()` with `.despawn()`. * Replace calls to `.despawn_descendants()` with `.despawn_related::<Children>()`. * If you have any calls to `.despawn()` which depend on the children being preserved, you'll need to remove the `Children` component first. --------- Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>
365 lines
16 KiB
Rust
365 lines
16 KiB
Rust
//! Definitions for [`Component`] reflection.
|
||
//! This allows inserting, updating, removing and generally interacting with components
|
||
//! whose types are only known at runtime.
|
||
//!
|
||
//! This module exports two types: [`ReflectComponentFns`] and [`ReflectComponent`].
|
||
//!
|
||
//! # Architecture
|
||
//!
|
||
//! [`ReflectComponent`] wraps a [`ReflectComponentFns`]. In fact, each method on
|
||
//! [`ReflectComponent`] wraps a call to a function pointer field in `ReflectComponentFns`.
|
||
//!
|
||
//! ## Who creates `ReflectComponent`s?
|
||
//!
|
||
//! When a user adds the `#[reflect(Component)]` attribute to their `#[derive(Reflect)]`
|
||
//! type, it tells the derive macro for `Reflect` to add the following single line to its
|
||
//! [`get_type_registration`] method (see the relevant code[^1]).
|
||
//!
|
||
//! ```
|
||
//! # use bevy_reflect::{FromType, Reflect};
|
||
//! # use bevy_ecs::prelude::{ReflectComponent, Component};
|
||
//! # #[derive(Default, Reflect, Component)]
|
||
//! # struct A;
|
||
//! # impl A {
|
||
//! # fn foo() {
|
||
//! # let mut registration = bevy_reflect::TypeRegistration::of::<A>();
|
||
//! registration.insert::<ReflectComponent>(FromType::<Self>::from_type());
|
||
//! # }
|
||
//! # }
|
||
//! ```
|
||
//!
|
||
//! This line adds a `ReflectComponent` to the registration data for the type in question.
|
||
//! The user can access the `ReflectComponent` for type `T` through the type registry,
|
||
//! as per the `trait_reflection.rs` example.
|
||
//!
|
||
//! The `FromType::<Self>::from_type()` in the previous line calls the `FromType<C>`
|
||
//! implementation of `ReflectComponent`.
|
||
//!
|
||
//! The `FromType<C>` impl creates a function per field of [`ReflectComponentFns`].
|
||
//! In those functions, we call generic methods on [`World`] and [`EntityWorldMut`].
|
||
//!
|
||
//! The result is a `ReflectComponent` completely independent of `C`, yet capable
|
||
//! of using generic ECS methods such as `entity.get::<C>()` to get `&dyn Reflect`
|
||
//! with underlying type `C`, without the `C` appearing in the type signature.
|
||
//!
|
||
//! ## A note on code generation
|
||
//!
|
||
//! A downside of this approach is that monomorphized code (ie: concrete code
|
||
//! for generics) is generated **unconditionally**, regardless of whether it ends
|
||
//! up used or not.
|
||
//!
|
||
//! Adding `N` fields on `ReflectComponentFns` will generate `N × M` additional
|
||
//! functions, where `M` is how many types derive `#[reflect(Component)]`.
|
||
//!
|
||
//! Those functions will increase the size of the final app binary.
|
||
//!
|
||
//! [^1]: `crates/bevy_reflect/bevy_reflect_derive/src/registration.rs`
|
||
//!
|
||
//! [`get_type_registration`]: bevy_reflect::GetTypeRegistration::get_type_registration
|
||
|
||
use super::from_reflect_with_fallback;
|
||
use crate::{
|
||
change_detection::Mut,
|
||
component::{ComponentId, ComponentMutability},
|
||
entity::Entity,
|
||
prelude::Component,
|
||
world::{
|
||
unsafe_world_cell::UnsafeEntityCell, EntityMut, EntityWorldMut, FilteredEntityMut,
|
||
FilteredEntityRef, World,
|
||
},
|
||
};
|
||
use bevy_reflect::{FromReflect, FromType, PartialReflect, Reflect, TypePath, TypeRegistry};
|
||
use disqualified::ShortName;
|
||
|
||
/// A struct used to operate on reflected [`Component`] trait of a type.
|
||
///
|
||
/// A [`ReflectComponent`] for type `T` can be obtained via
|
||
/// [`bevy_reflect::TypeRegistration::data`].
|
||
#[derive(Clone)]
|
||
pub struct ReflectComponent(ReflectComponentFns);
|
||
|
||
/// The raw function pointers needed to make up a [`ReflectComponent`].
|
||
///
|
||
/// This is used when creating custom implementations of [`ReflectComponent`] with
|
||
/// [`ReflectComponent::new()`].
|
||
///
|
||
/// > **Note:**
|
||
/// > Creating custom implementations of [`ReflectComponent`] is an advanced feature that most users
|
||
/// > will not need.
|
||
/// > Usually a [`ReflectComponent`] is created for a type by deriving [`Reflect`]
|
||
/// > and adding the `#[reflect(Component)]` attribute.
|
||
/// > After adding the component to the [`TypeRegistry`],
|
||
/// > its [`ReflectComponent`] can then be retrieved when needed.
|
||
///
|
||
/// Creating a custom [`ReflectComponent`] may be useful if you need to create new component types
|
||
/// at runtime, for example, for scripting implementations.
|
||
///
|
||
/// By creating a custom [`ReflectComponent`] and inserting it into a type's
|
||
/// [`TypeRegistration`][bevy_reflect::TypeRegistration],
|
||
/// you can modify the way that reflected components of that type will be inserted into the Bevy
|
||
/// world.
|
||
#[derive(Clone)]
|
||
pub struct ReflectComponentFns {
|
||
/// Function pointer implementing [`ReflectComponent::insert()`].
|
||
pub insert: fn(&mut EntityWorldMut, &dyn PartialReflect, &TypeRegistry),
|
||
/// Function pointer implementing [`ReflectComponent::apply()`].
|
||
pub apply: fn(EntityMut, &dyn PartialReflect),
|
||
/// Function pointer implementing [`ReflectComponent::apply_or_insert()`].
|
||
pub apply_or_insert: fn(&mut EntityWorldMut, &dyn PartialReflect, &TypeRegistry),
|
||
/// Function pointer implementing [`ReflectComponent::remove()`].
|
||
pub remove: fn(&mut EntityWorldMut),
|
||
/// Function pointer implementing [`ReflectComponent::contains()`].
|
||
pub contains: fn(FilteredEntityRef) -> bool,
|
||
/// Function pointer implementing [`ReflectComponent::reflect()`].
|
||
pub reflect: fn(FilteredEntityRef) -> Option<&dyn Reflect>,
|
||
/// Function pointer implementing [`ReflectComponent::reflect_mut()`].
|
||
pub reflect_mut: fn(FilteredEntityMut) -> Option<Mut<dyn Reflect>>,
|
||
/// Function pointer implementing [`ReflectComponent::reflect_unchecked_mut()`].
|
||
///
|
||
/// # Safety
|
||
/// The function may only be called with an [`UnsafeEntityCell`] that can be used to mutably access the relevant component on the given entity.
|
||
pub reflect_unchecked_mut: unsafe fn(UnsafeEntityCell<'_>) -> Option<Mut<'_, dyn Reflect>>,
|
||
/// Function pointer implementing [`ReflectComponent::copy()`].
|
||
pub copy: fn(&World, &mut World, Entity, Entity, &TypeRegistry),
|
||
/// Function pointer implementing [`ReflectComponent::register_component()`].
|
||
pub register_component: fn(&mut World) -> ComponentId,
|
||
}
|
||
|
||
impl ReflectComponentFns {
|
||
/// Get the default set of [`ReflectComponentFns`] for a specific component type using its
|
||
/// [`FromType`] implementation.
|
||
///
|
||
/// This is useful if you want to start with the default implementation before overriding some
|
||
/// of the functions to create a custom implementation.
|
||
pub fn new<T: Component + FromReflect + TypePath>() -> Self {
|
||
<ReflectComponent as FromType<T>>::from_type().0
|
||
}
|
||
}
|
||
|
||
impl ReflectComponent {
|
||
/// Insert a reflected [`Component`] into the entity like [`insert()`](EntityWorldMut::insert).
|
||
pub fn insert(
|
||
&self,
|
||
entity: &mut EntityWorldMut,
|
||
component: &dyn PartialReflect,
|
||
registry: &TypeRegistry,
|
||
) {
|
||
(self.0.insert)(entity, component, registry);
|
||
}
|
||
|
||
/// Uses reflection to set the value of this [`Component`] type in the entity to the given value.
|
||
///
|
||
/// # Panics
|
||
///
|
||
/// Panics if there is no [`Component`] of the given type.
|
||
///
|
||
/// Will also panic if [`Component`] is immutable.
|
||
pub fn apply<'a>(&self, entity: impl Into<EntityMut<'a>>, component: &dyn PartialReflect) {
|
||
(self.0.apply)(entity.into(), component);
|
||
}
|
||
|
||
/// Uses reflection to set the value of this [`Component`] type in the entity to the given value or insert a new one if it does not exist.
|
||
///
|
||
/// # Panics
|
||
///
|
||
/// Panics if [`Component`] is immutable.
|
||
pub fn apply_or_insert(
|
||
&self,
|
||
entity: &mut EntityWorldMut,
|
||
component: &dyn PartialReflect,
|
||
registry: &TypeRegistry,
|
||
) {
|
||
(self.0.apply_or_insert)(entity, component, registry);
|
||
}
|
||
|
||
/// Removes this [`Component`] type from the entity. Does nothing if it doesn't exist.
|
||
pub fn remove(&self, entity: &mut EntityWorldMut) {
|
||
(self.0.remove)(entity);
|
||
}
|
||
|
||
/// Returns whether entity contains this [`Component`]
|
||
pub fn contains<'a>(&self, entity: impl Into<FilteredEntityRef<'a>>) -> bool {
|
||
(self.0.contains)(entity.into())
|
||
}
|
||
|
||
/// Gets the value of this [`Component`] type from the entity as a reflected reference.
|
||
pub fn reflect<'a>(&self, entity: impl Into<FilteredEntityRef<'a>>) -> Option<&'a dyn Reflect> {
|
||
(self.0.reflect)(entity.into())
|
||
}
|
||
|
||
/// Gets the value of this [`Component`] type from the entity as a mutable reflected reference.
|
||
///
|
||
/// # Panics
|
||
///
|
||
/// Panics if [`Component`] is immutable.
|
||
pub fn reflect_mut<'a>(
|
||
&self,
|
||
entity: impl Into<FilteredEntityMut<'a>>,
|
||
) -> Option<Mut<'a, dyn Reflect>> {
|
||
(self.0.reflect_mut)(entity.into())
|
||
}
|
||
|
||
/// # Safety
|
||
/// This method does not prevent you from having two mutable pointers to the same data,
|
||
/// violating Rust's aliasing rules. To avoid this:
|
||
/// * Only call this method with a [`UnsafeEntityCell`] that may be used to mutably access the component on the entity `entity`
|
||
/// * Don't call this method more than once in the same scope for a given [`Component`].
|
||
///
|
||
/// # Panics
|
||
///
|
||
/// Panics if [`Component`] is immutable.
|
||
pub unsafe fn reflect_unchecked_mut<'a>(
|
||
&self,
|
||
entity: UnsafeEntityCell<'a>,
|
||
) -> Option<Mut<'a, dyn Reflect>> {
|
||
// SAFETY: safety requirements deferred to caller
|
||
unsafe { (self.0.reflect_unchecked_mut)(entity) }
|
||
}
|
||
|
||
/// Gets the value of this [`Component`] type from entity from `source_world` and [applies](Self::apply()) it to the value of this [`Component`] type in entity in `destination_world`.
|
||
///
|
||
/// # Panics
|
||
///
|
||
/// Panics if there is no [`Component`] of the given type or either entity does not exist.
|
||
pub fn copy(
|
||
&self,
|
||
source_world: &World,
|
||
destination_world: &mut World,
|
||
source_entity: Entity,
|
||
destination_entity: Entity,
|
||
registry: &TypeRegistry,
|
||
) {
|
||
(self.0.copy)(
|
||
source_world,
|
||
destination_world,
|
||
source_entity,
|
||
destination_entity,
|
||
registry,
|
||
);
|
||
}
|
||
|
||
/// Register the type of this [`Component`] in [`World`], returning its [`ComponentId`].
|
||
pub fn register_component(&self, world: &mut World) -> ComponentId {
|
||
(self.0.register_component)(world)
|
||
}
|
||
|
||
/// Create a custom implementation of [`ReflectComponent`].
|
||
///
|
||
/// This is an advanced feature,
|
||
/// useful for scripting implementations,
|
||
/// that should not be used by most users
|
||
/// unless you know what you are doing.
|
||
///
|
||
/// Usually you should derive [`Reflect`] and add the `#[reflect(Component)]` component
|
||
/// to generate a [`ReflectComponent`] implementation automatically.
|
||
///
|
||
/// See [`ReflectComponentFns`] for more information.
|
||
pub fn new(fns: ReflectComponentFns) -> Self {
|
||
Self(fns)
|
||
}
|
||
|
||
/// The underlying function pointers implementing methods on `ReflectComponent`.
|
||
///
|
||
/// This is useful when you want to keep track locally of an individual
|
||
/// function pointer.
|
||
///
|
||
/// Calling [`TypeRegistry::get`] followed by
|
||
/// [`TypeRegistration::data::<ReflectComponent>`] can be costly if done several
|
||
/// times per frame. Consider cloning [`ReflectComponent`] and keeping it
|
||
/// between frames, cloning a `ReflectComponent` is very cheap.
|
||
///
|
||
/// If you only need a subset of the methods on `ReflectComponent`,
|
||
/// use `fn_pointers` to get the underlying [`ReflectComponentFns`]
|
||
/// and copy the subset of function pointers you care about.
|
||
///
|
||
/// [`TypeRegistration::data::<ReflectComponent>`]: bevy_reflect::TypeRegistration::data
|
||
/// [`TypeRegistry::get`]: bevy_reflect::TypeRegistry::get
|
||
pub fn fn_pointers(&self) -> &ReflectComponentFns {
|
||
&self.0
|
||
}
|
||
}
|
||
|
||
impl<C: Component + Reflect + TypePath> FromType<C> for ReflectComponent {
|
||
fn from_type() -> Self {
|
||
// TODO: Currently we panic if a component is immutable and you use
|
||
// reflection to mutate it. Perhaps the mutation methods should be fallible?
|
||
ReflectComponent(ReflectComponentFns {
|
||
insert: |entity, reflected_component, registry| {
|
||
let component = entity.world_scope(|world| {
|
||
from_reflect_with_fallback::<C>(reflected_component, world, registry)
|
||
});
|
||
entity.insert(component);
|
||
},
|
||
apply: |mut entity, reflected_component| {
|
||
if !C::Mutability::MUTABLE {
|
||
let name = ShortName::of::<C>();
|
||
panic!("Cannot call `ReflectComponent::apply` on component {name}. It is immutable, and cannot modified through reflection");
|
||
}
|
||
|
||
// SAFETY: guard ensures `C` is a mutable component
|
||
let mut component = unsafe { entity.get_mut_assume_mutable::<C>() }.unwrap();
|
||
component.apply(reflected_component);
|
||
},
|
||
apply_or_insert: |entity, reflected_component, registry| {
|
||
if C::Mutability::MUTABLE {
|
||
// SAFETY: guard ensures `C` is a mutable component
|
||
if let Some(mut component) = unsafe { entity.get_mut_assume_mutable::<C>() } {
|
||
component.apply(reflected_component.as_partial_reflect());
|
||
} else {
|
||
let component = entity.world_scope(|world| {
|
||
from_reflect_with_fallback::<C>(reflected_component, world, registry)
|
||
});
|
||
entity.insert(component);
|
||
}
|
||
} else {
|
||
let component = entity.world_scope(|world| {
|
||
from_reflect_with_fallback::<C>(reflected_component, world, registry)
|
||
});
|
||
entity.insert(component);
|
||
}
|
||
},
|
||
remove: |entity| {
|
||
entity.remove::<C>();
|
||
},
|
||
contains: |entity| entity.contains::<C>(),
|
||
copy: |source_world, destination_world, source_entity, destination_entity, registry| {
|
||
let source_component = source_world.get::<C>(source_entity).unwrap();
|
||
let destination_component =
|
||
from_reflect_with_fallback::<C>(source_component, destination_world, registry);
|
||
destination_world
|
||
.entity_mut(destination_entity)
|
||
.insert(destination_component);
|
||
},
|
||
reflect: |entity| entity.get::<C>().map(|c| c as &dyn Reflect),
|
||
reflect_mut: |entity| {
|
||
if !C::Mutability::MUTABLE {
|
||
let name = ShortName::of::<C>();
|
||
panic!("Cannot call `ReflectComponent::reflect_mut` on component {name}. It is immutable, and cannot modified through reflection");
|
||
}
|
||
|
||
// SAFETY: guard ensures `C` is a mutable component
|
||
unsafe {
|
||
entity
|
||
.into_mut_assume_mutable::<C>()
|
||
.map(|c| c.map_unchanged(|value| value as &mut dyn Reflect))
|
||
}
|
||
},
|
||
reflect_unchecked_mut: |entity| {
|
||
if !C::Mutability::MUTABLE {
|
||
let name = ShortName::of::<C>();
|
||
panic!("Cannot call `ReflectComponent::reflect_unchecked_mut` on component {name}. It is immutable, and cannot modified through reflection");
|
||
}
|
||
|
||
// SAFETY: reflect_unchecked_mut is an unsafe function pointer used by
|
||
// `reflect_unchecked_mut` which must be called with an UnsafeEntityCell with access to the component `C` on the `entity`
|
||
// guard ensures `C` is a mutable component
|
||
let c = unsafe { entity.get_mut_assume_mutable::<C>() };
|
||
c.map(|c| c.map_unchanged(|value| value as &mut dyn Reflect))
|
||
},
|
||
register_component: |world: &mut World| -> ComponentId {
|
||
world.register_component::<C>()
|
||
},
|
||
})
|
||
}
|
||
}
|