Thanks! Sorry I was unable to change the title to something more specific, like “Typing new Move increment sometimes adds text to end instead of replacing”
1 Like
No problem at all.
Fun fact when I quickly made this ticket earlier this week I called it “Entering decimal point values in Move Studs is wonky” 
4 Likes
Before I forget: this was fixed and should be available in next week’s release (5/3/2023)
4 Likes
Thanks for the heads up! Just today I was about to post a comment asking if this had been followed up. Thank you!
1 Like
The 573 release just went live moments ago. This should be resolved for you 
3 Likes
The fix went through! Though it seems that the other part of the bug still remains: whenever you type “.125” the pointer remains at the decimal position.
It’s the bug pointed out here Decimal move increment adjustments - Bug Reports / Studio Bugs - DevForum | Roblox
Hopefully it gets fixed soon as well, thanks!
For reference, this is me typing in “.125”, and the result is “.251”
2 Likes
Thanks! I’ve let the team know. I think there’s still some work happening with move increments so hopefully they can touch this up with that.
3 Likes
Can confirm, next week’s release will have a more comprehensive set of improvements to the Snap to Grid boxes which should resolve all of the existing issues with them (uncap minimum grid snap, fix typing problems, improve handling of zero, etc).
4 Likes
Awesome to hear! Thanks for providing some insight, can’t wait for the improvements!
1 Like
Circling back to this bug before the thread cools down again. Seems like the bug is persisting even after yesterday’s push.
Typing decimal, 1, 2 ,3 resulted in the same bugged behavior as above.
1 Like
That’s because I hadn’t turned on the changes yet, I have now and this should be resolved for good:
4 Likes
The bug had been fixed some time ago. Unfortunately, it seems to have returned.
1 Like
Indeed. We needed to amend the fix because it ran into issues 
, it’ll be fixed again next Wednesday.
4 Likes
This is still an issue in July
Huh, I’m not seeing the issue. What platform are you on?
The repro mentions if you move the mouse cursor while clicking, this happens. In this video I was showing it off with 100% repro rate while typing 1 2 3 4 and carefully avoiding moving the mouse for 5
In the vid I’m intentionally doing it to show it off, but it was annoying me for years how it would happen seemingly randomly, maybe 1 in 5 or 10 times, while not intentionally moving the mouse while clicking; it just happens while quickly building
Still windows 10, haven’t upgraded in this time
Oh I see.
This isn’t really a bug, is it? That’s just how textboxes work, if you move your cursor while clicking on them you’re drag selecting text, and if that drag select is off of the end of the text it will select nothing and put the cursor at the end.
How bad of an issue is this? It would take some truly heroic hacking of Qt to get a different behavior here and possibly mess up some of the other text selection mechanics in the box.
Ah, true. Clicking the box selects the whole thing to be able to clear & replace it in one stroke, which is different than every other textbox which would just place the cursor where you clicked or at the end; this makes the clear & replace functionality fail if the mouse slightly moves during the process. It was driving me nuts while building, personally. Trying to move something 2 studs and it turns into 12, then 122. 
I’m not sure what the best UX here would be; perhaps a shortcut keybind to select the entire text, which avoids the drag behavior and readies it for replacing. Or a UI button that does the same.
I’ve heard other people want a shortcut to focus the grid snap increment box regardless of this issue. One of the things people miss from SBS. I’ll look into that.
Hello,
This bug is still frustrating me even today and I’ll be illustrating why I think this is a bug that needs addressing:
Action for reproduction: Click, hold, and move a pixel while holding. In the one bugged location, it unhighlights the selection.
Unintended behavior (bug):
100% repro when intending to do it, but this happens accidentally enough that it causes frustration when your increment gets set to something like 501.
Intended behavior (for example, in Properties):
Nice! Keeps its selection