Say Hello to the New Lua Draggers

By the way, if anyone has received an “Out of Memory” error while using the Lua Draggers I would be very interested to know what you were doing. I’ve seen these errors occasionally in the analytics but never been able to reproduce them.

1 Like

I think I found another bug. After selecting both a Model and a MeshPart, it screwed up the positioning when I moved them. See video below:

As seen in the video, I can move each object separately without any issues, but moving both of them screws it up.

This is a legitimate bug, good find. It looks like it happens when:

  • Your selection contains anchored models and un-anchored individual parts.
  • One of the unanchored parts is welded to one of the anchored models.
  • You try to move the selection.

Unfortunately, for now I think this is a rare enough set of circumstances that we won’t be reverting the rollout for it.

I actually already fixed this bug incidentally, however the changes that that fix are part of won’t be coming out until the 23rd.

There are several reasonable workarounds until the fix comes out:

  • Anchor the part. This is only a problem if the part is unanchored but the model is.
  • Temporarily group the two objects together. You won’t ever run into the issue dragging a single model.
  • Group the single part into a model (which consists of only that part), since the issue only manifests when working with a selection which is a mix of both models and individual parts.
1 Like

So far so good! Only noticed some minor things so far!
Small Bugs

  • Pressing R when dragging along a wall rotates different than pressing r when dragging on the ground
  • Pressing the Select tool while activated will activate a weird mode that I can’t find a use for. You can’t select anything, and previously I believe it just kept the select mode enabled (please correct me if I’m wrong). As someone who constantly uses the hotkey control 1 to quickly go to select mode out of habit, sometimes when it’s activated, it will de-activate and I’ll have to activate it again. Again, not major feels oddly different.
  • I’m unable to use control r while mid-drag to rotate an item, rather I’m forced to use JUST the r key. This is slightly different from the previous version. You can see where I press r alone and the model rotates, as opposed to when I press control r.

Amazing work and I’m so excited to work with these epic re-imagined tools!

1 Like

This is intentional, now R will always rotate around the normal of the surface that you’re dragging on.

The intent here is to make +Y no longer be a “privileged” direction: Now if you’re trying to build inside of a spaceship or something oriented at an arbitrary angle, the building tools will still work just as well in that rotated reference frame as they do on an unrotated baseplate.

It’s the mode where you have no tool selected at all! In editing mode it isn’t super useful (though some people do like to use it to look around their place without selection boxes popping up), but being able to go back to having no tool selected is quite useful in Run / Play mode.

I could look into a setting for this when we do a pass adding more dragger settings but you’ll have to be more careful with the hotkey for now.

I’m unable to use control r while mid-drag to rotate an item

I didn’t know about this behavior, but I can see why it worked. The fact that it worked before was more of a coincidence of how the legacy draggers were implemented rather than intentional behavior.

Before using R while dragging was rather unpredictable, hopefully I’ve made the new rotate-while-dragging behavior better enough that it mostly removes the need to use the Ctrl+R shortcut.

Unfortunately I don’t have an easy way to fix this (since the Plugin API lacks a way to temporarily handle a shortcut). If I get enough feedback about it I can look into fixing it anyways but you’ll likely have to learn to not press Ctrl in that scenario.

1 Like

can i opt out for the new lua draggers and get the classic c++ draggers back as that is what i prefer to use more than the lua ones and are much less buggy imo

Please raise the issues here if you are experiencing bugs so we can fix them.

when i select multiple parts to move, it gets quite laggy when moving them and using a plugin like F3X, for example, it’s near flawless, shown below: (lua) (f3x)
I do still want to opt out of the lua draggers

I’m also having problems with lua draggers. When clicking on one part -without even dragging it- it moved to an area near the middle of my screen (was on far right).

Then a feature that I used quite often,clicking on two instances and having the latter be the one the explorer focuses on so I could put the first instance inside the second one is now gone, or doesnt work properly and will just focus on the first instance in the explorer. Plus, while not a big deal, I really liked how the old cursor worked and how it didn’t turn into the regular pointer when I deselect parts. If I could seriously opt out of it or if there could be an option to go back (even if it doesn’t get “updated” anymore) I would still go back.

Also when trying to gettings gifs for this, this started happening:
It started to like, keep trying to click back on a part im pretty sure i deselected when clicking on the baseplate

