First of all: Why Roblox has used before a C++ dragger?!
Studio and Player are programmed in C++ [and QT], itās just Roblox is migrating some things from internal C++ code to Lua.
??? Not understand, where?
(30 character limits)
To keep everything on-topic, Iāve moved this to PMs. Check your forum messages!
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.
Finally! I can drag pretty much everything without confusion! This really helps!
finally iāve waited for this feature for years
This would REALLY help me a lot for quick building. Thank you Roblox for this Awesome feature!
Shift-click on an empty space in Run mode. This error will be spammed every frame.
Select two parts connected by a rigid joint and rotate it while holding shift. May take a few tries.
Was doing some combination of anchoring a part, moving the camera and using the move arrow while zoomed out.
Also this:
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.
All of them are shrunken.
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.