Please read:
That would be doable for now, but would be unsustainable in the long run. If we supported both then when we add new features that need dragger support we would need to design and implement two completely different copies of that support. That would make it really hard to add new features, and the draggers wouldnât get as much support as they deserve.
The Lua draggers also are a step towards letting developers choose, as they let us move towards plugin developers publishing draggers as plugins which replace the core movement tools with whatever game developers want. Granted, this isnât possible just yet.
2 Likes
New draggers look promising. Thanks for tackling this!
Some observations and opinions:
1. Move Handles
Whatâs working:
This one is pretty close to where Iâd personally like to see it. If you place a box part in the scene and change itâs size to a 0.1X cube, moving in on the cube with the mouse wheel (after pressing F) causes the handles to scale in a way that keeps them in frame even when zoomed way in. It feels just a hair tight at the closest zoom, but itâs an improvement over the old system where some handles could go offscreen when in very close.
Once you start scaling your cube to 2X or 1000X, this nice feature of being able to see all the handles doesnât hold completely; although, itâs still an improvement over the old system and the handles are accessible easy enough by turning the camera view. Ideally, one would be able to press F and move in with the mouse wheel and still see enough handle on each side to get ahold of it, but how it is now is not bad.
Whatâs not working so well:
Functionally, I donât have much to complain about with these ones. Visually, there are two points that Iâd pick at. First, I donât like dropping the arrow heads completely from the axes that arenât selected (Making them thinner is great), and I question doing that at any rate for the opposite directly to the one youâve selected. If you grab an X handle to move in a positive direction, a slight change to how you move your mouse will send it moving in the negative direction. Why would all the X handles not be highlighted? Are you wanting to show which handle was grabbed or which axis the movement is locked along? Second, I miss feeling that the handles are inside the world. They may have been before and are now on a gui layer of sorts, but if thereâs any way to desaturate (or something) handles that are visually behind a 3D object that would really make them look great. Minor stuff on the whole.
2. Rotation Handles
Whatâs working:
The style of the circle grabbers is reminiscent of the old version. It can be easier to find a place to grab the new ones since you donât have to locate a dot, and the dial of increments youâve added in the center is a useful touch. Unlike the move handles, the rotation handles are within reach at any zoom level (until they vanish when very close).
Whatâs not working so well:
Compared to the arrows used for moving, the circles take up a lot of real estate, visually. Using the same line thickness may give some style consistency, but it is maybe too much for this design. Probably due to that feeling of these handles taking up a lot of space, the whole dragger seems a bit cramped. The circles should make it easier to grab a rotation handle, but grabbing a particular circle isnât as immediate as it could be when the handles are overlapping in such a close space. The old version allowed the camera to move inside the dragger circles. That worked pretty well. It just needed the ability to grab anywhere on the circles so you could remove the dots. If itâs not possible to go inside the circles, perhaps consider having bigger circles (rel to screen size) and thinner lines before an axis is selected. Once an axis has been selected, the way you have it with everything else disappearing works great, imo.
Finally, the behavior doesnât feel consistent with the mover handles. The rotation handles are a static size on the screen while the mover handles appear to zoom in and out a bit in concert with the camera in the scene. Obviously, this is the reason we arenât losing rotation handles when zoomed in close, but itâs inconsistent and doesnât feel as natural as whatâs happening with the mover handles. Some zoom feels great, and locking to min/max sizes so handles donât get lost while zooming in the scene is good. Maybe letting the size of this dragger float a bit with the size of the model itâs attached to (similar to the mover handles) would also help mitigate the cramped feeling.
3. Zoom Handles
These feel pretty similar to the move handles, but without most of the downside points I raised. Nothing to add.
Other Thoughts/Observations
- The camera seems to change orientation sometimes when zooming into a part. For example, Iâll wheel in on an object and the camera will rotate to align itself with the top of the baseplate. Is that a setting? I havenât been able to reproduce it reliably.
- Is it possible, within all these changes, to choose a pivot point for rotations in Studio? Allowing an option to use the center of the first selected object in a group to rotate around would be plenty.
- Another great feature would be to lock the minimum amount the mouse has to move when using small snap increments. Is it necessary to use such small mouse movements in order to work with snap increments like 0.01. Donât know if thatâs controllable at the dragger level.
Thanks for all your efforts!
3 Likes
First, thanks for the very detailed feedback, much appreciated.
Basically what you want is for it to work like it does in other programs, where the Move handles are anchored to the center of the selection, rather than its outer edges? The reason I did not change the handles to behave that way is that many builders like to do micro-adjustments of part position by zooming in really close on one end of a long part and dragging the handle out at that end to get it lined up with something. I couldnât think of a good way to support this while having the handles be at the center.
Could you elaborate on why you want this? What I wanted to accomplish with the thinning of all the other handles was to show you clearly which handle you clicked on. You already know that youâre moving along X by seeing one of the X handles prominently, what would highlighting the other one as well show you?
Unfortunately I canât do anything about that since having the handles feel like theyâre in the world, although âneatâ, directly conflicts with usability.
The handles actually already do this, itâs just not very prominent, since with a greater dim it becomes hard to see the handles when theyâre occluded. Note the dim on the red handle as it passes under the baseplate:
They actually do have the exact same scaling logic. Itâs just that the Move / Scale handles are anchored to the edges of the selection vs the Rotate handles are anchored to the center. I could do it differently for rotate since micro-adjusting rotation by zooming in on the extent of a long thin part isnât a similarly common use case.
Try insert NumberValues called âRotateHandleRadiusâ and âRotateHandleThicknessâ under the workspace. They will act as debug multipliers on the rotate handle sizing. Iâm interested to know what your prefered values are.
Long standing camera bug, has nothing to do with the draggers. There is a ticket for it which weâll get to eventually.
Itâs actually being worked on right now! Though thereâs still a lot of open questions on how best to do this and have it tie in with rotation behavior ingame / in the scripting API etc. but also not break any existing code, so I canât promise a timeline.
Elaborate? Iâm not sure I understand what youâre asking for but it sounds like something we could change.
Yeah, I do that too. If itâs one or the other Iâd vote to keep it how you have it. The case I had in mind was a recent build where I had a large object that was misaligned with a smaller one and I needed to move the large one left-right on the screen while zoomed in on the smaller (near center of larger). It just stood out at the time that I couldnât see any move handles near my viewpoint. Having a through line (like a linear version of the continuous rotate handle) that popped up when both handles were offscreen, or a keyboard hotkey that could be used to nudge things in those cases are the only potential solutions that come to mind (There may already be a hotkey. I havenât looked). Probably not enough of a general worry to bother with. Itâs usually no trouble to look around for a handle.
My comment on this sounded more critical than I meant. Iâll explain the observation through comparison with the other draggers. With the scale tool, if the positive z dot is dragged, for example, the negative z dot does not move. That side of the object stays put (unless some ctrl keys are being pressed). It feels right that the negative dot in that case would not highlight because there is nothing happening to that side of the object, whichever way I drag the selected dot. With the rotate handles, the entire handle is highlighted. It doesnât distinguish between rotating one way or the other. There is no rotate left version of highlighting. To me, the move action feels closer to the rotate action in that there are no deformations happening where one side might not move and the changes the selection is experiencing could be mapped along a continuum in some respect. Connecting the meaning of the highlight to the possibilities allowed by the constraint (rather than to the handle being grabbed) allows for things like highlighting handles on both sides of a cube when scaling from centerâor all 6 if scaling in all directions. The specific handle being grabbed in those cases isnât the most important information to communicate. This isnât something that will affect my ability to build things, but it struck me at one point that the direction I was dragging wasnât being highlighted because I had grabbed the other handle. Itâs easy to acclimate, but I thought Iâd bring it up.
Oh yeah! Okay, I just missed it. I guess it wasnât registering as strongly as the change in the old version where the occluded part basically vanishes (except for a small dot). Great!
Ah! That makes sense. Not knowing the details, it appeared that the rotate dragger was sitting stationary while the world zoomed in and out behind it (not a particularly pleasant sensation). Having the move/scale handles attached to the extents of the object rather than the center might also be contributing to the less cramped feeling those draggers have. When you zoom in and the handles move out a bit, it feels like you are moving in on the object. When the handles stay the same it feels for a minute like you are stuffing a too large item in a too small container as the rings close in around the item. I canât visualize precisely how a different zoom for the rotate handles would work best. I imagine it would fake some of the best parts of how the move handles work without ever going off screen or getting too tiny. It would probably be worth taking a shot at it since a number of previous posts about that dragger feeling âoffâ might be helped with that kind of thing.
Oh right, itâs customizable! Well, nm then 
.
Iâd set the thickness adjustment to at most a constant 0.8 (since the other handles stay constant as well. The thinking there is that the scale handles look like they could be round versions of the move handles (they appear to have similar volumes). Extending that idea to the rotation handles, we could instead stretch the volume to get a long loop, which would necessarily be a smaller thickness than what the mover is using (adjusted to taste). In my opinion, the handles would get no smaller than a radius adjustment of 0.8 for an object that is very small on the screen and no larger than 3 for something in-your-face (screen-sided or larger). Thatâs on my monitor anyway. It clips outside the frame a little at 3, but I donât mind it. It probably wouldnât hurt to be more aggressive with the dimmer effect where the rings are occluded when itâs large. I assume there would always be one side of each ring on the front of the object to grab. The back edge of the rings are adding to the visual spaghetti sensation as much as anything (but it wouldnât hurt if they were still active). I donât think the dimmer effect from occlusion would be all that helpful when objects are very small on the screen. Making the dimmer effect stronger as the object gets closer might be a nice-to-have effect to add to the pile of things to look at.
Nice! I use a simple dummy object and snap it where I need it and then use snippets of CFrame code to move things relative to it. Trying to account for all the variations of rotating around points or edges or points on edges or surfaces, etc. could turn that into a nightmare implementation that never gets added. Iâd be happy with being able to select a dummy piece that Iâve snapped exactly where I want it and then be able to rotate other things Iâve selected around its center. Select the dummy pivot. Select everything else, Rotate. Done. Thatâs wonderful to hear itâs being looked into. Thanks!
Iâll often turn on collisions and turn off snapping to bump a part right up against another, but sometimes there will be additional geometry attached to one of the pieces that collides somewhere else and messes up this approach. In that case Iâll turn the snap back on (collide off) and move the pieces closer with very small snap increments (dragging with the mouse). Maybe there is already a setting to adjust this, but the control I have to exert with the mouse in order to keep from overshooting my snap point 2 or 3 times over is high. If there were a comfortable minimum amount that I could move the mouse in order to accommodate any valid snap size, Iâd view that as a plus. For increments smaller than about 0.1 (on my machine anyway), thereâs almost no point in using the snap because I end up just typing in values due to the 1-to-1 feedback being too much at that scale.
Thanks for the queries and for entertaining my opinions on these things!
Your efforts there are very much appreciated out here!
Basically, what you want is for the part to not always follow your mouse directly with Move/Rotate/Scale, but there to be an optional scaling factor? (so for instance, the part only moves 1/10 as far as your mouse does)
Automatically adding a scaling factor like that when you have grid snapping set to a very small value is actually a really good idea. Iâll try implementing something like that and see if it feels good enough to ship.
1 Like
A scaling factor would definitely help extend the useful range of numbers that can be input as a snap increment. It stands to reason that if a number can be entered as a snap-to value, then it should be possible to snap with it. The problem with that in practice is with how fine grained the mouse movements need to become at the very low end. Scaling is one solution. However, the movement in the 3D world would still be proportional to the mouse movement, so there may still be a danger of bottoming out the effective range before the actual bottom of the range is reached. Having a hard limit thatâs tied to a reasonable expectation of what a mouse can register in terms of precision might be another thing to investigate. I donât know what that limit would be, but it could be used as a minimum. So, snapping to 0.05 increments could require a 5 pixel move with the mouse. Snapping to 0.0005 increments could also require a 5 pixel mouse move. Whatever the snap is set to becomes the unit length that corresponds to the 5 pixel mouse move, and thereâs no limit on how low the numbers can go. Either approach could work, and they could likely work in concert in some way.
The trade-off for either is that macro movements may be throttled in a way that isnât done currently if a user isnât aware that theyâve set a snap value that falls down in the high-precision zone. Maybe you were addressing that concern with the âoptional scaling factorâ comment. Seems it would have to be that way, or youâd get non stop complaints about the draggers being slow.
FYI the minimum grid snap is 0.01 unless you cheat and edit the settings file.
Seems it would have to be that way, or youâd get non stop complaints about the draggers being slow.
Part of using this solution would be checking the analytics to see whether too many people have their grid snap just hanging out at some small value. My guess is that itâs a reasonably low number and most people just keep their grid snap set to 1, which is why I think it might work out even without being optional.
1 Like
Minor feature request, donât think itâs worth making an entire thread for.
Would be nice to be able to type in the resize amount, like in blender when scaling. So when I resize and press 1.5, it will scale by 1.5 studs in whatever direction im resizing in
3 Likes
This is great however Iâve been facing one minor issue, when you stretch a part out then press crtl the part will spread out from itâs original position. This issue causes great annoyance when Iâm building things like windows or walls.
Also is the transform tool going to get an update any time soon?
2 Likes
Ye, update is great and all but Iâve also got into a problem. Whenever a part is grouped with a part or somekind, I canât double click that group part and get a specific part selected. If you get what I mean. With the old one, I could select any group parts by double clicking, with this new Dragger, I cannot.
Apologies if Iâve mistaken.
2 Likes
Hi there, Weâre looking at some options with the Transform tool. What are the key tasks you use it for/features you like about it? Thanks!
1 Like
This is so weird, youâre the second person who Iâve had mention this, but it doesnât work like that on my machine, and I also canât see any code in the old draggers which looks like it would allow that. Are you sure you didnât have some plugin installed which was adding that behavior?
At any rate, the supported way to do this with both the old and new draggers is to hold the Alt key while clicking. That will select the deepest object in the hierarchy rather than the toplevel model, and also works with box-selection, allowing you to box-select all the individual parts inside of models).
Do you mean how it scales centered from the starting point rather than the point where it was when you started holding the Ctrl key? This was a deliberate change to bring it in line with the way that modifier keys work in most other content editing programs.
Iâm not too worried about this because I think itâs mostly a muscle memory change: You just need to learn to release and re-click the handle when you want to remember the point that the resize is currently at. If you disagree and think that this significantly worsens some particular building workflow, we are still open to changing this, and would appreciate if you could take a video showing how you use it.
4 Likes
Thatâs a behavior of the CmdUtl plugin and several derivatives like qCmdUtl and SBS.
3 Likes
I used this beta for a few months now and I still enjoy it! I am also excited for the release! 
4 Likes
As you can see in this video it âSnapsâ around as I press crtl
1 Like
Yeah, thatâs intended. Itâs not glitching out: when you press Ctrl it now scales centered around where the part was when you started scaling rather than where it is when you press Ctrl.
What I mean is, what is the use case where you need to constantly switch between scaling centered and scaling not centered which makes the change in behavior awkward? As far as I can tell you should just be able to quickly release and re-click the handle if you want to set the starting point for the scale.
3 Likes
That is two extra clicks. Also Iâve never had a use for that funky crtl thing. The only time that that would be useful is you accidentally miss the ctrl button which is very rare for me.
1 Like
Oh, now I see the problem with this feature
1 Like
This will be an amazing update, this will totally change the way we work in Studio, Iâm also really excited about this!! 
2 Likes