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?)
Thanks Abcreator. When we move anchored objects, we edit their pivot and this does not naturally work with the collision system in-game. So it’s not a natural fit.
And sometimes you DO want to be able to drag things the way they work now.
But of course we want to make you happy so we will look into what it might take to get this behavior to be an option.
Moving the part in the
The first person is doing this, with the default settings of the DragDetector this is what has happened so far.
Expected: In games like Lumber Tycoon where you can drag parts, and lift them up to place them on a sawmill.
Is this a possible bug or is it evident with the default settings, also changing a few settings too didn’t fix it, so is the first person dragging glitchy?
Summary: When you drag in first-person the part goes to somewhere like it got flunged
If you mean ScreenGUi, it’s a great idea, possibly for the future. We’ve thought about it enough to know that there would be several ways to do this; so it would require some thought and design.
When you are in first person view, you both move the camera and drag the object when you press and drag. But even so, all that I say below should be true and hopefully helpful:
By default, the DragStyle is TranslatePlane, and axis (i.e. normal to the dragPlane) is going to be theY axis.
You can change your DragStyle to TranslateViewPlane, and it will always move in the viewplane.
Or if you want to move in a specific different plane, you can set your referenceInstance to be a part, model, or attachment, and set the DragDetector.Axis to be a different value. The plane you drag in will be normal to the Axis of the referenceInstance’s coordinate system.
Also, you just want to lift vertically, you can change DragStyle to TranslateLine and it will move ALONG that Y axis.
Lastly, TranslatePlaneOrLine, or TranslateLineOrPlane, will let you switch between the two using the control key. The key you use may be customzied with DragDetector.KeyboardModeSwitchKey
That would be a property of the part itself. In the property pane you can set custom physical parameters, and that is where you can customize friction.
You can set the MinDragTranslation and MaxDragTranslation. If any dimension has max > min, then motion will be confined within that range. We are hoping that this is enough and we don’t need to add a mmaximum distance.
But this only while dragging; if it’s non-anchored and you fling it, that’s different.
