Sorry, I was not clear about what will change with the new constraint API.
The ONLY things that will break are that if you have a script that calls DragDetector:AddConstraintFunction or DragDetector:RemoveConstraintFunction.
EVERYTHING else will continue to work in all scripts.
For those curious, the upcoming change is just to simplify the calls. You won’t have to name your function. So instead of:
OLD:
dragDetector:AddConstraintFunction(1, “MyFunction”, function()
– some code
end)
dragDetector:RemoveConstraintFunction(“MyFunction”)
NEW
local connection = dragDetector:AddConstraintFunction(1, function()
– some code
end)
connection:Disconnect()
As for your other comments:
On mobile, dragging should not move the camera when you click and drag a dragDetector. It should only move the camera if you click and drag an area off the DragDetector, or if you use the thumbstick.
If you have a different result, can you post a video somehow? or very clearly describe what you are doing and what you see?
As for the form…I don’t know how we made it so that you must select things! @Urukeli made it so I need to let him answer your question.
On mobile camera should not move if drag detector is activated.
Character would move, but camera should gets disabled by dragging in test place. I just tried on TestWorld 1
P.S. @foodeggs7 Google form - you can Click three vertical dots near Required switch in the bottom of the question and select “Answer Validation”.
I also tried Test World 1 on my phone and it worked as expected, So @foodeggs7 if you are getting simultaneous drags and camera moves please give us some details: type of device, whether you are in first person mode, which demo you are dragging, where you are clicking on screen, etc. And if you can do it, a video showing the incorrect behavior?
I tested it but i think I’m not picking up the drag detectors because the sun was into my screen shining so I’m not picked up it correct but i tested it again and it work
I activated DragDetectors for submitted places. If it doesn’t work for you place please reply here. We also added a verification step to the form to avoid misunderstandings.
@YasuYoshida , thanks again for this great feedback and information.
I’ve had a chance to look through all of it and here’s the result:
Mysterious DragStyleFunction Parameter
Oops! We documented how to add/remove/set functions but did not document the arguments to those functions! I will update the documentation and post here when it’s fixed.
For now:
constraint functions have:
1 input: CFrame proposedMotionInReferenceFrame (the motion that would be applied to the pivot relative to the referenceFrame if you didn’t constrain)
output: CFrame newMotionInReferenceFrame (the motion that should be used instead)
customDragStyleFunctions have:
1 input: the cursorRay in worldspace. It’s a ray from the viewpoint in the direction of the cursor.
1 output: CFrame desiredWorldspaceCFrame (the desired orientation and position for your object)
if you haven’t found it yet, there are examples of using the cursor in the customDragStyle in “DragDetectors Test World 1” and “DragDetectors Test World 2”: search for “followTheCursor” in the scripts
Missing AlignOrientation for Scriptable DragStyle
You are correct! Great find; we will fix. It’s also the case for 6DOF in VR (which you get with “BestForDevice” with VR input)
Stuttering with Geometric Dragging in First Person
I don’t think this is a mismatch between dragger and camera; if so, then when you stop moving the camera, the object would not return to the same place relative to the cursor; it would be out of register. I’ve seen that before. Rather, I think the issue is that rendering and camera moves happen at a faster rate than the drag/UI events. For every few frames rendered, there may be only one drag. So when you move the camera while you’re dragging, you get the same effect whether you runLocally or not. The blue box in this video is running on server with no scripts. The red box uses your script. The stuttering occurs for both whether you are running or turning your head. I’m not sure there’s much to do about this unless we could do some kind of automatic rendering interpolation. This would be an extra project for later but I’ll make a note of it.
Unexpected Positioning
This demo looks different from what you have above because the camera is not moving so you’ve got motion but not first person. Anyhow, I made something similar that also showed what is probably the same bug. The good news is, there is a fix for the bug I am seeing that should go live late next week. When it does, I’ll ask you to test this. If the problem is still there I will ask you perhaps for your world file (or send it today if you want me to confirm now).
Constraints Remaining after Dying
A change that is coming next week will make it so that you will not see added Attachment and Constraint objects in the data model. The behavior will be the same except we are using internal APIs so as not to edit the data model in this way just to perform a drag.
Either way, we need to clean up in certain cases. We’re handling when players LEAVE the game, but not when they die! New bug for us to fix. Thanks so much!
I never realized that it wasn’t constantly updating when using a DragDetector. In fact, now that you mention that, I’ve noticed instances where the object doesn’t immediately go to the desired location until it updates. This can look weird in certain scenarios like this one:
As you can see in the video, I start dragging it, but it only slightly moves to an irrelevant location. Once I trigger an update by moving my camera/mouse, then it goes to the correct location.
Unexpected Positioning
It’s actually the same exact setup. I have a ScreenGui in StarterPlayerGui that has a TextButton with ModalEnabled. When I do this, it allows me to freely move my mouse in first person. I can hold the right mouse button down to move my camera with this setup. That’s what the “Stuttering with Geometric Dragging in First Person” video showed. The “Unexpected Positioning” video only used the aspect of moving your mouse in first person and not rotating the camera. I’m not sure if that makes sense. It’s easier to understand if you take a look at the place file below.
Here’s a place file that contains the exact same stuff used in the videos from my previous post:
It also contains the ScreenGui with a ModalEnabled TextButton that I mentioned earlier.
Constraints Remaining after Dying
I really like seeing how the constraints are affecting the object and where the attachments are located when Constraint Details is turned on (that’s what I was using for the Unexpected Positioning video). I hope that aspect of them remain. If not, something like those would definitely be on my list of useful stuff for debugging DragDetectors.
Thanks for the reply. I know it can take quite a bit of time to formulate one.
First, off, regarding the stuttering in Geometric mode:
I talked with some of the engineers and my assumption above. may be incorrect; it’s possible that we can get a better result by coordinating our changes with work we do in a PreRender callback. We will be researching this, although we may tackle it after the other more functional issues are addressed.
As for your your new physics example:
Two things are happening here.
The first is that on mouseDown:
Our general contract is that on mouseDown, the object should not move at all; and if applyToCenterOfMass is true then on mouseDown the centerOfMass will be moved to the cursor.
However, currently there is a bug that often moves the object to a funny spot on mouseDown; I think you were seeing this in your earlier example “UnexpectedPositioning.” A fix for this is coming next week.
The second is that the object does not go in front of the player until the mouse moves. This is because your custom drag style function is only called once you move the mouse; which is correct. If you want it to fly there immediately you will need to take action onMouseDown.
All this is different than the stuttering issue that happens when the camera is changing more often than the dragging occurs.
Unexpected Positioning
Thanks. I played with your world file a bit, and I’m pretty sure that this will behave the way you desire once we have [a] next week’s bug fixes and [b] creation of the AlignOrientation constraint that is currently missing. But we’ll confirm as these changes roll out.
Constraints Remaining after Dying
I understand it’s convenient for debugging, but it is best for us to make as few changes to the data model as possible that are side-effects of dragging, even if only temporary. We are always going to need to change ‘anchored’ between true and false. But we have alternatives to constraints to keep things cleaner.
We can add debug tools to help you inspect or visualize the constraints later.
Thanks for your replies as well. You are giving us information that will help hundreds of people after you have a better and easier time.
@foodeggs7 thank you for being so perseverant!
I looked into this with another engineer, and I can reproduce your problem.
I am sorry it took so long to acknowledge this, but yes, this is a bug.
The problem is that the changes you make to Axis/Orientation/SecondaryAxis/WorldAxis/WorldSecondaryAxis do not propagate to the Team Create server!
We will fix this, and I will post here when it is ready for you (probably a week from next wednesday). But until then, the best thing for you to do is set the axis in a script, as you are doing.
Are you still getting an error in your script? If so please let me know what it is, so I can help you debug it.
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.
