Your intuitions are correct. If you don’t want it to move then a delta position of (0,0,0) is the natural action to take.
The problem is less on your end and more in the way we are expressing the matrices we are giving and receiving from you; and the order we apply the rotation and translation that are bound into that matrix. I need to decide whether we change some behavior; or add new API. And I won’t be certain until I spend a little time on the problem.
In the interim, I might not try working too much with constraints on rotations and stick with constraining translation drag styles, which should work nicely.
@bigcrazycarboy no, the implementation is in C++.
And the hope was that the API hooks would let you customize things to accomplish what you want.
What are some of the things you’d like to try that are not supported by the DragDetector properties, events, and methods?
I wanted to change it pretty fundamentally in order to see if I could bind its input to the motion of an object in 3d space to make a sort of “spring service” for the motion of objects outside of constraints, as well as possibly work with 2D UI or other things. It would be really cool to create a “goal” brick and use the maxforce to adapt the tendency of a different assembly to try to match that goal cframe. I guess that’s generally just the behavior of a gyro but perhaps if it were implemented in Lua it could be applied to camera coding and other things that a gyro isn’t suited for - not to mention, the level of control you could have over it.
Honestly I just saw this was a pretty complex system and I wanted to see if there were any interesting parts of the code I could rip out and use in other ways. Sometimes I know C++ features are developed with Lua prototypes so I just thought I’d ask. Thanks for being pretty active here and replying so quick.
@bigcrazycarboy I’m not 100% clear on what you mean. But you could put a DragDetector under your anchored “goal” brick to move it where you want. And then have a spring with one attachment on your goal brick, and the other attachment on your assembly. Then you’d be pulling your assembly around by a spring; and you would adjust the spring parameters to get tighter/looser motion. If you look at the marionette example in the Test World 2 I do something similar with ropes instead of springs. The handles are anchored and movable. The rest of the marionette is connected and so you can tug it around by the handles.
Is this the sort of thing you mean? If not, perhaps describe in more detail.
We tried to build a powerful and flexible API, so if there are things you can’t do, we’d like to understand why.
As for DragDetectors that work within 2D UI… it’s high on our list. We hope to make that a feature in the future.
Honestly it is really impressive, you guys did a great job with the API design and it feels extremely powerful and customizable to use - great job!
The only thing I could think to add to the existing API would be the ability to “emulate” drag input from a player. Since we cant actually invoke a real “click” from the player (someone had to get creative to make the original version of the xbox mouse before roblox released it officially), there is no actual way to invoke these draggers to work from a localscript without programming the entire physics behavior of the draggers from scratch. It might actually be very useful to have a DragDetector that is totally disabled for use by a player, but instead receives its movement input from a script. This could be useful in cases where a developer wants to add controller support to the draggers. There isn’t a really good way for roblox to generically add controller support because controllers don’t have a mouse, and other solutions may be intrusive. I did notice that if I hold down the right trigger it sends a “click” but if a developer used a proximity prompt to enter a “drag editor” state, they could interpret the controller signals and send corresponding input to the DragDetector, making a much cleaner implementation.
Regarding driving a DragDetector from scripts:
[1] If the parts effected by the DragDetector are anchored, you can edit the DragDetector’s DragFrame property and the object will move to match it. So this is one way you can drive the motion of the object with a script. This SHOULD work with non-anchored objects (using kinematic constraints in Studio and full physics constraints in game) but it does not; we consider this a bug to be fixed, relatively high on our list (but it won’t be fixed before the new year). This would allow you to move the object using physics via a script, and you could direct it exactly where you want to go.
[2] If you wanted to simulate the click-drag-release behavior via a script, how would you express the drag? Via calculating mouse events of a simulated mouse? That sounds hard, and we haven’t yet come up with a way to do this that would feel nice.
[3] So instead, if you wanted a proximity sensor to move a DragDetector, what if you had the key actions edit the DragFrame? For example, you could have a leftArrow button that edits the DragFrame, in increments per press, to move in the direction you consider ‘left’ ; and a rightArrow button to move it right. Or you could use four arrows to move in 4 directions within a plane. this is something you can try right now with anchored objects; and you’ll need to wait for #1 to do this for non-anchored. Attached is a little demo that moves an anchored part in this way, 1 unit in X, when you press ‘E’, Of course you could do this without DragDetectors by editing the Cframe/pivot; so this will all only really be new/different when we fix #1 above. But it gets across the concept. ProximityPromptDrivingDragDetector.rbxl (56.5 KB)
Is it possible to make a function where if you drag on a part, it gives you another part and its automatically drag that item instead of the previous one you dragged?
@anewnameealt look at the demos in DragDetector TestWorld 2 number 22 “Drag Rectangles To Create Anchored Blocks”. and #23 “Drag Rectangles To create unanchored Blocks”
This demos let you sweep out new objects to build little graybox models or sculptures.
These put a dragdetector under the purple base rectangle, and set the DragDetector.ResponseStyle to Enum.DragDetectorResponseStyle.Custom.
When you do this, the dragdetector will not move that object, but it will still update the DragFrame.
On dragStart, these demos create a new part and place it at the location where you clicked. On DragContinue, they update the location and size to ‘drag out’ a new object. And on DragEnd, they close things out.
Note that the new part is put in the same model as the purple background, so now you can click on the new object too to create things on top of that.
I think you can probably start with this and use a variation of it to get what you want.
Give it a try and if you run into trouble, write back.
I’m moving from my current drag system which used Raycast and Attachment, Align Position, quite Similar to this system
But the catch’s. On the old system, I have a feature when the mouse is hovering above the object
I add some highlight
I think you have already scripted this behavior which when your mouse is hovering above the object, mouse Icon would change. So It would be nice if developers could access that too.
Hovering Event:
Yes
No
0voters
I can script the highlight on my own but, having a hovering event would be more clean,
Thank you.
@MrVietChopsticks Ha! Here at Roblox HQ we miss NOTHING!
DragDetector inherits MouseHoverEnter and MouseHoverLeave signals from ClickDetector.
If you go to the API documentation, it’s listed under Events->Inherited from ClickDetector. But perhaps we should mention it in the user guide page.
The model I used is linked just below the video.
I added a short example that shows how you can use a DragDetector with runLocally set to true on an unanchored part. To do this you need a client script that requests network ownership via a RemoteEvent, and a server event that grants it.
Here’s the model: RunLocallDragDetectorWithPhysics Model
Here’s a world containing it: RunLocallyDragDetectorWithPhysics Game
Hello,
A few day ago I found out about this opensource DragSystem
And it’s great and better than my system which just use center point, here’s a video of the opensource system:
I noticed It approach dragging with Attachment0 set To the clickedPosition, and Attachment1 set To the wanted Position which is same as your approach:
The only different is the Opensource one have dragLimit
So during the process of translating that system to be compatible with DragDetector
I realise the :SetDragStyleFunction(function(cursorRay) Is actually using default position which set to the center, rather than using the ClickedPosition as Attachment0:
You can clearly see: WhitePart(with drag detector no adjustment) Yellow Part (Drag detector with :SetDragStyleFunction)
The white Part approach the mouse Position with the Hit point marked by attachment
The Yellow Part approach the targetPosition with the CenterPoint rather than Hit point also marked
Basically Yellow’s Attachment0 is set to Center and white’s Attachment0 is set to the clicked point
So To Summarize I want to keep using The HitPoint as Attachment0 when using the :SetDragStyleFunction rather than using the CenterPoint
I wonder how I can Use ClickedPosition as the pulled point rather than CenterPosition
If I missed out on something, Please correct
If there’s already a way to do this, tell me I would be happy for it
Or maybe you should add feature where Developers can Set the Goal position and the Pull position just like in Align Position
Thank you for Reading! Best Regard
Suggestion
You should Add Attachment0 and Attachment1 To the Option, It would be more customizable and Easier to handle, plus more Flexible than :SetDragStyleFunction
DragDetector:
Align Position:
By Attachment0 I mean the point that being pull
By Attachment1 I mean the point that’s the goal of the pull
Checkout AlignPosition’s Attachment property
Suggestion 1
If it’s possible, You should make a Drag Style which have DragLimit
I’m pretty sure it would far better at making Developer’s life easier,
because in almost all cased we Need A DragSystem which Limit is RelativetoTheCharacter
or even better RelativeToObject which mean It would add more mobility not just limit to being still
You have only implement RelativetoWorld Limit
Regarding a drag limit: we’ve gotten a few requests for this, and it’s totally fair. I’ve got it on our list of things to fix. But since you can limit things using minDragTranslation and maxTranslation, we don’t consider it super urgent. These allow you to establish a box around the referenceInstance that limits how far you can drag the object. If the referenceInstance is not set, that’s equivalent to your RelativeToObject. If you set it to terrain or an object at the origin, that’s like RelativeToWorld. If you set the referenceInstance to be your characters root, that’s your RelativeToCharacter. And you can set referenceInstance to any object you want, so the box can be relative to any object in your world. But you are correct that we could make your lives easier, and I’ll add your API suggestion to our work-item about this task.
Regarding ‘moving from the center’ using the dragStyle function: I worked out an example for this. I’ll clean it up and post it in the next couple of days.