This is because you have Join Surfaces turned on, so the Lua Dragger are doing the extra work to find, display, and create surface joints. If you turn off Join Surfaces, the Lua Dragger should have better performance than F3X.

Did this happen the last time that you tried them or recently? We fixed a problem which would have caused that kind of problem before for this most recent rollout.

Could you explain this problem in more detail?

Explain this also? As far as I can tell the cursor behavior is the same except that the Open/Closed hand cursor is the for the draggers is the system default one now rather than an old Roblox specific one.

I can’t really put my finger on it but If I’d have to say overall something just feels off when using the new lua-draggers still making me prefer the older Tools over the newer ones.

Don’t get me wrong. I think theres places where the new tool excells Like where the rotate tool shows you how far you’ve rotated that said brick But stuff like how the “arrows” (I guess i’ll call them) Are dynamic with the camera. I’d with there was a static type of option for it.
or even then possibly a option to toggle between the two versions of tools even if one seems to be inferior to the other.

On a final note I love the new change for when dragging something and pressing R Rotates it around the cursor rather than just the middle.

other than that I just wish as someone who’s very familiar to the older tools can still use them with the ability to toggle between the two tools.

1 Like

The problem where clicking on parts to drag them into the other model might’ve been a bug that was just “for” last night, because it was just happening last night, if it is still happening I cant even try it because of the problem where it just moves to the middle of the screen when i just select it.
These could all be related because it appears the cursor is just trying to “go” towards one side of my screen. For the other examples I edited the last post to put them in.
essentially the problem is somewhat just visual and when i deselect a part that i have selected it switches back to the original pointer and then back to the hand.

Unfortunately you’ll have to get used to this. This is how the overwhelming majority of 3D editing tools do things and it’s how we’re going to do things also going forwards with handles. There’s other improvements to the tools which we want to make which don’t work well with the handles being a constant size in the world like they were before.

Oh, I see what you mean, while the mouse is down after Ctrl+Click to deselect something it shows the arrow. I will fix this, thanks for the details.

but can i still opt out please?

If you can demonstrate that your development workflow is significantly impacted and we don’t have a good workaround for you to use we can still manually opt you out, but otherwise we’re moving forwards with the release.

The explorer behavior started up again where it wouldnt go to the last selected object and just stay on the first one selected
the behavior Im getting is when clicking on the house and then a tree, but the behavior expected (and that happened before) is when I clicked on the tree and then the house.
the behavior also isn’t just in that game or just with that model. I don’t know if this is supposed to happen or not but it is hindering how I group things together

Thats understandable.
It’s just something that bothered me a lot when working on a widescreen monitor.
Do you think there will end up being more customization with how the tools look and interact overall? or is what we see what we end up getting?

Two things:

  • Part of the reluctance to add options is that there’s no good mechanism to provide options right now. Settings we add to the Studio settings dialogue are technically part of Roblox’s public API, since you can get them via plugin, so we have to be careful about what we add there, as we need to support it.

  • One of the goals of the LuaDraggers is to be forkable. You can technically fork the Lua Draggers right now as your own user plugin and edit it however you want, there’s only a few things that you will have to strip out of the code for them to run as user plugins (mostly fast flags). We aren’t really advertizing this yet as there’s still a couple of APIs we have to open up (there’s no way for a user plugin to set the “insert point” that stuff gets inserted / created at by studio) for you to get a fully featured Lua Dragger as a user plugin.

1 Like

I checked it out, and, yes it is a distinct bug. It happens any time you select multiple objects, only the farthest one down in the explorer window will be focused rather than the most recently selected one (so selecting a single object will always work). Sorry I did not notice this before as I keep stuff grouped together enough in my test places that I don’t scroll the Explorer window much.

I have an easy path to fixing this, and can have a fix for it out on the 23rd. In the meantime, this may be a good opportunity to experiment with using folders for organization: If you haven’t tried it out before, grouping things into folders still lets you select and drag those objects individually but keeps your explorer window much smaller and more manageable.

1 Like

I’ve noticed you’ve brought back the L indicator from the old draggers when using local space.

The outline looks very ugly on Mac (my screen res is 5120x2880) since it is thicker on one side. Don’t think this needs a feature request but could you remove it? The one on the old dragger was fine.