@hellohennessy well, that depends on your system.
We tried to build DragDetectors to be efficient, but if your system is highly specialized to your needs, it might be faster.
We’d be curious to hear the result if you try it out, but you are the only one who can truly answer this question.
@x_maks441 Hmmm. Others have tried this and been successful, so the models can’t just be broken.
There must be something about your situation.
Maybe we can trouble shoot?
[1] Are you trying to use these in studio edit mode, or in play mode? They really should work when you hit play or test. But they won’t work in Studio Edit mode because the scripts don’t initialize
[2] Are you sure that the DragDetectors are still set to have DragDetectors.runLocally to true? The scripts are local scripts and so this is required
[3] Did you try publishing it to a game and then playing the game? Do they work in that case?
(The deprecated type shouldn’t really matter I don’t think).
If you follow these steps, can you drag the object?
[1] create a part
[2] place a DragDetector below it
[3] hit play
[4] can you drag it?
[5] if not, try making the part Anchored. Does it work now?
Good to hear my feature request didn’t fall on deaf ears, if you are going to add a 2D variant of this, being able to snap to a position is a must (unsure if DragDetectors already have this?)
@PeZsmistic by the way, if you look above under “What’s Next” you can see that we are hoping to make Network Ownership “do the right thing” automatically.
We’ll make it so that if you are dragging with runLocally true, you’ll automatically have network ownership (only) during the drag.
Commensurate with that, we’ll add the API you see under “Security Control” so that exploiters can’t just grab network ownership without permission by clicking an object. You’ll be able to decide who may drag which part.
If you have feedback on that proposed API we’d be happy to hear it.
@metatablecatmaid See the above post 4 above yours about constraints.
The intent is that you’ll be able to constrain your 2D objects using the exact same API as you do for 3D objects.
that didn’t work, still unable to drag it when testing.
When playing the game, it works, but studio doesn’t, thats weird.
I’ve been messing around with them for a while and I’ve figured out that DragDetectors don’t work if they are parented with a Humanoid. Setups such as the one below do not work.
Is this a bug or is there a reason for this?
BTW You want cool new button actions?
Here’s some info info I sent to a user in our old beta posting:
You can actually make some cool variations on buttons using DragDetectors that you were never able to do with clickDetectors, because you can detect both the down and the up on dragStart and dragEnd.
If you set the ResponseStyle to custom, and then don’t do anything, then the part won’t move but you can still detect down and up.
There are 3 button examples in DragDetectors TestWorld 2
A push button, a sprarying button , and a toggle button:
@paper_hat Can you post a video or link showing exactly what you are doing so I can see what’s happening? (Also uninstall and reinstall first, if you have not already?)
@strawbberrys
I’m curious what your end goal is for the interaction you want in your game. Care to share?
And I did some experiments.
I created a rig with RigBuilder.
I found that whether you place the DragDetector under the model, the HumanoidRootPart, or any of the body part meshes, you’d get the same result. You move the whole body.
But then if you place that model under StartPlayer and name it StarterCharacter, then the DragDetectors have no effect when you run the game using the rig as an active player.
It might be reasonable to expect this to work; but there may be a conflict with all the player scripts that control how it moves and animates.
I need to talk to some other people to determine whether this is really a bug or if the player scripts would be expected to prevent the dragging. I dont’ see a cursor change though, which is a bad sign.
@strawbberrys well this is interesting.
You can drag other players, just not yourself! And when you do it they respond by animating to walk where you drag them
There is specific code in our ClickDetectors and DragDetectors to prevent clicking on your own players avatar. It was added to fix a bug that was reported.
Is it important to be able to drag yourself and not others?
Super cool! I’m questioning reality after this.
Here are two short videos I created during the beta. We’ll add them to the list up top soon too:
How To Create A Sliding Door With DragDetectors
How To Create A DragDetector that Only One Player Can Operate
@PrinceTybalt Thank you for your reply. DragDetector is also off the beta list in my Studio.
And in this way, DragDetecotor is indeed ready to be added from the explorer, and it works when I publish the space. However, only Roblox Studio test play does not work. In Roblox Studio, the Drag “hand” icon appears like this, but the object cannot be moved. This is the same phenomenon even if I bring the test space you introduced above to my Studio.
Hmm. The hand icon is correct for DragDetectors, so the DragDetector code is getting called.
Check the output window. Do you see anything printed?
If not, try adding print statements into the dragStart, dragContinue, and SetDragStyleFunction to see if hey get called.
What about the green one, which uses geometric style motion and no constraints?
And Can you use a simple DragDetector case?
Try doing just this:
[1] add a part
[2] set it anchored
[3] add a DragDetector below it
[4] hit play.
Can you drag that one?
I get that is possible with scripting, it just seems like it would be a logical property of the draggers , considering even the tools in studio can snap movement and rotation.
Thought I would mention it, considering almost every ‘move part’ script I have ever made, needed some sort of snapping.
@PrinceTybalt As you said, I tried to attach an anchor to the Part and tried installing DragDetector.
But it didn’t work in my Studio. When I published it, it worked in the published version.
The one below is the public version.That’s the gray part.
I checked the output, but no particular errors occurred.
Regarding print, I don’t know enough about programming and didn’t know how to do it.
Those messages in your output may have something to do with the problem. I don’t see those on a normal installation of Roblox Studio, and they are not produced by my scripts.
In particular the “hotFix” output is strange.,
“Stored Mouse” is especially concerning since it’s happening on the client (hooray for katakana) and the mouse is the input that DragDetectors care about.
Maybe you have some kind of plugin installed? Try disabling all your extra plugins and restart studio?
Maybe reinstall studio entirely if that does not work?