MouseClick and RightMouseClick are inherited from ClickDetector, so you can also use those events. I used RightMouse click in a line editor to delete the point I was working on, for example.
I’m not sure what you mean by making Crates openable and draggable though. Maybe you mean like the door unlocking example we were discussing in this thread?
1 Like
It’s hard to guess exactly what you mean, but it sounds like using DragStyle = TranslateViewPlane might get partway there.
1 Like
yeah, that is what im using, but when looking down or using first person the part slowly drifts into space
1 Like
Hmm 
I wonder if a hacky system like this could be recreated using this new feature. Thoughts?
I guess I’ll give it a shot.
4 Likes
Can you post a video of what looks wrong, and try to describe what you’d like to see happen instead?
If you look down, viewplane is parallel to the ground, so it would move away.
Is the idea that you want it to move always in a vertical plane, but the plane should shift with your point of view?
if that’s what you are after then this script might help. It sets the plane of motion to always be vertical, but in the direction you are looking; kind of like viewPlane except always tilted to match world vertical.
local dragDetector = script.Parent.DragDetector
dragDetector.DragStart:Connect(function(player, ray, viewFrame, hitFrame, clickedPart, vrInputFrame, isModeSwitchKeyDown)
-- select the vertical plane most perpendicular to the viewPlane
local look = viewFrame.LookVector
local x = math.abs(look.x)
local y = math.abs(look.y)
local z = math.abs(look.z)
local yVec = Vector3.new(0,1,0)
local screenX = yVec:Cross(-look)
local foo = screenX:Cross(yVec)
dragDetector.Axis = foo
\
dragDetector:RestartDrag()
end)
When you use the above, if you look straight down then the motion plane is a sheer wall which may be weird. So you can use this version to swtich to the ground plane when you are looking down:
local dragDetector = script.Parent.DragDetector
dragDetector.DragStart:Connect(function(player, ray, viewFrame, hitFrame, clickedPart, vrInputFrame, isModeSwitchKeyDown)
-- select the vertical plane most perpendicular to the viewPlane
local look = viewFrame.LookVector
local x = math.abs(look.x)
local y = math.abs(look.y)
local z = math.abs(look.z)
local yVec = Vector3.new(0,1,0)
if y >= x and y >= z then
-- use Ground Plane instead
dragDetector.Axis = yVec
else
local screenX = yVec:Cross(-look)
local foo = screenX:Cross(yVec)
dragDetector.Axis = foo
end
dragDetector:RestartDrag()
end)
Does any of that help?
2 Likes
Let us know how it goes. You may want to set DragStyle = Scriptable and then write a method that always returns a CoordinateFrame that is facing the avatar and positioned right in front. There’s an example of registering a scriptable dragStyle in the DragDetectors tutorial page and also in “DragDetectors TestWorld 1”
2 Likes
Alright! Thanks so much for your insane amount of activity on this post and all of the assistance you’ve provided to the community. On behalf of all of us, we appreciate it - it’s not something you see every day from staff members. 
I’ll let you know how it goes!
5 Likes
Uhm what I meant is like Crates that is openable when clicked and draggable when being drag by the mouse input. So you can basically do that without putting ClickDetector? If it is wow that is some convenience…
2 Likes
It’s a great feature, I can’t wait!
I tested it out, it’s awesome!
When do we expect to have this feature available in a published Roblox game? Right now it’s only available in studio.
2 Likes
They want to make sure they get alll the feedback and all bugs are fixed, so I would expect it to come for middle June/July but I can’t give an exact date and I’m not a Roblox employee so I can’t know for sue but it’s just my estimate
2 Likes
Basically like the example I needed?
Basically you can unlock the door and then you can drag it around a hinge?
3 Likes
It’s a beta release so it is understood that there would be bugs. I say we just throw it in, that’s when all the bugs come out.
2 Likes
Again, remember to search to see if your question has already been answered before asking.
2 Likes
Thanks, that’s very nice of you to say.
I will keep coming back here as long as you keep asking questions and hope you will spread the knowledge and help others.
You are the first people trying this feature. If I help you use it to its full advantage, I’m hoping that you will pass it on.
7 Likes
I believe you can do what you want., If you try it, let us know how it goes and I’ll try to help if you can’t make it work
3 Likes
Base as is will cause the part to get further and further when dragging in 3rd person, better viewable when moving it around fast, which i want to avoid since i want to keep it without a certain radius around the player
I believe Lumber Tycoon 2 does this by some fancy CFrame magic with the camera + character position
settings /\
I do want to note, the drag instances are added during runtime via the bombs when they blow parts up, allows players to only drag broken bits
1 Like
Awesome! Again, really do appreciate it. I’ve already told some of my colleagues and friends about this awesome new feature as it definitely could help them with what they’re doing, and I’ll continue to do so. Hopefully I’ll be able to help others in future with the knowledge I gain from working with this feature, as you stated.
Just a question; is there any way to get a reference to the player via the SetDragStyleFunction method on the server, or do I need to use remote events to accomplish this (
)? Not sure how I’d get the player’s character to derive the CFrame from, otherwise.
Edit: Here’s my code so far (disregard how the player is retrieved, testing purposes only until I figure out how to do it correctly):
local dragDetector = workspace.meat.DragDetector
dragDetector:SetDragStyleFunction(function()
local player = game.Players:FindFirstChildWhichIsA("Player")
local character = player.Character
if character then
local humanoidRootPart = character:FindFirstChild("HumanoidRootPart")
if humanoidRootPart then
local newPosition = humanoidRootPart.CFrame.Position + humanoidRootPart.CFrame.LookVector * 5
return CFrame.new(newPosition, newPosition + humanoidRootPart.CFrame.LookVector)
end
end
return dragDetector.Parent.CFrame
end)
What I can’t help but notice so far is the jitter and delay that occurs when I move whilst holding the item and the item moves (well, attempts to) with me. Would the RunLocally property (with remote events) help with this, or maybe something to do with NetworkOwnership?
There’s probably a simple solution to this so my dearest apologies if I’ve skimmed over some important info in the documentation that anwers these questions. 
2 Likes
Also tagging @Dede_4242
A possible solution to this could be using ClickDetector events to first run some logic. As DragDetectors are ClickDetectors themselves, all ClickDetector events are also available for use.
It should be noted though that events like MoseClick would overlap with Drag events. An event like RightMouseClick, however, would not trigger any dragDetector events, allowing for separate logic.
I do unfortunately think that the best way might be to use a clickDetector purposed specifically for the opening/closing logic though, as that would allow it to enable/disable the dragDetector as you wish, and also limit the opening/closing trigger to a specific part that’s not necessarily the draggable part.
If you happen to come up with other solutions, please let us know! We’re interested in how people use it and I’m certain that the community will come up with creative ways to use it that we do not expect 
3 Likes
If what you want is for the object to always stay within a certain distance of the character as. you move and carry it, you might want to add a Scripable DragStyle as I suggested in this reply above.
Or, if you still want the player to be able to drag away from the center of the screen as you move but stay in a plane that is not too far away as you turn, then you could stick with TranslateViewPlane but add a constraint function that takes the proposed motion and modifies it to not be too far away; this might be a little tricky to get the math right but those two entry points will let you do that kind of modification while still working with DragDetectors
P.S. Adding DragDetectors at the right time with server scripts, like when your bombs explode, is a nice way to go.,
2 Likes
This is really neat and you are on the bleeding edge trying this technique for the first time (I haven’t done it myself yet) so your questions are great and there’s no need to apologize.
You can get your player by saving it during the dragStart callback:
local dragDetector = workspace.meat.DragDetector
local draggingPlayer = nil
dragDetector.DragStart:Connect(function(player)
draggingPlayer = player
end)
dragDetector.DragEnd:Connect(function(player)
draggingPlayer = nil
end)
dragDetector:SetDragStyleFunction(function(proposedMotion)
if draggingPlayer == nil then
return proposedMotion
end
local character = draggingPlayer.Character
if character then
local humanoidRootPart = character:FindFirstChild("HumanoidRootPart")
if humanoidRootPart then
local newPosition = humanoidRootPart.CFrame.Position + humanoidRootPart.CFrame.LookVector * 5
return CFrame.new(newPosition, newPosition + humanoidRootPart.CFrame.LookVector)
end
end
return dragDetector.Parent.CFrame
end)
The jitter may be from server roundtrip delay.
I tried changing the dragger to runLocally and put the script in a local script and it was more responsive.
BTW you will get better results in your local script using:
local dragDetector = game.Workspace:WaitForChild(“meat”):WaitForChild(“DragDetector”)
It could also be in part because we’re setting pivots/cframes here and when we get resuls from the server we don’t interpolate to the new value the way we do when physics is running; so it jumps and the jump is magnified [a] by the delay and [b] because you’re rotating the head, which often feels jittery because it’s quick motion on screen for a smallish rotation.
2 Likes