Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Slightly nicer handling of parent/child failure modes #3199

Closed
wants to merge 2 commits into from
Closed

Slightly nicer handling of parent/child failure modes #3199

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
45a6492
Give a 'better' panic message when an entity has a broken parent
DJMcNab Nov 26, 2021
4bbc9f0
Change to despawning instead
DJMcNab Nov 26, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
36 changes: 23 additions & 13 deletions crates/bevy_transform/src/hierarchy/hierarchy_maintenance_system.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -8,6 +8,8 @@ use bevy_ecs::{
use bevy_utils::HashMap;
use smallvec::SmallVec;

use super::DespawnRecursiveExt;

pub fn parent_update_system(
mut commands: Commands,
removed_parent_query: Query<(Entity, &PreviousParent), Without<Parent>>,
Expand Down Expand Up @@ -45,20 +47,28 @@ pub fn parent_update_system(
commands.entity(entity).insert(PreviousParent(parent.0));
};

// Add to the parent's `Children` (either the real component, or
// `children_additions`).
if let Ok(mut new_parent_children) = children_query.get_mut(parent.0) {
// This is the parent
// PERF: Ideally we shouldn't need to check for duplicates
if !(*new_parent_children).0.contains(&entity) {
(*new_parent_children).0.push(entity);
match children_query.get_mut(parent.0) {
Ok(mut new_parent_children) => {
// This is the parent
// PERF: Ideally we shouldn't need to check for duplicates
if !(*new_parent_children).0.contains(&entity) {
(*new_parent_children).0.push(entity);
}
}
Err(bevy_ecs::query::QueryEntityError::QueryDoesNotMatch) => {
// The parent doesn't have a children component, lets add it
children_additions
.entry(parent.0)
.or_insert_with(Default::default)
.push(entity);
}
Err(bevy_ecs::query::QueryEntityError::NoSuchEntity) => {
// Our parent does not exist, so we should no longer exist.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this actually true? A parent no longer existing doesn't necessarily imply that the descendants should be despawned? Maybe the intent was to move the children to the top of the hierarchy?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Like I say in the PR body, we cannot reasonably check whether despawn or despawn_recursive was called on the parent entity.

In my mind, a parent with all its children is an atomic unit, so it's much more likely that the user wants to despawn this child

But in general, this messiness is a consequence of how messy our entire parent/child system is; that is, I doubt this will be the final state. However, this patch makes the current state nicer, fixing an issue which several users ran into.

// Please note that this is only triggered if `Parent` is changed.
// (e.g. if `Parent` is newly added, such as from scene spawning)
// So this is a slight hack
commands.entity(entity).despawn_recursive();
}
} else {
// The parent doesn't have a children entity, lets add it
children_additions
.entry(parent.0)
.or_insert_with(Default::default)
.push(entity);
}
}

Expand Down