Set move increment to 0.01 studs
Select any object with the move tool
Move the object in any direction
The object’s position to increment exactly 0.01 studs in the direction of movement
The object’s position increments at less than 0.01 studs in the direction of movement
At 0.012 increment or more, the object does move exactly at that increment, so it seems to be bugging at around the (0, 0.11] range.
We’ve filed a ticket to our internal database for this issue and will come back as soon as we have updates!
Thanks for the report!
Not actually a bug as per se, for historical reasons any grid snap smaller than approximately 0.01 studs is treated the same as snapping off.
However that’s not great behavior. 0.01 may have made sense as the minimum snap way back when the minimum part size was 0.2 studs, but now that the minimum part size is 0.001 studs it definitely isn’t adequate for every scenario.
I went ahead and made a change unbounding the minimum grid snap. Once the changes ship on May 3rd, any grid snap greater than zero should work, along with some other improvements to the grid snap box behavior (including a fix for the bad text input behavior that’s been bothering people recently).
I’ve enabled the changes:
The grid snap boxes should never get in the way of you entering the intended text anymore, they wait until you press enter or defocus the box to do anything interesting.
If you enter zero, the old value in the box will be left alone, and the enabled checkbox will be unchecked instead of the increment changing. This lets you easily disable snapping by entering zero if you change your mind mid-input.
There’s no more minimum snap value. However note that:
The snap box will visually round the displayed value to three digits, but does store the whatever arbitrarily small / precise value you enter under the hood.
The Rotate tool does not visually show ticks for increments smaller than 5° to avoid clutter, but behavior wise it does still snap to whatever small increment you enter.
Had to revert this for now because people who had last entered exactly “0” before I enabled it experienced broken dragging after the switch until they entered a different non-zero grid snap.
I’m not sure if this is related, but I noticed that when moving a part that has a thickness of 0.01 on a surface, it is slightly offset above the surface instead of being directly on it.
Where it should be:
I noticed that it is always offset by 0.025 studs in any direction of surface that it is placed on.
Not actually related. What’s going on there is that the physical minimum size of parts is still 0.05 studs, even when they are visually made smaller than that, and moving objects with Collisions enabled uses well… actual physical collisions to do its work.
That means it’s using that 0.05 physical size rather than the 0.01 visual size, hence the offset.
If you drag using freeform dragging it will exactly snap to the surface since that uses the logical size rather than the physical one.
Thank you!
Also, sorry to ask here but, how would I use/enable freeform dragging?
By “freeform dragging” I just mean clicking and dragging on the part (rather than the handles).
Yeah, I ended up directly clicking and dragging the thin parts, but I still couldn’t get that same surface snap effect with them than other parts.
I’m not sure if there’s a setting in studio that’s giving this offset or a recent update that caused this, but I’m kind of at a loss on what to do. For now, I decided to just resize the thin parts back to 0.05 studs.
Sorry, I’m going to have to add onto this as I still feel this has to do with some sort of move tool/increment bug. I’m trying to manually drag the part on the brick like you said to have it placed right on the top surface, however there’s always a slight offset and I have to manually edit the position.
Before, parts that I sized as less than 0.05 could snap onto any surface without any problems at all.
(I’m unable to make posts on the bug reports section, so I apologize for replying here)
No one can, you instead need to dm the @Bug-Support team and they’ll put your dm in this thread if it’s deemed worthy.
Ah, my bad, I know what this is.
We recently moved freeform dragging over to using Part.ExtentsSize / Part.ExtentsCFrame to figure out how to drag onto something. These do include the physical size, so freeform dragging will no longer avoid this.
Let me think about if we should do something to fix that or whether it makes sense as the intended behavior.
Fixed! Thanks again for the report.
