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