We will take a look at this. Do you happen to have a sample place you could send us with steps to reproduce it?
Could you let us know why it was harder for you to use? Out of curiosity, do you know that you can now grab and drag anywhere on the rotate rings to move them? You don’t have to just grab the intersection area where the orbs were?
Thanks for the feedback and note about the shading! As I’ve said in other posts, we have plans to continuously build on and improve these draggers, and we’ll take that into account.
Awesome. Do note though that the most useful aspect of the handle shading was that it helped me notice which handle was in front or behind. I also just remembered that IIRC, the old handles were also fully occluded by parts, which is also contributing to difficulty in seeing which handle is in the foreground. Currently I don’t think the transparency effect on occluded handles is obvious enough, it might be worth experimenting with e.g. making it more transparent, desaturating the color of the occluded handle, or particularly highlighting a smaller specific part of the handle through parts (for example, I think the old draggers had little squares that would show through parts).
Also I should mention since other people are complaining so much that the automatic resizing of the handles does not get in my way, and makes the tools easier to use.
I don’t really have a valid reason except that I practiced and built my experience building on Roblox Studio with those orbs, and it will take awhile to adjust to these new tools. I also strongly miss the little squares on the occluded handles and the invisible handles when through a block, as @PeZsmistic mentioned. They greatly contributed to my understanding of where the part was in the Workspace (is that what depth is?)
Not sure if this is related to the new draggers, but the studio selection tools within the 3D viewport don’t work if the parts you’re selecting are configured to not collide with the Default collision group.
More info here: Studio Selection doesn't work if CollisionGroup doesn't collide with Default group
We’ll look into it. Thanks for the bug report.
1 Like
I recognise that this is largely a nitpick, but since the new Studio cursor is a little larger, it can block some small parts if you’re far away enough.
We should be able to resize the cursor, or opt out to use the old cursor.
3 Likes
I believe you can set this at the OS level. The new draggers use the system default hand cursor.
1 Like
My cursor is as small as it can get, so I can’t really do anything about it
how can i access the framework for this to use in my own tools?
I found it on my Windows machine at
%localappdata%\Roblox\Versions\version-CURRENT STUDIO VERSION\BuiltInStandalonePlugins
Putting %localappdata%\Roblox\Versions\version alone in your Start menu alone should find you a version with it.
I noticed that previous C++ draggers had an interesting feature: when you double-clicked on a certain part of a model, it would select that part instead of the whole model. Will that feature return? It was so cool and handy.
You can hold down ALT to select parts, without selecting the model that the parts are parented to.
3 Likes
Would you mind putting these in folders?
As a plugin developer, I also put visuals in CoreGui, so navigating CoreGui is annoying while also using the new draggers.
1 Like
Could we please get an update for this that allows us to move by smaller increments? A lot of models that used to be easy to work with have required me to use an older version of studio to move these parts at a small enough increment to get the desired result.
If there is a workaround for this, or an option to change the absolute minimum increment, I haven’t noticed.
Physical Draggers work at the same increments geometric ones do. Have you tried to change it from where you’d normally change your increments?
1 Like
The recommended workflow for making small models like this is working on them at a larger scale, and then scaling them down to get the final model. The engine is not designed to work well on very small parts (<0.1 studs in size), so an even smaller increment would only help so much.
The new tools should be able to do everything the old ones can though. If you believe there’s something that they can’t do, please share exact repro steps and we can fix it.
1 Like
What I meant by this is that whenever I try to move parts with these new tools, the part always sort of “jumps” compared to the older draggers. For example, let’s say I have two human characters, and I’m trying to move the clothes from one to the other since I updated one of them. If I try moving the clothes with the new dragger, I can’t get them into the exact spot I need them to be. It’s always slightly too far left, or too far right. However, with the old draggers, I’d be able to move them to the correct spot so that it aligns correctly.
While you could say I could scale up the models, move the pieces into position at that scale, and then downscale them, the problem would then be that I’d have to be able to scale them back down to the exact same size they were before, which is a bit of an issue when you’re dealing with unions that can only get so small without plugins. It’s also really unhelpful if there’s multiple parts that need to be scaled precisely to-scale with each other. A lot of unions I have use holes to house other parts without clipping into each other, and also so that they can be colored individually.
I’ve attached an example of what I’m talking about below. It’s really small, but if you watch the selection box, you should be able to see what I’m talking about.
If there’s a way to change this at all, I’m not sure what it is.
Have you tried to change it from where you’d normally change your increments?
I have indeed, but it doesn’t affect it. I typically leave my increment at 0 for small movements and 0.25 or 0.05 for larger, to keep things symmetrical.
(I apologize, I don’t know how to quote Krunnie’s post fully in the reply feature, despite checking the forum guide.)
1 Like
Could you DM me an example model?
EDIT: It turns out there is a behavior difference in the case where Use Local Space = true. The minimum grid snap increment even when grid snapping is disabled will be removed, sorry for not spotting this behavior difference.
2 Likes