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.

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

Improve ergonomics when using parent/child relationships with component hooks #14545

Open
piedoom opened this issue Jul 31, 2024 · 1 comment
Labels
A-ECS Entities, components, systems, and events A-Hierarchy Parent-child entity hierarchies C-Usability A targeted quality-of-life change that makes Bevy easier to use

Comments

@piedoom
Copy link

piedoom commented Jul 31, 2024

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

When using component hooks, it is possible to access the Entity Parent on_remove but not on_add or on_insert, specifically when using a child builder. It would be ideal to always have access to the Parent in any hook while using the child builder.

This is somewhat unexpected behavior from the perspective of someone learning hooks, as it is unclear why one state functions while the does not. Furthermore, it is possible to work around the child builder problem by manually setting a parent with set_parent, however this is discouraged by Bevy's docs in favor of the child builder, and it is still opaque as to why one method works without understanding a bit about how Bevy's parent/child hierachy works.

Concrete use-case

In my game, I have a parent Entity that has an inventory. When inventory items are equipped, they are spawned as children onto the parent entity. I like this approach because it feels idiomatic with an ECS, but it does require extra internal state tracking for the inventory. For instance, the inventory has a maximum size. Instead of calculating the size every frame, it's nice to track the space used as a separate variable, and update it whenever I add or remove an equip. This seems like an ideal use for hooks, but I need to be able to access the parent entity. Note the hierarchy is required so I can add multiple items of the same type of component, e.g. two weapons can be equipped at once.

What solution would you like?

I am unsure as to the technical implementation, but ideally I could use a child builder as normal and access the Parent entity in any hook.

What alternative(s) have you considered?

  • Manually setting via set_parent
    • This is a good workaround, but not obvious when or why it should be used over child builder, and is prone to errors
  • Adding a specific system to track Added<T> components instead of using on_add
    • This is a more robust method, but it separates code into two orthogonal boxes. I keep components in a separate module from systems and plugins, so this would mean I'd have logic that does roughly the same thing in two very different places in my codebase, which isn't great ergonomically.

Additional information:

Original discussion post

@piedoom piedoom added C-Feature A new feature, making something new possible S-Needs-Triage This issue needs to be labelled labels Jul 31, 2024
@alice-i-cecile
Copy link
Member

Related to #12235, but distinct.

@alice-i-cecile alice-i-cecile added A-ECS Entities, components, systems, and events C-Usability A targeted quality-of-life change that makes Bevy easier to use A-Hierarchy Parent-child entity hierarchies and removed C-Feature A new feature, making something new possible S-Needs-Triage This issue needs to be labelled labels Jul 31, 2024
@alice-i-cecile alice-i-cecile moved this to Active: engine observers and hooks in Alice's Work Planning Jul 31, 2024
@ItsDoot ItsDoot moved this to Todo in Relations Aug 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-ECS Entities, components, systems, and events A-Hierarchy Parent-child entity hierarchies C-Usability A targeted quality-of-life change that makes Bevy easier to use
Projects
Archived in project
Status: Todo
Development

No branches or pull requests

2 participants