@razorter by the way @DeFactoCepti has check in a fix for this enabled issue. It should go live in about 2 weeks. ‘enabled’ will be checked when the drag is attempted, not just when the client sends the signal; so your timing issue should go away.
If ContextActionService is getting you the information you need, then I think you are in luck.
If you are using BindAction, then your action handler can return the value
Enum.ContextActionResult.Pass.
This will make it so that your handler doesn’t “claim” the event for its own use, and the events should continue on to the DragDetector.
By default, if you don’t return a value, then it assumes you want ContextActionResult.Sink which prevents others from using it after you
I’m trying this out, the part won’t even accept that I’m clicking on it. Either my place is cursed with the fact I can’t use drag detectors or it’s just very buggy.
@PolyHall It’s unlikely that DragDetectors are very buggy because we’ve got many successful creators and players happily using them.
You’ve probably got a plugin installed that’s stealing your events.
Start simple. Just add a part with a dragdetector below it and click play. If this doesn’t work in studio, but it works when you publish your game, it’s almost certainly a plugin. Disable them all and see if things improve.
If you still have an issue, check if there is anything in your output window when you hit play and report back.
And if the simple demo works, but not your game, then your game may not be cursed, but you may be binding actions with ContextActionService that are stealing the mouse events. Try returning Enum.ContextActionResult.Pass from any actions bound to the mouse and see whether that lets them fall through to the DragDetectors.
Please let us know how it goes.
@PrinceTybalt Why is this happening to me? Is there anyway to make it smoother? https://youtu.be/XNfZh0SwwlI Edit: How do i make this so it doesnt go very far I want it to stay in front of the player.
@xxoof_oofoofxxALT I assume its the jumpy-jittery up-and-downiness that bothers you? It’s hard to tell without seeing the contents of the scene. It might be colliding against the wall or something in an odd way? Or it might be this issue. If you share an rbx file that shows the effect, I will take a look.
As for “How do i make this so it doesnt go very far I want it to stay in front of the player.”
there are two things to consider:
First, here’s a reply to the main announcement that talks about ways to limit how far you object will go when you drag it in a plane.
Secondly, check out and/or download the Lift and Carry sample world or the Lift and Carry - Physical or Lift and Carry - Geometric models that are described in the main announcement. They move approximately in the style of the Lumber Tycoon dragger.
Dang, didn’t think any of my old code was still usable. Nice.
I originally planned on rewriting everything in TS and putting it on GitHub since it’s a much better workflow, but never got around to doing it. So best option is just my Roblox inventory.
Be wary though, I never intended it to be used in anything too serious. It’s far from optimized (e.g. the neighbor search algorithm is O(n²)
for any given BoidGroup. So use multiple groups whereever possible). Will be the first thing I look into if people actually use it in any serious projects.
Glad you like it though, they’re fun to play around with
It’s great to hear from you. I’ve just used your boids code to play around a little, and yes if you make big groups it does get slow. But it’s so much fun.
I wrote some boids/particle code back in the day when I was working on Shout3D (a java game engine that nobody knows about anymore; we wrote it so that we could deliver 3D graphics without a plugin back when every browser ran java), It was just as inefficient as yours!
I’ve noticed that DragDetectors don’t work if the part is a child of the current active character. Any chance of a fix? Due to quirks with the engine it saves a lot of time if I can do that.
We’ve discussed this before, I think in the main announcement. There is code that specifically prevents this for ClickDetectors, and DragDetectors inherit that behavior. I need to make sure there’s not a good reason for this before changing it.
Wow this worked first try without anything, it even stopped me from shooting my weapon when dragging.
Just wondering if there’s a way to force a player to begin dragging an object?
Can you describe more fully what you are hoping to do?
What might be the sequence of events?
I want to be able to call a method on a DragDetector using a player as a parameter that would cause the player to begin dragging the model, whether they are holding down their mouse or not
This is not something you can do.
How would you know where to move the object without mouse rays? Are you saying you want them to start tracking the mouse without pressing it, and then stop at a particular time?
I want to be able to call a method on the client to basically simulate clicking an object, then it will trace the mouse whether the client is holding down left click or not
Decided to try out DragDetectors. Have to say that the amount of thought and polish that went into them is very much appreciated. Very well done, love the feature.
There’s some issues with that, like how would it work cross platform (e.g. mobile and VR)
This would be useful for making building tools.
DragDetectors are built to work on mobile and VR. On mobile, you can drag a DragDetector with touch; in VR you can use the virtual laser. They should behave the same as with keyboard and mouse.
The exception is the DragStyle “BestForDevice”: this used TranslatePlaneOrLine with keyboard and mouse; TranslatePlane for mobile; and for VR it does 6DOF motion at the end of the laser