Hello, PrinceTybalt !
I can confirm to you that I can access both documentation & tutorial pages for the DragDetector. I guess sometimes, things behave weirdly and we wouldn’t be able to explain them 
The reassuring part is that it is the very first time it happened to me in years of checking documentations, so it must be a really rare occurrence (?)
Yup, I considered doing that at one point. 
So I was trying the HingeConstraint door setup that’s in the video from earlier with an axis that allowed me to do a vertical type door. However, I don’t know why RotateAxis wouldn’t push the door all the way back. I don’t think I’ve ever got it all the way up no matter what angle I tried. As you can see in the video below, I use my character to push the blue door since I can’t get it past the midpoint:
TranslateViewPlane (that’s the red part) obviously works the best in this scenario when viewing the mechanism from the side. Ideally I’d want to be able to drag the door open all the way from the front and the side, but I don’t know if there’s a DragStyle that’d allow me to do that.
EDIT: I think I got it working better with RotateAxis after changing the Axis. I assumed I had the right axis because it worked fine with TranslateViewPlane, but I guess I was wrong.
The reason why I believe network ownership is involved is because this is what the problem looks like with AreOwnersShown turned on:
As you can see, I can only drag the part once I’m the owner of it. I’ve also noticed that I sometimes lose ownership of the part with the DragDetector once I start dragging and regain ownership when I stop dragging.
@PrinceTybalt hello,
I wanted to know if it would be possible to add some sort of Adornee property to ClickDetector class (and proximity prmpt?)
I have a project of using the DragDetector as a tool to move parts around to create a level.
The only one thing I’m concerned with is if a part the player is manipulating, is getting deleted by another player. I’m afraid of instabilities of the DragDetector being destroyed as well.
Such a property would help in this way
Just want to know your opinion about this feature, I thought it would be a good idea!
Thanks for your time, and all the rest 
If a DragDetector or the part are destroyed while a player is manipulating it, the DragDetector should exit gracefully; as if you let go of the mouse. So if that’s your concern, it might not be an issue. If you try this and something seems funny, please let us know.
Is there another reason, though, why’d you’d like to associate an adornee with a DragDetector?
I think for the axis, it looks like in your video the DragDetector is set to rotate about the Y axis. Your hinge is about an axis in the plane, perpendicular to Y. And so it works a little bit, but only up to a point because you start applying all your force in a direction perpendicular to where it does any good.
I think if you switch your DragDetector axis to either (1,0,0) or (0,0,1) it will fix it.
I will eventually try a few systems to make sure the DragDetector isn’t getting removed, like a signal using RemoteEvents, that make every client reparent the DragDetector before the instance’s getting deleted.
I can try to imagine something else that can work
This little “problem” (that can be solved as explained before) was the only reason why I suggested it
Yet I don’t have any issues with the DragDetector itself. I was expressing a concern I had while remaking my whole building system.
If I have any issues, I will of course let you know !
That was the case in the end. I ended up changing it to (1,0,0) and now it works how I would expect it to, at least from the side. Dragging from the front still doesn’t get it past that midpoint ocassionally, but most of the time it does.
As for network ownership, I think I know what is happening.
Do you have runLocally set to true?
If runLocally is the default (false) then anybody can operate the DragDetector, regardless of network owner. And you don’t have to think about it.
But if runLocally is true, then you need to have network ownership because the network owner cannot learn of your actions. All is not lost, however: during your local script’s dragStart callback, you may employ a RemoteEvent to request network ownership from the server. A separate server script sets the network owner as requested; and then you are good to go.
There is an example in “DragDetectors Test World 2”. If you load it into studio and search for “NetworkOwnershipEvent” you should see all the scripts that rely on it. One good example to check out would be “CircleConstraintNonAnchored_Physical_RunLocally.”
I figured that might have played a factor in the problem. I’m wondering why it’s recommended for the developer to request network ownership and assign network ownership as the solution? It sounds like a lot of boilerplate every time I want to use RunLocally. Shouldn’t that be the job of the DragDetector?
When you say “Dragging from the front” are you talking about standing so that the hinge is horizontal in front of you and trying to “lift” the door?
If so, I have bad news and I have good news. The bad news is, yes, it’s wonky. It’s just like if you try to rotate a Roblox Studio Rotate Dragger ring when it is edge-on: it moves incoherently.
This is something we can and will fix, in time.
Here’s what’s happening: imagine a DJ scratching a record. That’s how our RotateAxis drag detectors work. But when you are edge-on, the points that your finger traces on that circle all collapse into a line and you can’t work with it any more.
The fix is to treat the edge-on case special. We move it as if you stroked your hand along the edge of the record. The action is more like a rolling pin or rolling a hoop.
That is a really great idea, but there may be an issue with security.
Network Ownership can only be transferred on server scripts, not local scripts.
But if we do this automatic behavior you suggest, then during a game, anybody could run a local script to create a DragDetector and set it to runLocally. Then, basically they have a local script that can steal network ownership while they are operating a DragDetector, without needing to get server permission.
I personally was thinking of the DragDetector automatically requesting ownership of the part only if RunLocally is set to true. The server would validate if there’s a DragDetector with RunLocally set to true and give ownership as long as the part/assemblyRoot has SetNetworkOwnershipAuto (meaning it wouldn’t conflict with the developer assigning the network owner manually).
A player touching a part can give them ownership of the part, why not using/dragging a DragDetector that the server has? I think that’s the main question I have in my head.
More good points. I will check this out with the security experts here at Roblox and investigate.
it work i have sides made and it canot out it
I hope you enjoy my creations
In this video i show you my drag detectors creations drag detectors are a new (beta) function on Roblox for now it work only in studio idk when it will work on Roblox check the dev forum for more information
©2023 happy games studio,s
---------------------------------------links---------------------------------------
Website happy games studio,s: removed link i think not that it can here because it us a link to my website but idk which links i can place here
Model sliding wall:
https://create.roblox.com/marketplace/asset/13544639781/slidingwall
Model desk with drawers and stuff in it:https://create.roblox.com/marketplace/asset/11124093431/beuro
Model puzzle:
https://create.roblox.com/marketplace/asset/13757666510
About drag detectors dev forum:
DragDetectors [Beta]
(This link bring you to above 
)
Have a nice day and 
the full release is close? i really want to publish what i was working on this days
Wow this is awesome! You got the sliding puzzle working and you are our first creator to make a full video presentation like this with DragDetectors!
Congratulations on some nice work, @foodeggs7
I noticed that your last sliding block got stuck.
It looks like it didn’t drag in a fully straight line and it got stuck against a corner.
There are 3 things that might help here:
[1] I think you are using TranslateLine for your DragStyle, but if you are not, you could switch to TranslateLine from TranslatePlane (and then adjust the Axis property to point in the direction of motion).
[2] I think though that you are using TranslateLine, with a non-anchored part in Physical ResponseMode. So! You can set the DragDetector.ApplyAtCenterOfMass to true. Then when you drag, the forces will be applied at the center and not at the point where you click; the result is that the part will move in a more direct line. After this, I doubt it will be aproblem, but if your block bunks into something, it could still get rotated out of alignment, in which case you may want to add [3] below.
[3] If this still doesn’t do it, you could add a Prismatic Constraint to keep it moving only in a line. This is harder because you need to add an attachment to the moving part and an attachment to a fixed part; make sure they both lie on the same line with respect to the motion you desire; make sure that the X axes of the 2 attachments are both pointing in the direction of motion; then add a Prismatic Constraint; then set the constraint’s 2 attachments to be the ones you just created.
You mentioned a bug with axis resetting. I watched your video but couldn’t tell exactly what you did between editing the axis and then going to the game page and hitting edit. But it looks like you maybe did not save and publish the game first?
Have you figured out what was wrong or are you still having a problem with this?
I have celobrative editing enabled for that place so he sall automatically save
i have clicked save after change but after restart he still reset
i have done a restart test with the atachments but here it svae the axis just
i have tried set the axis with a script but then i get errors
i have done the atachments but then the moving part run away
I gave SetDragStyleFunction a whirl tonight and ran into a few issues. Let me explain what I was trying to use it for first. I tried to use it to position a draggable object in front of the character at all times. The script positioned the object in front of the character’s head if the player was in third person. If the player was in first person, the object would be positioned wherever their mouse is on the viewport. In most circumstances, that’d be in the center of the screen. Here’s what the script looked like:
local DISTANCE_FROM_CHARACTER = 4
local dragDetector = script.Parent
local draggablePart = dragDetector.Parent
local currentCamera = workspace.CurrentCamera
local currentGuiInset = game:GetService("GuiService"):GetGuiInset()
local function shouldUseHeadAsOrigin(): (boolean, CFrame?)
local cameraSubject = currentCamera.CameraSubject
if cameraSubject then
local isLockedToHead = cameraSubject:IsA("Humanoid")
if not isLockedToHead then
return false
end
local currentHead = cameraSubject.Parent:FindFirstChild("Head")
if currentHead==nil then
return false
end
local currentCameraFocusPosition = currentCamera.Focus.Position
local currentCameraPosition = currentCamera.CFrame.Position
local isCameraInFirstPerson = (currentCameraFocusPosition-currentCameraPosition).Magnitude < 0.75
if not isCameraInFirstPerson then
return true, currentHead.CFrame
end
end
return false
end
dragDetector:SetDragStyleFunction(function()
local shouldUseHead, headCFrame = shouldUseHeadAsOrigin()
if shouldUseHead then
return CFrame.new(headCFrame.Position + headCFrame.LookVector * DISTANCE_FROM_CHARACTER) * headCFrame.Rotation
end
local currentMouseLocation = game:GetService("UserInputService"):GetMouseLocation() - currentGuiInset
local viewportCursorRay = currentCamera:ViewportPointToRay(currentMouseLocation.X, currentMouseLocation.Y)
return CFrame.new(viewportCursorRay.Origin + viewportCursorRay.Direction * DISTANCE_FROM_CHARACTER) * currentCamera.CFrame.Rotation
end)
All the DragDetectors in this post use RunLocally.
The first issue I ran into was that I had no clue what parameters were passed to the DragStyleFunction from the docs and from studio’s intellisense. The only hint that it passed down a parameter was this part from the documentation:
it receives the signal’s world space cursor ray
Which in itself is a bit vague. It mentions the cursor, but from what I saw, it’s not the same as what I did with my DragStyleFunction for the viewportCursorRay variable. It’d be nice if there was a small explanation of what the parameter really is. In addition, a simple example function that could be passed to SetDragStyleFunction on the doc site that shows off that parameter would be handy as well.
I was messing around with the draggable object that used the code above and I noticed that the orientation of the object didn’t match what I was giving through my DragStyleFunction. I was heavily confused because the docs said this about the CFrame that the function returns:
it returns a CFrame containing the desired location and orientation of the pivot in world space
After a bit of investigating, apparently no AlignOrientation object is created when using a Scriptable DragStyle plus the Physical ResponseStyle. The Geometric ResponseStyle works as expected, so this definitely looks to be unintentional. Here’s what it looks like:
As you can see, the part with the Geometric ResponseStyle always has the red face pointing towards the character, like it’s supposed to. However, with the one that has the ResponseStyle set to Physical, it doesn’t do anything with the orientation.
When dragging an object with the ResponseStyle set to Geometric, the object stutters since it’s being CFramed after the frame has been rendered, leading the object to being always a frame behind position wise. With this ReponseStyle, I don’t think this should be happening. Here’s a quick look at that:
When using the Geometric ResponseStyle, the object is positioned at the CFrame I returned with my DragStyleFunction (as seen in the video above), like I expected. However, when using the Physical ResponseStyle, the object rarely seems to be positioned correctly, if ever. I’m not sure what exactly is going on here. Here’s what that looks like:
In that video, I would expect the starting drag point to be where the cursor is. At the end though, you can see the cursor be on the opposite side of the part where the drag originated. No clue if that makes sense. The DragStyle being used here is the same as earlier (scriptable with the snippet at the top).
The DragDetector does indeed have ApplyAtCenterOfMass enabled in that video. However, with or without it enabled, I still get unexpected results with where the object is ending up.
If a player is dragging a DragDetector when their character respawns, the AlignPosition and AlignOrientation constraints aren’t cleaned up until a different player tries dragging the object. There’s also some kind of desync when the ResponseStyle is Geometric (the client has it frozen but the server doesn’t).
This means if a player dies while falling and dragging an object, the object has the potential to be stuck floating in the air and out of reach.