There’s this incredibly useful feature with the old draggers where you could select something, then paste (Ctrl+V) and the pasted item would be aligned to the thing you just selected. Incredibly useful for so many things without needing the use of command bar or primary parts or any of that.
With the Lua dragger it just pastes aligned with whatever was copied / cut, which is incredibly frustrating, and it doesn’t even move the camera to the new part so it’s not always obvious where it’s pasted it.
Video example using Cut and Paste
Old dragger:
Lua dragger beta:
As you can probably imagine, the old behaviour has a lot of use cases.
If you could bring back the functionality to paste aligned to the bounding box of the selected Part / Model, or even better make it an option that can be toggled on/off, it would make life so much easier with the new dragger. Sadly I’ve had to switch back to the old dragger due to this.
Separate issue, when moving the camera and dragging at the same time, occasionally the output gets spammed with: Failed to solve for movement amount! Wanted: 0.88089123959626 Got: 0.82009346916914
(rbxopenscript://www.dummy.com/dummy?scriptGuid=&gst=6#290)
We’re looking at changes to the selection is displayed too, however that is an entirely separate feature from the draggers themselves. As a workaround, you can develop your model at a larger size, and then scale the whole thing down to the size you want to use it at.
We did not intend to change this behavior, I just didn’t notice that it broke. I assumed it part of studio’s core copy-paste logic, but checking it out, it turns out that it is actually part of the dragger code.
Thanks for the report, this will be fixed. Do you have any requests for how this should work? With the new code I could make it do something like automatically snap the part’s rotation as well as the position.
I think rotation as well as position would be very helpful.
Collisions might be worth thinking about too. Currently, the old dragger pastes the part on top avoiding collisions regardless of the Collisions setting. The new one could potentially honour the setting? Although I can see how it could get confusing if the pasted item ends up inside the object and ends up hidden.
I’d be happy with it matching the old behaviour, but those two extra features could make it even more useful.
Unfortunately I don’t think I can do that because it would be way too confusing for new users having the part hidden inside the selection. Duplicate (Ctrl + D) already covers some of that use case.
I’ve played around a bit more and I remembered why this is important. Sometime i move stuff with the select or move tool while testing in game. I have to be able to Unselect the select tool when testing so I can click stuff in game (shoot a gun) and not select parts
First batch of fixes is now live. Full list of things which have been fixed:
Scale tool always scales in the correct face.
If you delete the part you’re hovering over, the hover box will now disappear immediately.
If you’re attempting to scale a part which is at the minimum size on one axis it will now work correcty.
You can now use the move / rotate / scale parts outside of the workspace, including those in ViewportFrames. Doing this for parts in ViewportFrames will still feel a bit weird as the handles won’t show up in the ViewportFrame, but it will work.
Moving attachments by editing their properties in the Properties pane will no longer leave the handles in the wrong place.
Switching tools with the mouse held down no longer breaks the draggers.
You can now deselect the Select tool (deselecting a different tool will still cause the Select tool to become selected)
The draggers now use the same bounding box orientation logic as Models, so you won’t get scenarios where the model drags differently than its bounding box would suggest it will.
VectorForce and other constraints that only have one Attachment will no longer break the draggers.
The option to switch between local and global space should show up in the right click context menu again with the draggers selected.
Many more fixes are still on the way. If you’ve raised an issue here and I haven’t explicitly said we aren’t changing it, then a fix is either on the way or planned before release.
This particular error (the BoundsChangedTracker one) has happened SO MANY TIMES for so many different reasons that I just don’t know what kind of code you guys are running here. Aaaa. It happens while I’m dragging things from the Toolbox, it happens while I’m changing the Size property of hundreds of parts, etc.
I really think these are cool toys, but they just feel like toys to me and the new arrows and rotate handles don’t help. There’s also the presence of so many fatal errors that can cause them to stop functioning.
I’m only in the beta so I can report all of these blaring issues to hopefully get them fixed so other people don’t have to deal with these problems :’<
My select tool has completely broken and it can no longer be selected, how ironic. Fortunately that means it’s one less keypress for me to become toolless, but becoming toolless randomly actually is a bad user experience, considering how buggy and crashy the other tools are.
This is surprisingly hard to click on actually, I would appreciate a setting to change the scale just like you have with the constraint visualizations. (but not combined into the same setting)
It’s a symptom, not a problem. Installing the BoundsChangedTracker is the first thing it does during one of the state transitions, so if something broke earlier on and it failed to uninstall it then you’ll get that error. Though I agree, there must be something I can do to refactoring wise to reduce the likelihood of that class of error, I’m going to look at that.
Part of the difficulty of getting these tools stable is that they’re such a multiplicative problem: 4 Tools x 8 tool modes (collisions x constraints x joints) x 3 studio modes (studio, run, play solo) x A million little special case behaviors like being able to click an object a second time to select a decal on that object. Don’t worry, we’ve planned for a long beta to work out all of these issues and make sure that the tools reach a very stable state before they go out.
What in particular don’t you like about them? Just the choice of scaling behavior? Or way they look visually?
Well, there’s scaling, but there’s also subtle things, like the fact that they’re missing shading and they don’t have any of those little dots that they used to. (the tiny squares that were always visible even if the handles were hidden. I could always find the right place to click back then!)
And the rotate tool is just a nightmare for me.
It is SO not easy to accurately click on those arcs, which ends up selecting something else.
I also feel like the other handles have shrunken hitboxes as well…
Most of these just have pathetically small handles compared to what I’m used to. I’m good at moving my cursor, but having to contemplate for even a second longer whether or not my mouse is correctly positioned over the darn handle is extremely annoying!
It’s impossible to undo losing your selection, by the way.
The original hitboxes were very insanely large compared to anything other programs have: IIRC it was a 5x as large hitbox compared to the visual on the Move handles. It’s likely we swung the pendulum too far in the other direction now and made them too small.
I wanted to see what people said first, and the answer is pretty clear that we made the hitboxes too small.
That’s probably what happened. I’m all for the nice petite look, and the sharp lines of the rotate tool… if you wanted to make a visualization. If you want to actually USE these and manipulate things in 3D space, it’s a nightmare!
I need thicker rotate arcs and larger handles in general. Probably even some textbox somewhere to scale them like what we have with constraints. (Funny thing is, I scale constraints to be as small as possible - but small move tools are a nono!)
This is a really impressive and unique new feature for Studio. Especially for people like me with a potato PC. This is a huge improvement to my system, and the way I drag. Thank you so much.
It is, I have had this issue recently using them. My fix apart from restarting studio is to click somewhere on the asset manager each time you want it to go away, but I guess that’s a bit annoying to do each time
Want what to go away? I was referring to the explorer changing spacing when you hovered something, but then reverting back when you moved your cursor to empty space.
