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.
Absolutely love how customisable this API is however I have found one-flaw. There appears to be no way to ensure a part is not placed inside another part (so that it is no longer accessible) without custom writing all of that code manually - which is not ideal especially when it seems like such a regularly needed mechanic, for example:
The DragDetector.DragFrame updates to tell you where the object’s pivot is relative to the referenceInstance. So if you set your referenceInstance to something that is not moving, then the DragFrame.,Position will tell you where the pivot is relative to that referenceFrame. In your dragStart/dragContinue callbacks you can measure the change in the DragFrame.Position to get the velocity of motion.
Check out the ParticleSlider examples in “DragDetectors TestWorld 2”. They look at the DragFrame and update Sparkle system strength based on the DragFrame.Position (though not its velocity).
I’m not sure exactly what you are doing, but here are some things that may help:
[1] parts that are not anchored, moving with DragDetector.ResponseStyle = Physical should not go through other objects when you drag them.
[2a] if the part is anchored, you can set your MinDragTranslation and MaxDragTrange., If you do this, it’s important to set the referenceInstance to something fixed to measure against. Terrain is fine if you want to measure this in worldspace.
[2b] If a simple box does not meet your needs, then you will need to write some code. You will need to register a constraint function, which takes as input the desired motion and lets you return an output that is a motion to use instead. Examples of constraint functions are in both “DragDetector TestWorld 1” and “DragDetector TestWorld 2”. That method will have to do whatever calculattions are needed for your specific situation.
Very interesting feature, however right now i am noticing that the drag detectors seem to be running at half my framerate? It’s not entirely a gigantic issue but its 100% something you will notice.
My part is anchored so option 1 unfortunately does not solve my use-case. I understand that this is possible via code although having draggable objects that cannot go through other objects is a common mechanic in Roblox games and it feels “wrong” to have so many useful properties to make the instance user-friendly and proceed to not have one to block anchored parts from going right inside other objects only to be unrecoverable by a player, having developers forced to write this code doesn’t appear to match the user-friendly approach this instance appears to want to achieve especially when such behaviour tends to be commonly used in games.
This occurs if RunLocally is set to false, likely due to the server overriding your edits to the object’s position (network-ownership not set / can’t be set on anchored objects, etc?)
