Right now, the hammer strike can merge Builds containing a single piece no problem.
Going back to that image from five days ago…
I can join pieces A and B together and C and D. But after that, if I join B and C then either A or D will simply disappear. And the nail that connected it.
That’s because when I merge pieces I’m not traversing the graph at all. I’m just adding the one piece and then deleting the Build that it came from.
…
For each step in the traversal, I need to know the last piece I attached, and the hardware and build piece that I will attach next. Or just check the list of previously visited piece IDs. It’s cheap. That way I can just track which piece to add next.
…
It works! Wute. I was also sure to test with cycles in the build graph.
Now I need to update the origin of the build as pieces are added to it. In the picture above, each piece is a separate build and the little white plus signs indicate their origins.
After hammer striking all the pieces together into a single build, the center of the build ends up being that of one of the build pieces. It’s hard to control which and it almost always ends up looking silly when you pick it up.
The worst is when you rotate the build.
…
Alright so problem. When I recenter the origin, I’m shifting the position of the Build by offset and shifting the position of all the Build’s children by negative offset. That gets it into the right spot but the physics engine freaks out. Frame to frame all the collision shapes are in the same place but I guess the collisions that were occurring in the previous frame are treated as new..? Either way, this isn’t gonna work.
Is it because it’s not happening during _physics_process()?
Nope. I tried invalidating the origin and waiting until _physics_process() to update it but the effect was exactly the same.
I’ll just add a method to fetch the center and use that when carrying and rotating.
Should I be using the centroid instead of the center of the axis-aligned bounding box? The center changes a little bit for the latter and wouldn’t for the former. Right now all pieces have four vertices so they’re equally weighted. I’d need a new way to calculate the centroid if some pieces have more complex shapes than other but for now it’s fine. I guess I could calculate the centroid of each piece and then use those to calculate the centroid of the build to ensure each piece is equally weighted.
Doesn’t sound too bad.