This has been a big issue for me, especially when rotating long parts or models such as roads. Currently, there is a tab option to summon the handle so the rotate tool can be shown in the screen, but it does not rotate along the pivot point. It would be good if there is an shortcut key to make the tool follow the pivot point instead of the summon point in both move and rotate tool.
For example, when building roads around curvy terrain, it is unclear how much to rotate at the end of the road. If I use the rotate tool and press Tab to summon the handle, it won’t follow the pivot point, resulting in incorrect rotation and position, making it very difficult to connect the roads.
This is really really really really annoying, and that’s understating it immensely.
I’ve had the beta for this enabled literally since the beta feature was first rolled out, since for the most part I like how it looks, and I’m still not used to this. I was counting on this eventually being rebindable and that’s why I never disabled the beta feature. To know it’s not becoming a thing really sucks. I literally can’t think of a single other application that uses anything but shift for uniform scaling – or at least one that doesn’t have it rebindable.
Is there a way to completely revert/hide the new changes? Mainly the line when moving a part on an axis, and the colored line from the original origin to the new origin.
While good for many people, it disrupts my workflow so horrendously and feels more like visual clutter than something helpful. Additionally, the Shift key disabling the snapping function being forced feels like such a slap in the face for someone who prefers the old studio. So far, all of the new QoL changes feel more like brand new hinderances than anything else.
I don’t see why they moved uniform scaling to ALT, they could have kept it on SHIFT and just made ALT the key bind to disable snapping, seems counter intuitive to swap hotkeys around when it seems unnecessary.
We had it both ways at different times under the beta.
Shift was actually how we planned to leave it before moving shift away from being snapping control midway through the beta was badly received. Detailed surveying with people who tried both found that using shift for snapping control was actually preferable to most of them.
So far I really like these new changes, however 1 thing:
The studio really needs key remapping feature.
When I entered studio, the very first addition that I met wasn’t any of mentioned in these posts, but the sudden unreasonable remap of all main tool hotkeys from Ctrl + 1-4, to Fn + 1-4
That’s really inconvinitent considering me, and most likely a ton of other people are used to the original hotkeys.
Edit: After using the update for a bit, its becoming somewhat comfortable, but what I also don’t like is the change of proportional scaling from holding Shift, to holding Alt.
I disabled the beta that kept the old draggers before this change is forced on me. Since I first enabled the beta with the first announcement of the new draggers, I still really hate this change. It’s overengineered for the sake of calling it a “better tool” and it really feels like the people working on it were really bored.
Why on God’s green earth do the snapping tool still work when the “Move” increment is disabled? It should disable along with it. While I can see the use case behind it, move increments are enabled by default at 1 stud with an easy way to change the increment if needed.
The rulers, while useful, are too distracting for my ADHD brain. That also goes for a lot of the UX changes in relation to the new draggers. I basically disabled them as soon as I figured out you could do it.
The reason Roblox studio is appealing is the fact that it’s easy to use and not overwhelming to the user. This isn’t it. The only good thing about it is the shortcuts it gives you in the output.
This feels like the studio UI toggle situation all over again where the engineers bent over backwards to call it “industry standard” and a “much better tool than what Roblox offered” (and lowkey insulted the people against the change - I was one of those people) just to revert their change a year later with the new viewport options. There are so many things you guys could be doing (like implementing shaders into the engine) but instead you’re wasting your time trying to reinvent the wheel.
Found another really annoying bug. I had a keycode mapped to the C key on my keyboard which is also mapped to the Toggle Snapping hotkey, and when testing and trying to use the C key while holding down shift doesn’t register that key press. So if I had a sprint system that uses the Shift key and a crouch toggle mapped to the C key then UserInputService will ignore that InputBegan input (InputEnded appears to still work). This is true for the X key as well, so if I wanted to map prone to the X key then it would also not register. I had to remap the keys so I can properly test again.
I don’t personally have a problem with remapping the keys but Is it possible to have the dragger hotkeys only register if you have the tool activated? I can definitely see a scenario where someone in the future might encounter this issue and have no idea why their keys are not being registered properly.
Honestly not a fan of this update, yes the measurements and such may be a nice change, but overall things feel harder to do than before. wasting solid minutes of time!
You might notice that this already works for the 1/2/3/4 keys: The backpack’s function is not interrupted while testing despite the hotkey conflict. Shift + those 9 keys on that side of the keyboard should probably get a similar treatment because of how common a gameplay interaction that is.
This entire change is infuriating. If I could disable this entirely FOREVER then I would, but this is getting shoved down our throats.
Keep the keybinds the same as legacy or add a way to adjust them. The fact that now Ctrl and Shift scale the same way and I have to press Alt is annoying. I wouldn’t complain if Studio had extensive keybind settings but it doesn’t. Add a checkbox to use legacy keybinds.
Please get rid of whatever this yellow line is and replicate the legacy behavior. While it could be useful for some in very specific situations, having it on by default is annoying and impossible to work with. I want to be able to drag from the center and use the bounding box as its collision. I noticed that you can drag from the origin/pivot but it’s not the same at all as it has collision not at the bounding box but the origin. As a result the entire object sinks into the ground. Not to mention to get into that dragging mode is extremely difficult as you have to aim and get your mouse just right to click/drag the origin/pivot. I no longer have control of where I want the object placed and this is extremely damaging to my workflow with how I manage and drag objects. Please add a checkbox to disable the yellow surface dragging and a button to enable bounding box drag collision.
I don’t understand why its so hard for this to just be an addition to legacy features and not a replacement. This isn’t QoL this is ruining workflow we have had for decades. I would have no issue if the dragging and keybinds were the exact same as the legacy dragging. Keybinds sure you can get used to but changing the entire behavior of dragging is unexpectable. Other than that moving using handles, rotation, and scaling works the same as legacy.
I will NOT be using this feature until it’s fixed/behaves the same as legacy or of course when this is shoved down my throat permanently.
The exaggeration isn’t helpful. The current iteration of the draggers have existed for less than 4 years. The current draggers are already drastically diverged in behavior from what we had before that.
Could you elaborate? I don’t understand what change in behavior you’re referencing here. Is grabbing the pivot to drag by it getting in the way of traditional follow-the-cursor dragging or are you talking about something else?
If you’re talking about the part snapping to nearby geometry, all you need to do to disable that is uncheck “Snap to Parts”.
The default keybinding changed. It’s now just 1/2/3/4 with no control. Though you can add back control in File -> Advanced -> Customize Shortcuts... if you don’t want to change your muscle memory.
To be honest this person is not exaggerating. I can barely focus on building even a simple chair with all of those lines popping up. This of course wouldn’t be a problem if there was a way to disable this monstrosity (a toggle). But to my knowledge this word is one of those words Roblox can’t understand what it means…
Actually, the UX changes to this tool had likely the most staff engagement and user feedback integrated ever. The amount of engagement the community has had in driving these changes in the right direction is a shining gold star example of great communication.
A lot of the angry replies here are from people who willfully ignored these changes in beta this whole time and are finding out now that they’re obviously still going to happen, and that they still need to relearn some muscle memory. These people are younger than I am. These people have a greater capacity to learn than I do. I love these changes and had no problems adopting them.
All that’s left now are nitpicks and bugs, and for people to learn that they can turn off things they don’t like.
Give your feedback respectfully if you want anyone to listen to you. This reply does not reflect well.
I can’t even see the selection box while I am hovering over a part. This is how bad this update is, it broke my hole selection box hover thingy. To be fair I did turn off a few settings in studio setting stab but that was while I have the beta feature on. And after I turned it off, not it’s broken. You love to see it.
Edit: I didn’t check if it’s still broken. I will check maybe tomorrow since It’s pretty late for were I leave
Edit2: I just turned off hover selection by accident. the beta feature didn’t broke anything.
