You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Big love for Bevy here (namely language choice, ECS, scope and API design ❤️ ). Thank you!
While playing around with Bevy in the context of Rapier, I struggled with getting newly created entities within the context of with_children, as the way to get entities that I knew (current_entity) is not exposed on the ChildBuilder struct. Rapier needs references to the entities when you build joints.
Thanks to the Discord I learned that it was possible to just not use with_children but rather collect what you need with current_entity and use push_children later.
Since with_children seems like a expressive way to declare entity hierarchy, I'd prefer to have access to an entity within it.
It also feels like there might be a larger point here wrt API simplification, things that are feeling a bit weird to me right now:
there's multiple ways to declare a hierarchy (with_children, insert_children, push_children), isn't one enough?
there's multiple ways to declare components for entities (spawn, with, with_bundle)
current_entity makes CommandsInternal feel like a stateful-iterator-esque thing and then there are methods which need to check whether the entity is even set. Might
somewhat related, I just noticed that there is also for_current_entity which seems to be another API to get an entity handle. I'm wondering whether these two APIs might be better dropped in favor of a variant of spawn which has this FnOnce(Entity) type as a second param
I'm also starting to appreciate the value of method chaining here and am wondering whether moving the with_*-fns to a new struct which is returned by spawn might be feasible, thereby alleviating those fns of the need to current_entity-check, aka making illegal state impossible
Okay sorry these spitballs turned into the lion share of the post, I'll make a PR for the less controversial first part now :)
The text was updated successfully, but these errors were encountered:
Big love for Bevy here (namely language choice, ECS, scope and API design ❤️ ). Thank you!
While playing around with Bevy in the context of Rapier, I struggled with getting newly created entities within the context of
with_children
, as the way to get entities that I knew (current_entity
) is not exposed on theChildBuilder
struct. Rapier needs references to the entities when you build joints.Thanks to the Discord I learned that it was possible to just not use
with_children
but rather collect what you need withcurrent_entity
and usepush_children
later.Since
with_children
seems like a expressive way to declare entity hierarchy, I'd prefer to have access to an entity within it.It also feels like there might be a larger point here wrt API simplification, things that are feeling a bit weird to me right now:
with_children
,insert_children
,push_children
), isn't one enough?spawn
,with
,with_bundle
)current_entity
makesCommandsInternal
feel like a stateful-iterator-esque thing and then there are methods which need to check whether the entity is even set. Mightfor_current_entity
which seems to be another API to get an entity handle. I'm wondering whether these two APIs might be better dropped in favor of a variant ofspawn
which has thisFnOnce(Entity)
type as a second paramwith_*
-fns to a new struct which is returned byspawn
might be feasible, thereby alleviating those fns of the need to current_entity-check, aka making illegal state impossibleOkay sorry these spitballs turned into the lion share of the post, I'll make a PR for the less controversial first part now :)
The text was updated successfully, but these errors were encountered: