Hierarchy propagation opt-out #7225
Labels
C-Usability
A targeted quality-of-life change that makes Bevy easier to use
D-Complex
Quite challenging from either a design or technical perspective. Ask for help!
X-Controversial
There is active debate or serious implications around merging this PR
What problem does this solve or what need does it fill?
There are a lot of cases where I'd like to group entities logically together, but I can't because it would mean their positions would be required to be relative to each-other.
For example, one common usecase I've found (maybe a bit more common for me than other people given the physics-y-ness of my project) is anything with a joint needs to not have a parent entity. Otherwise the joint will either be overridden by the transform propagation and the joint essentially doesn't exist or it explodes out to infinity because it'd try to keep correcting position.

These are all logically the
Player 1
entity in my mental model, but the hierarchy doesn't really represent that very well, it also makes it more difficult to traverse this non-standard hierarchy which I have ended up having to do quite often.What solution would you like?
Adding a
Split
component that would act as if it wasn't a child of its parent during propagation.Or maybe call it
NoTransformPropagation
if it won't be that generic over the different propagation stuffs.What alternative(s) have you considered?
The text was updated successfully, but these errors were encountered: