Say hello to the new Lua dragger (Beta)

Yes, that would be an efficient way to solve the problem.

Managed to break the draggerā€™s rotate (R) key:

Open studio.
Place the Part on a basic part/baseplate (baseplate is sized as 500, 4, 500)
Select the Part by click on it directly
Click and drag to select both he Part and the baseplate it sits on
Press R to rotate:

Observe the following stack trace:

15:52:14.109 - Plugin_SelectDragger.rbxm.SelectDragger.Packages.DraggerFramework.Implementation.DraggerStates.DraggingParts:107: attempt to index nil with 'targetMatrix'
15:52:14.110 - Stack Begin
15:52:14.110 - Script 'Plugin_SelectDragger.rbxm.SelectDragger.Packages.DraggerFramework.Implementation.DraggerStates.DraggingParts', Line 107 - function _tiltRotateFreeformSelectionDrag
15:52:14.111 - Script 'Plugin_SelectDragger.rbxm.SelectDragger.Packages.DraggerFramework.Implementation.DraggerStates.DraggingParts', Line 96 - function processKeyDown
15:52:14.111 - Script 'Plugin_SelectDragger.rbxm.SelectDragger.Packages.DraggerFramework.DraggerTool', Line 301 - function _processKeyDown
15:52:14.112 - Script 'Plugin_SelectDragger.rbxm.SelectDragger.Packages.DraggerFramework.DraggerTool', Line 119
15:52:14.112 - Stack End

Studio version: 430

5 Likes

Thanks for the clear report, will be fixed.

2 Likes

if a model is anchored, I would usually be able to drag it using the move tool. But now, I have to unanchor it.

This should work just fine with the new draggers. Can you take a video showing the issue?

1 Like

robloxapp-20200429-1650130.wmv (286.6 KB)

I reset the settings and it still happens

Both of those drags are being done with the old draggers.

1 Like

So how do I fix it? It worked fine before, so I assumed it was the new draggers that did it.

I turned the new dragger on, and it still happened.

You probably have Constraints turned on (the button beside Collisions and Join Surfaces) in the Model toolbar. If you turn that off youā€™ll be able to move anchored parts. Common mistake.

1 Like

When dragging any selection on the highlighted hill Iā€™ve managed to produce the following stack trace, though this doesnā€™t seem to affect anything outside my output being spammed as I can use the tools fine.

LimeRepro.rbxl (31.1 KB)

07:13:02.551 - Plugin_SelectDragger.rbxm.SelectDragger.Packages.DraggerFramework.Utility.DragHelper:209: bad argument #2 (Vector3 expected, got nil)
07:13:02.554 - Stack Begin
07:13:02.555 - Script 'Plugin_SelectDragger.rbxm.SelectDragger.Packages.DraggerFramework.Utility.DragHelper', Line 209 - function getDragTarget
07:13:02.555 - Script 'Plugin_SelectDragger.rbxm.SelectDragger.Packages.DraggerFramework.Implementation.DraggerStates.DraggingParts', Line 132 - function _updateFreeformSelectionDrag
07:13:02.556 - Script 'Plugin_SelectDragger.rbxm.SelectDragger.Packages.DraggerFramework.Implementation.DraggerStates.DraggingParts', Line 85 - function processViewChanged
07:13:02.556 - Script 'Plugin_SelectDragger.rbxm.SelectDragger.Packages.DraggerFramework.DraggerTool', Line 333 - function _processViewChanged
07:13:02.556 - Script 'Plugin_SelectDragger.rbxm.SelectDragger.Packages.DraggerFramework.DraggerTool', Line 177
07:13:02.557 - Stack End
07:13:02.557 - RunService:fireRenderStepEarlyFunctions unexpected error while invoking callback: Plugin_SelectDragger.rbxm.SelectDragger.Packages.DraggerFramework.Utility.DragHelper:209: bad argument #2 (Vector3 expected, got nil)
5 Likes

I thought that too at first, but after checking to make sure collisions were disabled, it still behaves like what I showed. I also find it really weird and unusual that now I have to disable collisions to prevent a part thatā€™s being imported from moving a mile above me if Iā€™m building something underneath objects. There should be an option to turn this annoyance off. For this reason alone, I wonā€™t be able to use the new dragger, but Iā€™m sure a fix will be out soon :slight_smile:

Edit:
As I side note, I really do not want to have to turn off can collide for every part I import to have a smooth building process and then having to turn them all back on once Iā€™m finished.

Edit 2:
Bruh did the other dragger get updated too? Itā€™s literally a complete pain to work in studio now. Pleaseeee tell me there is an option to stop this :frowning:

