I’d like to add, while floating point errors are inevitable, I just tried in studio today, and moving a part 40 studs can cause it to rotate 15 degrees.
This is not remotely how it normally acts and has only become present to this degree sometime in the past couple of days.
I think I’ve also found a potentially related bug that’s happening with both lua draggers on and off. https://i.gyazo.com/42155da535b1ea186d31780d465e956d.mp4
Alt-clicking a part in a humanoid is not moving it individually.
I’m only guessing this is related because I’ve seen the listed problem occurring most commonly with humanoids.
Edit: Second “Bug” isn’t a bug, its just a change with how constraints work, deleting the constraints on each limb allows them to be moved individually fine with studio draggers (though the weird rotation problems are still occurring)
This is because you have the Constraints toggle turned on, so it’s being dragged via IK dragging rather than geometric dragging. The IK dragging is applying “force” through the center of the bounding box, so since the dragged object is not symmetrical, the heavier side lags causing it to tilt.
Yes, we’re aware that it’s not very obvious what’s going on in this case, we’re currently looking at ways to improve the situation.
So far I haven’t encountered the original issue with the Lua Draggers Beta yet. I think considering the Lua Draggers is currently what Roblox is focusing on, I think it’s safe to say it’s considered the solution to the issue.
For those windows, the glass pane at the top is thinner than the solid part at the bottom, so the bottom lags behind causing the tilt.
I would also add that even for perfectly symmetrical parts which don’t visibly tilt, using Constraints enabled dragging to move normal objects around is a bad idea, because it inherently generates a lot of floating point error thanks to being a physical simulation process.