This is great! Now I don’t have to spend 2 minutes trying to snap to corners!
4 Likes
As for people who are having the issue with scaling parts: The issue with scaling the incorrect face ocurrs when you scale a single part in Global Coordinate mode. As a temporary workaround make sure you’re in Local Coordinate mode (switch by pressing Ctrl + L) before you scale a single part.
1 Like
Two word’s, thank you! This has been a problem for so long!
2 Likes
I’m also experiencing this. I work in a large place as well and my PC just can’t handle the performance impact. Gonna have to stick to the old tools for now 
1 Like
What would be the process of making this dragger work in a live game? So far I’ve ripped the MoveDragger, RotateDragger, ScaleDragger, and SelectDragger from the BuiltInPlugins folder but it’s kind of overwhelming
2 Likes
It’s both easy, and not trivial.
The framework is exposed as a Roact component which takes in a mouse property. So you could simply make a tool which mounts the Roact component with a tool mouse rather than the plugin mouse which it is currently mounted with.
The main issue you will run into is that the all the settings such as Grid Size, Snap to grid, Collision, Join Surface etc… are on the StudioService, which doesn’t exist in a live game. You will have to replace all of that usage either with stubs, or functions which connect to some ingame UI you make to set those options.
Another note is that you cannot get the IK dragging functionality of these tools in a live game (ie. you’ll have to hardcode the “Constraints” toggle to false). I am going to be exposing the WorldRoot::IKMoveTo function to community plugins next week, which is the last private API which the Lua Draggers currently use, however that API will still be restricted to plugins only, since the engine’s IK solver is not designed to interact with the physics of a running game.
Once the feature is more stable I will look at publishing an example of using the framework in a live game, and possibly refactoring the code a bit to make it easier.
12 Likes
This is all really good news. Building games will benefit from this very much, on top of the studio version <3
Which part of the dragger uses the IK dragging/constraints? I’m not super familiar with that
3 Likes
This is actually a fantastic improvement i always found the build tools lacking and very frustrating to use which is why i primarily just program and loath building or rush through a build. Good work on this one cant wait till its all debugged and out of beta. 
3 Likes
All of them! If you toggle the “Constraints” button then the draggers will use IK dragging, where they respect constraints, joints, and (if you have “Collisions” enabled too) collisions with other parts in the Workspace.
3 Likes
Ohh, I forgot about that cuz I don’t use it (it’s cool but I just build simple stuff and not physics constraints stuff/etc)
2 Likes
Quick poll, which behavior would you prefer, with:
Should the minimum size be:
Or should it still let you resize it all the way down to 0.05 studs:
Keeping in mind that within one resize action if you resized down from 4 studs to 0.05 studs, and then back up to 4, you would resize up to 4, not 4.05.
- Resize down to min part size (0.05)
- Resize down to grid size
0 voters
3 Likes
This is a great change, it honestly will help a lot with building. But I have found a few bugs and issues. I understand this is a Beta feature so bugs are expected. (sorry if some stuff was a bit confusing I tried to be as transparent as possible) 
Scaling
First of all, Scaling has an issue with following the snap to grid move value. So for example, if I have the snap to grid move value set to 1 and try and scale a part down, what ends up happening is when I scale down the Z-axis for example beyond 1 stud is it goes down to 0.1. Compared to the old system when you try and scale down beyond 1 stud with a snap to grid move value of 1 it wouldn’t let you. The new system has a bug where it keeps going down to the smallest limit which is 0.05.
Here is a video demonstrating the issue. Please look at the scale of the part as I resize it. (sorry if it’s low quality)
If you were able to notice I started with a default part size of (4,1,2) and resized the X and Z axes. I was able to resize the part beyond 1 stud on the X and Z axes. I let go of my mouse when I had resized the Z-axis to 6 studs and then had proceeded to resize the part down. Then strangely when I tried to resize the Z-axis beyond 1 stud it went to 0.3 instead of 0.1 as it did previously. Near the end, I had resized the Z-axis to the lowest limit of 0.05 studs and when I resized the Z-axis to its previous scale of 2 it had added on an extra 0.05 at the end. So now the part has a scale of (4,1,2.05) after I had resized it. This issue if affected on all axes and is not just limited to the X and Z.
Scaling + Rotation
There is also another bug with scaling a part that has been rotated. But this might involve being locked into the global movement rather than local. When you rotate a part and try to resize it, the part is resized locally rather than globally.
I feel showing the video will explain it much better than with words. Follow which axis I grab and how it scales. (again sorry for the low quality)
As you may have noticed when you rotate a part and try and rescale it, it rescales the wrong axes. When you click down it flips all of the axes according to how much you have rotated the part. I tested it again but rotating it about 45 degrees and this is what makes me believe it has to do something with a bug in the global and local movement.
Collision/Intersection
This isn’t a bug but I wanted to say something about how the collision works with the new system. Currently, there is no way of turning this off but it will be really nice if there was a way. Similar to how there is a collision feature with dragging and resizing in the old system.
It would be nice to have a new “Intersection Collision” button which will disable or enable the ability to have parts intersect while dragging against other parts. Having a separate button will allow us to still be able to scale, move, and rotate parts though each other when using the Tools but allow us to turn Collision on for when we are dragging a part without disrupting the other collision. (I’m sorry if this was confusing but I’m not sure on how to explain this)
In conclusion, other than those few issues this feature is amazing and will save a lot of time! I’m really glad that Roblox is patching up and improving Roblox Studio!
5 Likes
This was really helpful. I really got annoyed when dragging models inside buildings made then appear on top of the building. This is really useful for everyone.
2 Likes
I literally just asked a question about that as you were making your post (right above it). In fact, scaling down to 0.05 was actually a feature. Scaling back up to 2.05 is a bug though, which I’m fixing. Would you have an issue with the feature if it correctly scaled back up to a multiple of the grid size like 2.00?
A already made a fix for this this morning (though it will have to make its way down the release pipe still). The issue is local / global space, it should always be forcing local space positioning for the handles when you have a single part selected. As a workaround you can make sure you’re in local space mode (Toggle with Ctrl + L) when using resize right now.
3 Likes
It would be nice if you could highlight a use case for having collisions on. I’ve been unable to find any convincing use case that can’t be covered just as effectively by the non-colliding drag once you know how to use it, which is why I did not include a way to toggle to the old behavior (Understanding all the combinations of the current three toggles is already a significant hurdle for new users as is, we would like to avoid adding any more).
4 Likes
This is just insane! Thank you very much for this update. This is what we needed!
2 Likes
Ah thanks for the quick response! It’s great to know that you are already addressing these issues. I didn’t see the post you made earlier, so that was my mistake. I appreciate that the Roblox staff team is so proactive in our community. Again, thank you!
2 Likes
Thank you for this update! This is a much needed change, I’ve avoided dragging parts and models on so many occasions and instead resorted to positioning them through setting their position and rotation or CFrame manually or using the move and rotate tools. It’s nice that everything is much more predictable and even better that it’s all available for us to use in our own games!
One thing I consider to possibly not be predictable is:
This current behavior means that rotating and tilting are both dependant on different things. Rotating behaves according to you part you’re dragging across and tilting behaves according to the camera.
Would it not be better for tilting to also behave according to the part you’re dragging across (like rotation) but tilt away from the surface of that part?
Secondly, I have found a (very trivial) bug that I’d like to point out: if you delete a part with your mouse hovering hovering over it, the selection box does not disappear until you move your mouse.
This does not occur when the Lua dragger is disabled.
4 Likes
The API for the existing handles is unworkable: If you use it you actually have to introduce a lot more floating point error than you otherwise would with an optimal solution. So, if we wanted to use the existing Handles we would have had to add a new object with a different API for them anyways, and at that point we decided to just make them in Lua like everything else for greater flexibility.
We understand that the specifics like thickness / opacity on them aren’t perfect yet, and that’s actively being worked on. However, you can see some of the great benefits of the handles being coded in Lua if you try hovering the scale handles in cases where two of the scale handles are overlapping, it much more reliably guesses the “correct” handle which you were intending to grab now. This would not have been possible if the handles were implemented as a C++ object, because the behavior now relies on having very specific details about what the handles are being used for.
6 Likes
Once you think it through, that would not be consistent. When you look at a part, you know immediately what the direction “up” away from the surface is. You don’t know what the “secondary” direction you’re talking about of the surface is. Even if it has a studded surface, you still don’t know which of the two stud directions would be tilted around.
Using the camera horizontal direction and the surface normal has two important characteristics:
-
They are both readily known pieces of information in any situation just by looking at the screen
-
They are both usually different directions, since you don’t tent to look at objects at a very oblique angle. So you will rarely end up “gimbal locked” where both tilt and rotate mean the same thing.
Furthermore, that’s just the meaning that the words have: “Tilt” typically means an operation relative to you, the observer, vs “Rotate” is more likely to mean an operation relative to the object being rotated (ie, rotate a wheel or a screwdriver).
5 Likes