Edit 3:
This is very not much cash money. Itā€™s impossible for me to make half of the stuff I would normally make on studio, because partā€™s can no longer intersect, even when collisions are turned off for the part Iā€™m moving and the part thatā€™s being intersected.

Edit 4:
Probably the last of the edits, but as it turns out, this seems to only be a problem for me. For my friend, it seems to work fine.

Edit 5:
At this point, I might as well make a novel of my edits. Anyways, I thought it might be a good idea to make a gif of whatā€™s happening.
Date__05-01-2020__Hour-20-_Minute-37-

Edit 6:
Well, after the 3rd time trying to re-download it, it seems the problem is fixed. I would still like an option to ignore collisions while building though!

Also sorry for the late response, my wifi has been up and down.

2 Likes

Does this correct the floating point issues that have been a prevalent issue for a very long time? Something Iā€™ve reported in the past that 2 years later with the built in draggers and build tools remain an issue for myself and my team.

A quick refresher, this error causes all parts that have been dragged, scaled, moved using the drag tool, resize tool, and move tool, have resulted in a minor floating point error just large enough to be visible in game. When doing precise work this is a major issue and the primary reason most of my team, and myself include have migrated most modelling and map production to a 3rd party application.

I found aā€¦ thing?
Had a 1x1x1 wedge, duplicating it then rotating it and moving it resulted in this error:

Example

Date__05-03-2020__Hour-11-_Minute-44-

Causing annoying float point errors.

Edit:

So apparently inserting any part currently in the place Iā€™m working on is automatically giving said part a float point error, and yes, I checked the base plate CFrame. Itā€™s all normal. bruh.

Error

Date__05-03-2020__Hour-12-_Minute-01-

When opening the context menu while dragging any selection I get these errors, they donā€™t seem to affect anything outside my output being spammed:

12:53:44.069 - Plugin_ScaleDragger.rbxm.ScaleDragger.Packages.DraggerFramework.DraggerTool:306: assertion failed!
12:53:44.069 - Stack Begin
12:53:44.069 - Script 'Plugin_ScaleDragger.rbxm.ScaleDragger.Packages.DraggerFramework.DraggerTool', Line 306 - function _processMouseDown
12:53:44.070 - Script 'Plugin_ScaleDragger.rbxm.ScaleDragger.Packages.DraggerFramework.DraggerTool', Line 112
12:53:44.070 - Stack End
4 Likes

I have a fix for this coming out next week.

Like, just right click->insert part? And not dragging it? That insert code is entirely separate from the draggers.

Are you working far from the origin? I have a fix coming this week that should fix that case, I made a mistake which generated a lot of floating point error for people working far from the origin.

1 Like

I wasnā€™t working too far from the origin, but good to know a fix is coming soon.

For inserting the parts, it seemed to be that right after the error with moving the parts, the float point error for inserting parts happened - Inserting parts before this error resulted in expected behavior, although dragging said inserted part fixed it. Not sure how or if the two are related though.

Will we also eventually be getting an option to ignore collisions with the draggers? It would be like 100x better if we got that option (by that I mean workflow would improve, and probably other users workflow would be much smoother).

Oh one more thing, even with collisions off with the current dagger, duplicating parts results in the duplicated part being inserted above the part being duplicated. Is this intended? As of now itā€™s somewhat annoying always having to re-position the part.

Anyways, thanks for the response!

Removing the floating point error is impossible, having some floating point error is just the reality of working in 3d game engines.

What I tried to do with these improvements is make it easier to work around the floating point error that does happen. In being able to snap geometry nicely, it should be much easier to fix the alignment of things that should be lined up with eachother simply by dragging them.

If it seems like the floating point error got worse (especially when working far from the origin), it did, at least temporarily. I made a stupid mistake in part of the code which Iā€™m releasing a fix for this week.

What do you mean by this? I already made them ignore collisions in the way that made sense to me, in ignoring collisions while freeform dragging.

Youā€™re the second person to report this, but I canā€™t reproduce. For me it works exactly like it did before, respecting the Collisions option. It is certainly not intended if it has changed.

Currently for parts to intersect you would have to manually turn collisions off for parts and then turn collisions back on for individual parts once youā€™re finished with whatever youā€™re building, (this is for arrow dragging/scaling/rotating) maybe instead we could have it so that the dragger (not the free form dragger) just ignores all collisions, which would reduce the amount of steps needed to wellā€¦ build.

Thatā€™s pretty odd, as this is always happening to me, even after I re-downloaded studio.

Here's what happens

Date__05-04-2020__Hour-13-_Minute-21-