The default snap increment for the dragger object is 1. The pizza place furniture is along the same grid as terrain blocks. If SnapIncrement was a property, I would use the dragger in my game to place furniture in houses. Examples:
Dragger.SnapIncrement = 4
Dragger.SnapIncrement = 1/5
Dragger.SnapIncrement = 1/16
Dragger.SnapIncrement = 1/1000 --turn grid off
This dragger instance is nice, because it calculates local surface grids perfectly, out of the box. Even on very strangely rotated surfaces, and with grabbed objects that have weird sizes (like 0.05, 1.3, 4). It simply keeps dragged objects aligned as expected for players in-game.
It’s just missing:
The 2nd gif with the TextLabel is custom code (no Dragger instance) going through parts (intended) with a custom increment (0.5), but not aligning properly. I’d like the best of both worlds!
@tnavarts you worked on some draggers; what do you think? Two simple* tweaks! I think this would help devs easily implement drag tools with no fuss. (The recent beta DragDetectors are cool but I haven’t been able to replicate this Dragger instance behavior exactly. And ripping apart F3x tools is not what I have in mind for suggesting draggers to creators!)
*This may or may not be simple; I don’t know the codebase haha
There’s no way we’re updating the Dragger Instance further, rather it will likely be removed at some point if we can get the few consumers of it moved over to Lua code from the Studio draggers which implement even better mechanics.
There’s almost 10,000 lines of legacy C++ code which previously drove the old pre-2020 Studio draggers which only continue to exist because the Dragger Instance directly or indirectly depends on them. Being able to remove all that stuff would be really valuable.
The only blocker is packing up the Studio dragger code with an easily usable interface.
Isn’t the new dragger instance replacement for this? I forgot what it was called
Yes, the drag detectors.
I wouldn’t call it a replacement.
The Dragger Instance’s primary purpose is in game content creation. The DragDetector’s primary purpose is easily adding interactivity to a place. They have some overlap but the APIs are designed with different intent.
The Lua code from the Studio draggers could serve as a direct replacement for the Dragger Instance.
Cool insight! Thank you for the response. Legacy code 
I look forward to more updates relating to this! Dragging behavior has been a blocker in my own game for a while now.
Is there a place we can find the studio dragger code to make our own?
I posted it as a zip here, though you should expect it to take at least a day of work to get it into a usable state and it’s fairly complex code because it’s designed to support full Selection management + editing Gizmo mechanics.
Well, I managed to make an ugly hack around the issue of the dragger instance getting stuck on objects (like a pebble stopping a character from moving over it.) Thought you’d get a kick out of this:
Is there really a zero percent chance of just an increment being added to this legacy code? What if it were… non-zero? 
Unfortunately it’s indeed zero percent.
This is just not the kind of thing that we build into the engine, philosophically we ship features like this as Lua code built on top of the engine now, not dedicated Instances / methods.
“What about the DragDetectors?” you ask.
It’s about shipping reusable building blocks vs opinionated workflows. The Dragger Instance presents a very specific opinionated editing workflow (snap bounding box to surface normal, actually a rather uncommon workflow in DCC tools). Unless you’re happy with exactly what it does you’re out of luck, vs if we presented that as a Lua library you could adjust it. The DragDetectors on the other hand present a general unopinionated lower level building block for interactivity.
There’s nothing opinionated about rotating something around an axis or moving it along a line segment, anyone trying to build interactivity will inevitably need those primitives, which is why the DragDetector deserves to exist.
It’s legacy code, but it was infinitely better than the studio draggers we have now, which have always gotten in the way and take tolls on performance.
Based on the previous replies, it makes me feel like draggers are one of those legacy objects that doesn’t have a direct replacement (like VehicleSeat or Glue). We can code that functionality ourselves, so why waste time using this system when we could make our own customizable one and preferably post it in #resources:community-resources?