It already works in VR!
DragDetectors work with mouse, gamecontroller, touch, and VR. We wanted to take care of all the input devices for you so you don’t have to think about it.
You can click and drag anything with a DragDetector under it using the VR laser pointer.
The dragging will work the same as with a mouse, but controlled with your VR hand device.
Also, if you set the DragStyle to “BestForDevice” you will be able to move the object with 6DOF in VR.
It’s not a hand grab; that’s a different action. It’s the remote laser. Hope you find it useful.
I think that, since DragDetectors are not yet turned on for released games. I have not tried this personally but my understanding is it works on windows machines if you hook up your VR headset with Studio.
Roblox staff woke up today and just decided to release a great feature
I can see millions of possibilities with this new feature, I can definitely see people using this a lot. I might try to use this feature in an obby game where you have to drag floating platforms in order to get past.
When might we be expecting the full release of this?
Every new feature that has “detector” or “sensor” in it, I love it.
Anything that helps with physical interaction without heavy math is an absolute must for Roblox to keep improving tools for developers.
I assume that the part you are clicking is not anchored?
You may get the result you want if you change the ResponseStyle to Geometric instead of Physical (which is the default).
When you do that, instead of driving the motion with a constraint (which I see you have found!), it will temporarily anchor that part and move the pivot of the model instead. If there are other parts that are not anchored though, they may not move along with the parent pivot. We don’t search for ALL non-anchored children and temporarily anchor them. If you are following me so far… is anchoring all the non-anchored descendants while moving the model pivot something you would want in geometric mode?
Also: That AlignPosition should go away before our final release. We intend to use internal methods that do not add instances to apply the constraint forces.
Alternatively, if the part you click is anchored, it will always move the pivot of the parent without physics.
Varonex, can you clarify whether this second video shows a new issue that I didn’t talk about in my response above? Or is there a second issue you’re bringing up here?
Looks like another awesome Roblox Update! I can see this being great for puzzle-solving games, obstacle courses and even more. Loving the full coverage in the API too. Good job!
We want some soak time to fix a couple of non-crucial bugs, so you creators can give us feedback to know we got it right, and in case any of that feedback makes us want to change the API. Once we put it in games there is no going back!
Hi bigbenster702.
By default, yes. When you click and drag, the dragStart, dragContinue, and dragEnd events are sent to the server. The server makes the changes to the world, and they are replicated to all players.
But if you set the DragDetector.RunLocally property to true, then the events are run locally instead of going to the server. In that case, no other player will be affected.
RunLocally is useful, say, if you want each player to have their own slider to control volume of music or level of lighting. In this case, though, your scripts that connect to the events will need to be local scripts,.
We did not want to make changes to ClickDetectors when creating DragDetectors.
But I think that what you want has demos in “DragDetector TestWorld 2,” which has 3 new button styles you can’t do with ClickDetectors.
If you set the DragDetector.ResponseStyle to Custom, then the object won’t move unless you write a response in your dragStart/dragContinue/dragEnd events.
But now you know when the mouse goes down and up, and you won’t lose focus if you take the cursor off the object (which happens with ClickDetectors).
So! You can make buttons that look different when clicked (by changing geometry/materials during dragStart and dragEnd).
And you can make them take action while the mouse is pressed instead of when it is release, if you prefer.
Is there any large performance drawback to using the method you mentioned? I already made my own system that just uses RemoteEvents and UserInputService to detect mouse down and up events, and I dont know if I should migrate to this method.
Are there any properties that can be used to determine how fast a player is moving a DragDetector? I think these could be used to adjust the volume of a sound effect linearly to possibly provide some sort of additional feedback, such as a player opening an office drawer and having it play a sound or something of that nature (similar to levers in SCP: Containment Breach).
There should not be a large performance drawback because we only send those dragStart/dragContinue/dragEnd events to the server. If you are sending less info, yours may be more efficient.
The big difference may be in lag. If you do your moves locally and send changes with remoteEvents, you get immediate response. But with DragDetectors, you send events to the server and it sends the results back to you.
But if you set DragDetector.RunLocally to true, and then use your same remoteEvents, performance should be nearly identical. So then it becomes a question of whether the DragDetectors give you options above what you have in your own system.