Inconsistent select/drag tool behaviour, floating point issues

[Auhrii]

Hello! I’m experiencing issues with the select/drag tool wherein it’ll induce random offsets, sometimes visible, sometimes not.

My current dragger settings are Geometric mode with collisions, join surfaces, and snap to parts disabled (also tried with this one enabled, with no difference in behaviour), and a 1 stud transform and 15 degree rotation resolution. I default to using local space transforms.

Some examples. The part below this is 64 studs wide, I dragged the upper part (width 1) from its lower edge that’s visibly offset here:

Dragging the part again usually fixes it, but if I don’t catch this immediately it means having to readjust the parts next to it, which leads me to:

The pavement part here was dragged by the upper edge that’s meant to meet up here. The asphalt part is at exactly Y=396, but the pavement part has, for reasons I cannot fathom, snapped in place at Y=395.992. Both parts have a height of exactly 2. Dragging the pavement again set its Y=395.998. I ended up having to manually set the Y position in the explorer when subsequent attempts would yield 395.998.

I disabled the Dragger QoL Improvements beta with no change in behaviour. Whilst I doubt any of the other current betas would affect this, here are the ones I have enabled:

Enabled Betas

• 4k Texture Rendering
• Acoustic Simulation
• Avatar Joint Upgrade
• Dragger QoL Improvements
• Emissive Maps
• glTF Export
• Improved Constraint Tool
• In-Experience Avatar Auto Setup
• Live Animation Creator
• Multi-line Command Bar
• New Luau type solver
• New Studio Camera Controls
• New Video API
• Next Gen Studio Preview
• Party Simulator
• Proximity Prompt Indicators
• Reimport
• Revamped Asset Manager
• Script Sync
• Server Authority Core API
• User Provided Default Instances
• Video Uploads

I never noticed anything like this behaviour with the old select and move tools (back when they were still selected with ctrl+1, 2, etc) unless I was trying to align parts with non-integer sizes along the faces I was trying to align.

Expected behavior

I expect parts with integer sizes to snap together with their edges flush, not with a random offset.

[tnavarts]

In these cases is the orientation at aligned to 90 degree angles or are both the orientation and position messed up together?

[Auhrii]

Relative orientation seems fine, only translation appears to be affected. I only notice orientation misalignments in live with particularly long parts, which as I recall is a separate and known issue.

[tnavarts]

Yeah, part orientation is replicated to clients at lower precision in some cases to save bandwidth, Studio always uses full precision so it’s unrelated to that.

Could you try to watch out for specific things that cause this? I’m aware of some ways devs can end up with these results for meshes but it seems you’re running into it even for normal square part primitives. I don’t have any ideas on what might be wrong in your case.

[Auhrii]

Can do, it seems random so far as I’m consistently grabbing parts by the edge I wish to align and dragging to the other aligning edge.

Just out of curiosity - are there any plans to alter replication behaviour? Orientation misalignments can be noticeable in live with particularly long parts (>100 studs), especially as even an offset of ~0.01 or more can cause strong ambient occlusion. Maybe anchored parts could have their position sent with full precision on initial game load to fix this?

[tnavarts]

Some ideas:

• Any pattern with how far you are from the origin when it happens?
• Any pattern of whether you have grid snap on or off when it happens? (are you relying on Part Snap instead of grid snap?)

[Auhrii]

• I’m fairly close to origin - the entire map is some 6k studs across, centred around <0, 0, 0>. I’ve built at most maybe 1k studs away vertically.
• This occurs with both grid snap and part snap, I observed no change in this behaviour when switching between the two before.