Make hierarchy semi-mutable

[Shatur]

What problem does this solve or what need does it fill?

After proposal bevyengine/rfcs#53 and PR #4197 hierarchy became managable through commands. While this makes usage less error prone, it introduces several inconveniences. For example, when I want to store a scene, I have to store redundantly Children and Parent components, otherwise my scene will be broken. Same for replication over the network - I had to introduce an additional component (I called it SyncParent) that, when changed, pushes children through commands. But my workaround also not perfect because of one frame delay.

What solution would you like?

What if we do something similar to Transform and GlobalTransform? I.e. let user update Parent and the change will be propagated to Children.

[BoxyUwU]

The point of the rfc is that the hierarchy should never be in an invalid state. Allowing users to mutate Parent and then it getting updated some time later by a system violates that.

[Shatur]

Hmm... I understand why this might be a problem.
But current solution, unfortunately, leads to the problems described above. It's not just extra bytes in the scene/network transmission. Usually when users save a scene, they don't save all entities, some of them need to be filtered out (like 3D models). And Children could reference filtered entities which will lead to a scene loading error. And we can't mutate this component.

My workaround is to create a custom Parent component that will sync the hierarchy on insertion. So this is why I basically suggested to make Parent mutable and update the hierarchy on its change. This will solve the filtering issue and allow to store only Parent component in scenes. I.e. Parent will be like Transform and Children like GlobalTransform.

[mockersf]

Unlike Transform/GlobalTransform, Parent/Children are not on the same entities, and that can create issues if they are not updated in sync.

For example:

• spawn entity 1
• spawn entity 2
• set 1 as parent of 2
• despawn recursively 1

2 hasn't been despawned as recursion uses the Children component

[Shatur]

2 hasn't been despawned as recursion uses the Children component

Yes, this is an issue. I totally understand why Children and Parent are immutable. But just introduces a different inconveniences... Probably this should be solved by something like #4141. Clothing this one since the idea isn't good.