A suggestion i’d have is to add a Behavior functionality to the UiDragDetectors that will allow the player to click in any position that the UiDragDetector’s DragSpace is defined to, moving the drag detector object to this location
Black Box = DragSpace (The bounding box for the dragger)
Red Dots = Example places of where the player could click inside of the DragSpace without having to first grab the drag detector itself
White Dot = Starting point of the DragDetector
Basically what I mean is if the player clicks anywhere inside of the DragSpace defined within the UiDragDetector while this property is set to true, the drag detector will snap to this location, this would be a VERY nice addition imo.
Also allowing for the movement of the drag detectors from one location to another to be scripted would be nice, as this would allow for smoother animations.
(If this is already possible please let me know, I have been toying with the drag detectors and programming stuff with them for a few hours now and this does not seem possible at the moment)
This makes sliders so much easier to make! Can’t wait to experiment with this. Although there are some issues I noticed with the mobile interface, certain cases it’s impossible to select the GUI.
This absolutely does not work with objects put inside other GUI objects with UIListLayout, UIPageLayouts, and UIGridLayouts. I believe it would be a benefit to also enable this feature for those objects. As of now, people would have to use a hacky fix of parenting cells inside and outside of the said container to move the object.
The last issue you mention is interesting-- I’ll keep an eye out for that.
For the indicator appearing in the wrong area / being stuck, and needing to re-join the game, those are known issues and we are hoping to have a fix out by next Thursday.
More specifically, the indicator not going away / needing to re-join the game happens with UIDragDetectors on SurfaceGuis when you drag it outside the SurfaceGui area. It doesn’t terminate properly, and causes these issues. It is actively being worked on and should be resolved in the near future!
You would need to implement some custom input detection that triggers a change in the UIDragDetector’s DragUDim2 property to do the first behavior yourself, if I understood correctly. It doesn’t seem too trivial of a thing either, especially if the UIDragDetector is in a different DragSpace.
To drag a UIDragDetector with script only though, should be possible by simply setting the DragUDim2 property to a value you desire-- either a translation if there is no ReferenceUIInstance set, or a relative position to the ReferenceUIInstance if you do have it set.
Ex: If you wanted to move something from (0, 0) to (100, 100) in 50 frames, you could set the DragUDim2 to UDim2.fromOffset(2, 2) every frame for 50 frames. You’ll need to set it to UDim2.new() before/after setting it to (2, 2) as not changing the property doesn’t trigger the dragging behavior, but this would essentially move it by (2, 2) every single time you set it. This would be how you’d do it without a ReferenceUIInstance.
If that’s not what you were trying to do, please clarify and I can reply again!
What constraints would make dragging with UIDragDetectors more complicated? We’d like to know where we can improve this feature on. (Your previous reply was for Layouts-- we currently do lack support for them but it’s definitely on the to-do list)
What’s the current timeline for full client release? I’ve got an update that I need to get out within the next week or two that could use this if the release timeline is quick enough.
