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
Is there a way to only drag on a certain axis? Or do we have to use Scriptable DragStyle
2 Likes
Yes! Check out the documentation on Drag Directions which effect the axis used by the Drag Style
And you can change the axis dynamically. Check out “Throw It” in “DragDetectors DemoWorld 2”
1 Like
True, b it they’re also waiting for our feedback before trowing it out! Be patient, patience will be rewarded…
1 Like
I could try using the RightMouseClick from the DragDetector, I’ll tell you how it goes!
I’m also happy to notice Roblox is being more transparent and helping the Community out!
2 Likes
Update!
Changing the ResponseStyle works, I also uncovered something:
You can use parts with DragDetectors as “rafts”!
2 Likes
Great feature. But one thing:
- I can’t seem to find the detectors in my new object menu. They are turned on in my beta settings, and I have restarted studio twice. Not showing in the test place either.
2 Likes
I found another thing:
If you are moving something and your Mouse points the void, the part will simply be stuck with physics - like if it’s Anchored
I’m not sure if it’s a bug or intended behaviour
1 Like
I am making a game to test this new feature but in the actial game the drag dosent work, it work in the roblox studio test client but no in the game one, it is not out to make games? only to test or its an error?
1 Like
It’s only out for Studio, it’s not usable in Games still
3 Likes
when it will go out for games too?
1 Like
There’s no exact date, but I think you can expect it for middle-June/July (note that I’m not an expert and it’s just a very rough estimate)
3 Likes
You’re right MouseClick also fires when player stopped dragging or release their mouse input.
This is my solution to it, actually It’s very easy.
local player_continued = false
box.drag.MouseClick:Connect(function(player)
if not player_continued then
tooltip_module:tooltip(true, main, player)
end
end)
box.drag.DragStart:Connect(function()
player_continued = false
end)
box.drag.DragContinue:Connect(function()
player_continued = true
end)
The player_continued defines if the player is not meant to click to the object but meant to drag it.
When DragContinue fired player_continued will be true resulting that player really wants to drag the object not click it.
From what I believe DragContinue only fires when DragStart fires and the object and mouse starts to move…
3 Likes
You are correct. DragContinue will only fire after the DragStart fires and the mouse moves.
(Note that the object does not have to move, for example if you set the ResponseStyle to Custom and don’t change the position yourself. This is how the 3 buttons and the CubeCreate demos were done in “DragDetectors TestWorld 2”)
2 Likes
Piggybacking on what @DeFactoCepti said:
If you want to make a door or box that can be locked and unlocked by clicking, you are probably best to have a ClickDetector below one part to lock and unlock; but have that be included below a larger model that has a DragDetector to rotate it. If the lock is located within that larger model, it will rotate with everything else even though it has its own ClickDetector.
What you should avoid is adding a ClickDetector and a DragDetector as siblings to each other.
So this is a nice structure for this sort of thing:
ModelForWholeDoor
DragDetectorForWholeDoor
DoorPart
DoorKnobPart
LockButtonPart
ClickDetectorForLock
Your ClickDetectorForLock could set enabled/disabled on your DragDetectorForWholeDoor. And the DragDetector would not require a script at all.
If your parts are Anchored, your DragDetector will edit the pivot of ModelForWholeDoor and move it all together.
If your parts are NOT anchored and your DragDetector is in Physical mode, you will want to weld those parts together!
3 Likes