Correct me if I’m wrong, but there’s no way for a developer to take action when a drag starts. As in, there’s no way for a developer to force the object to move to the correct position acting like the properties of the DragDetector.
Shouldn’t the custom drag style function be ran both when a drag starts and when a drag continues? The current behavior doesn’t seem correct.
That is a good point.
Generally speaking, a drag is relative to a start location and so we don’t expect any change on mouseDown.
But with the scriptable DragStyle (and only for that DragStyle) it’s perfectly reasonable to expect us to call your function on DragStart.
We are going to explore this change.
Now that we know your bug saving the axis is a Team Create replication bug, let’s help you set that axis with a script! In your video it looks like you are still not able to change it.
What errors are you getting when you run the script now?
(Alternatively, for the sliding blocks puzzle, you could leave the axis at (0,1,0) and use TranslatePlane. The side rails might keep things sliding nicely. But I’d prefer to help you do what you really want to do, which is change the axis)
I have a question. probably this has been answered already and I’m just blind, but I seem to have an issue with the distance of how far you can actually use it.
what I mean is that I have set the MaxActivationDistance to 7 and I was able to move quite a distance and still interact with the DragDetector.
Is there a way to cut the interaction if the player goes too far? My guess is that this needs to be scripted.
Very cool feature! Thank you so much for making features that would normally require a script able to be done just as well without a script. One question, is there a property or parameter to the .DragStart or .DragContinue events that is the player dragging said drag detector? If not, how would you do that?
Sorry! I just looked at the documentation for the 4th time and see the parameter for the .DragStart event. Great feature again and I hope to see it added officially soon!
The MaxActivationDistance is a distance used only on to decide whether you can START a drag.
If your player is farther from the DragDetector than this distance, the cursor will not change when you hover, and clicking will not start a drag.
It does not effect how far you can move the object once you start dragging.
You can set the MaxDragTranslation and MinDragTranslation if you want to put limits on where you can drag the object without scripting.
But there’s no notion of “you can only drag this far from where you started”; although you could add a constraint function with AddConstraintFunction that would perform this limiting (which would require scripting).
Others have mentioned this too and we have it on the list of “maybe” suggestions; that’s as far as things are right now.
Congratulations! It took some work but you did it!
And yes, you may copy and use any text, descriptions, models, examples, worlds, or scripts that I put out as PrinceTybalt: this is all for you to help you create things in Roblox.
Fixed issues when click detectors would sometimes register two clicks on mobile (pending iOS/Android app update)
Geometrically dragging a model will now anchor all parts parented by the model being dragged and restore them appropriately when the drag finishes
Disabling drag detectors during a drag will properly fire dragEnd and end the drag
Disabled drag detectors will no longer change the cursor when hovering over it
Scrolling is now no longer captured during drag detector drags, meaning actions like zooming is allowed during drag
Drag detectors have a new icon, along with custom cursors on hover / drag. There is a new property called ActivatedCursorIcon which customizes the cursor during drag.
The dragStyle breaking when dragged too far is an issue that will also be resolved in the next couple days, hopefully before the next release.
I just bound an action using ContextActionService, and one of the input types I precised is Enum.UserInputType.MouseButton1. (It also broke with the Enum.UserInputType.Touch for mobile)
The problem is that now, all my DragDetector instances are no longer working. I was wondering whether or not it was normal (and I guess it is), and how I could try to “bypass” that?
I’ve successfully changed everything to UIS instead of CAS because I’ve heard CAS uses could sometimes break roblox core mechanics (tools, …), I advise you to do the same if you experience the same problems
Hi @Varonex_0 I just saw this.
It looks like you fixed this by using UserInputService instead of ContextActionService.
But you could ALSO do it with ContextActionService.
The trick is that you can return a (nondefault) value from your action handler which indicates that others may process the event after you are done: “Enum.ContextActionResult.Pass”
Here is a sample script. that prints messages on down/up, but still allows the DragDetectors to work:
local ContextActionService = game:GetService("ContextActionService")
local function handleAction(actionName, inputState, inputObject)
if actionName == "MouseFun" then
if inputState == Enum.UserInputState.Begin then
print("Mouse Down!")
elseif inputState == Enum.UserInputState.End then
print("Mouse Up")
end
end
-- This is the default and would prevent events from passing through to DragDetectors
-- return Enum.ContextActionResult.Sink
-- This lets others process the event after this method returns
return Enum.ContextActionResult.Pass
end
ContextActionService:BindAction("MouseFun", handleAction, true,Enum.UserInputType.MouseButton1)
DragDetectors using physics (non-anchored with Physical ResponseStyle) will no longer build instances of Attachment and Constraints that are added to the DataModel; instead we use an internal API so that we do not change add/remove instances to/from the DataModel while dragging.
How would I go about making the part with a DragDetector move with the player past a certain point? AKA if the block is more than 20 studs away it will continue moving with the player.