Studio draggers are causing floating point errors in the part's position values

[ChromeEight]

EDIT: Currently using this as a temporary solution: GridSnap Plugin - Roblox

Whenever I move or resize parts in Studio, the position coords of the parts tend to offset into floating point errors.
I noticed a few things:

• The offset does not occur when moving small parts (with average length of 20 studs and below)
• Offsets on the y-axis position occurs after a certain random length
• Offsets more commonly occur while resizing on the axis of the longer side
• Offsets occur while moving on either axis, but the y-axis position almost always offsets when moving on the longer side’s axis

Original part:

After duplicating the part and moving it a few studs away:

After moving the original part a few studs away:

After resizing the original part on its longer side:

After resizing the original part on its shorter side:

This bug is very frustrating as I have to make sure the positions do not offset, otherwise I would have connecting parts with gaps that I would need to fix, otherwise they would be visible ingame.

[LordHenryVonHenry]

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.

https://gyazo.com/0b3a445ea648d07723edbfd6a33048d9

https://i.gyazo.com/f58ea538dc18379f943f69fa288050dc.mp4

I’ve seen similar effects when using :SetPrimaryPartCFrame when 10,000+ studs away from 0,0,0, but this is on a default baseplate.

[marfit]

I had a similar issue, where I was moving parts of a car back and forth to edit it, and I noticed that it offset about .5 studs.

[Subcritical_alt]

Can you try with the Lua Draggers beta feature enabled and report whether this still happens?

[JoshSedai (Josh)]

Hi, could you let us know if this still happens with the beta Lua draggers?

[LordHenryVonHenry]

Still occurs with the lua draggers.
https://i.gyazo.com/cb8a90359acc0190f0011ce7f8c8ac2b.mp4

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)

[tnavarts]

@LordHenryVonHenry

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 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.

[tnavarts]

Could you test whether the original floating point issue brought up here still occurs with the Lua Draggers Beta enabled?

[ChromeEight]

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.

[ChromeEight]

update: New draggers causing rotation floating point errors

[tnavarts]

If you could try to isolate the kind of actions that trigger this behavior it would be a huge help. The detailed info in the original post was very helpful.

[ChromeEight]

I’ll reply again if I manage to encounter the behavior while using the new draggers.

[LordHenryVonHenry]

That makes sense for the humanoids, but to my knowledge doesn’t explain the issue with just general models that was occurring sometimes?
https://gyazo.com/0b3a445ea648d07723edbfd6a33048d9

[tnavarts]

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.

[ChromeEight]

I have something now.

• Rotation errors occur when attempting to rotate a part by 180 degrees
• These errors do not occur with parts shorter than 4 studs long.

1. 77.5 studs long (77.5 x 2 x 1)
   

   

2. 10 studs long (10 x 2 x 1)
   

   

3. 5 studs long (5 x 2 x 1)
   

   

4. 4 studs long (4 x 2 x 1)
   

   

[tnavarts]

Thanks. I’m going to add a special case for rotations which are very close to multiples of 90 degrees to avoid any floating point error in those cases.