Physics test level.rbxl (95.1 KB)
Open Studio.
I’m pretty sure that the buildings are not joined to the baseplate because when I play this game and someone hits a building with a rocket, sometimes I go flying to infinity.
This building is one of our oldest models and this used to work.
I am not able to repro this
Does this happen with all plugins and beta features disabled?
It works fine for me.
I have the Lua dragger enabled, by the way.
The only beta feature I have on is the one that stops Studio from killing itself to update. I definitely don’t get the white lines on the building like you do. It doesn’t show it in the video, but I also just tried the other building in case it’s only one of them (they are clones). I also tried dragging the one building on top of the other (doesn’t create joints).
It looks like this only happens when the “Drag multiple parts as single part” setting is off. With that setting disabled, I am able to repro the issue.
This is expected behavior with “Drag multiple parts as single part” off. If the model has been slightly rotated by being hit with a rocket or something, it is not flush with the ground anymore. When that setting is off, models are not rotated when being dragged, so it will not rotate back into a position where it is flush with the ground and can join with it.
The resolution is to turn on “Drag multiple parts as single part”. If you have an issue with that setting, you should bring it up now, because the Lua Draggers landing soon effectively always have that behavior.
Wait wait wait.
You are telling me I need to twiddle a secret setting to make model snapping work?
And that the setting defaults to off?
And this is known?
Is that right?
As far as I know, my building is axis-aligned-ortho-oriented, but even if it’s not, I want it to snap to the base plate IF I HAVE TOGGLED THE SETTING (JOIN SURFACES TOGGLE) THAT SAYS SNAP THIS TO THE BASE PLATE.
This is a huge deal. Dragging single parts is fairly rare. The only things I ever want to join are models. Models to base plates, models to other models, models to terrain (I’m afraid to even try it). This is the one thing in Studio that needs to just work.
The absolute worst thing it can do is silently fail, not join my models, and I only find out at runtime because physics performance is terrible in my game.
I don’t know what “drag models as a single part” is, or where that setting is. If I have an issue with that setting, it’s that I have to know about it. I think the problem is that there is a setting. Roblox should figure out when it can treat a model as a convex hull for dragger registration and when it can’t. Or maybe I grab a giant model and dragging it is slow, so it toggles “fast drag” mode with reduced collision fidelity (in a way that is obvious to the end user). Or maybe dragging is parallelized so it can use all 32 cores on my machine instead of one. Dragging should get closer to the metal, not further away.
At the very least, it sounds like there needs to be a release that changes the default. But it also sounds like we might lose generic concave/concave model snapping when we ship the Lua-based dragger, if it requires “drag models as a single part” to be on. I think Roblox has to aim for feature parity before shipping a new implementation of such a core piece of Studio functionality.
My 2c
This really bothered me so I spent some time trying to figure out if there is something unique about my building model. I inserted the first handful of models that appear in the tool box and found that, no, this seems to be a common issue. I tried 7-8 models and 2 don’t join to the baseplate when you drag them. In the attached file the bunker and the barrel don’t join either, even if you make the baseplate a weld surface.
Also the tower joins if you angle it 3-5 degrees, but not more than that. But it joins crooked. I don’t think this is how the dragger used to work. It used to align the model with the surface you were dragging over. I think the new behavior is worse.
This tower is joined to the baseplate
Bad Joins.rbxl (217.1 KB)
Also there are problems dragging models on terrain. The join indicator flashes on/off as I move drag around on the terrain. Also the white “we are joined now” indicator lines are absent.
For terrain I think we need different dragger logic that tries to “sink” the model into the terrain by a reasonable amount and minimize the gaps between the model and the terrain. If I drag over the side of a cliff, I probably still want the model to orient consistent to the slope of the ground. Probably hard.
even if you make the baseplate a weld surface.
FYI surface types (other than Hinge / Motor) literally don’t do anything anymore. You can have two completely smooth parts and they’ll join just the same as anything else.
And that the setting defaults to off?
I think part of the reason that setting wasn’t turned on by default is because it was broken for a long time with a subtle and hard to fix bug, from 2017 up until a few months ago when I fixed it. During that interval it would not correctly position things when dragging onto surface a surface of an object with a non-identity CFrame.
It should have been fixed much sooner, but I’m guessing given how obscure the feature is, the intersection between people who knew about how useful it could be and people who had the power to budget time for fixing it was empty.
Also the tower joins if you angle it 3-5 degrees, but not more than that. But it joins crooked. I don’t think this is how the dragger used to work.
This is also part of the reason the setting wasn’t turned on by default. The behavior of drag multiple parts as single part is a lot more detailed than the never-rotate-any-model behavior that’s the default right now. That model has rotated primary part set, so, when you drag it it will try to snap that rotated primary part’s orientation to the snap-to target.
Also there are problems dragging models on terrain.
The behavior for that is a mess because nobody properly updated the draggers to work with Terrain, they just have band-aid code which ended up being the production code. The new Lua Draggers have better code for dragging onto terrain. Though still not quite as “magic” as you’re thinking.
At the very least, it sounds like there needs to be a release that changes the default.
The reason we haven’t looked at doing this is because it’s a significant change which we don’t want to spend work on when the Lua Draggers release which will make it obsolete is coming so soon.
But it also sounds like we might lose generic concave/concave model snapping when we ship the Lua-based dragger, if it requires “drag models as a single part” to be on. I think Roblox has to aim for feature parity before shipping a new implementation of such a core piece of Studio functionality.
Please elaborate on exactly what missing behavior you’re worried about? I don’t follow what you mean by “generic concave/concave model snapping”.
Hi, I’m the PM who owns modeling. Let me jump in here and try to clarify both in terms of what’s happening and what you’d expect to happen 
(Other Roblox staff can let me know if I’m incorrect at all.)
Join surfaces joins things that are parallel, not things that are touching. There’s some tolerance, so the 3° you alluded to gets joined.
When you freeform drag parts (don’t use the axis handles) with the current draggers, there’s some magic alignment that happens. That is making things parallel, which–if you have Join Surfaces enabled–produces a side effect of making the surfaces join.
When you freeform drag a model with the current draggers, that magic alignment doesn’t happen. If you enable that “Drag multiple parts as single part” (hidden) setting, then the magic alignment happens, producing the side effect of making the model parallel and joining the surface. There’s also limited visual affordance that the thing you moved did not get joined.
In our new Lua draggers–which will be out of beta soon–we are simplifying this situation. The “Drag multiple parts as a single part” option is going away. Whether you freeform drag a part or a model, the “magic alignment” will happen so things will join as expected, no hidden setting needed–it just works.
Is that the behavior you expect, Shedletsky, or is your expectation that if Join Surfaces is enabled, things get joined if they’re touching regardless as to if they’re parallel (which is also valid and arguably a more stable solution)? Or is it that you want clearer visual affordance as to if the join succeeds/fails?
Thanks!
It turns out there is actually some kind of regression with Join Surfaces when the drag multiple parts as single part option is not turned on. Sorry for not investigating in enough detail to find this earlier.
I found a clear repro for the problem, and the issue is now being investigated.
In Roblox joints (at least welds, not sure about the new prismatic sliders etc) don’t have a 3D position. They have an implicit position based on the two parts they connect.
The thing I don’t like about the tower snapping at a 3 degree angle with space inbetween, is that, as a player, I have no idea where the joint is. Basically, where do I hit the tower to knock it over?
That’s sort of a theoretical problem. I could see instances where, as a builder, I would like to create joints between parts that are close-ish and aligned-ish. And, as an engineering matter, there’s always going to be some slop due to floating point math. I think “magic” alignment is the better default though, because most of the parts in Roblox are boxes. It’s also more physically intuitive.
The dire problem is that such a high percentage of the UGC models I pulled from the toolbox failed to weld to the baseplate, even though as a user I thought I had the right toggle set.
If I imagine a test case where I randomly select a model and randomly select a location on my map to drag it to, I feel like this should work 1000 out of 1000 times. I would guess that at the moment we are around 80%, and this is lower than the historic average.
I think it’s important that this case continue to work out of the box without any settings changes:
If “drag as part” supports this, then it’s fine. If “part” means model bounding box, then it’s a problem.
Drag multiple parts as single part with the legacy draggers does not support this (yet another reason to not turn it on by default), but the Lua Draggers do support this (in that they do not enforce collisions at all when freeform dragging, so the part you drag will always be placed exactly onto the surface you drag it onto regardless of other intersections).
If I imagine a test case where I randomly select a model and randomly select a location on my map to drag it to, I feel like this should work 1000 out of 1000 times.
You’ll be glad to know that this is exactly the mantra I took when designing the Lua draggers, they’re designed for maximum predictability (being able to predict exactly what will happen when you do a given drag) over any other factor.
I think this is an excellent design principle and something the current dragger doesn’t always nail, as you can see in the gif I just posted where I briefly struggle to put the T part where I want.
So to summarize my current understanding, this is the resolution:
John’s building model from the top post and the others he found in the toolbox that don’t join to the baseplate with the current Studio dragger is a big problem. However, we are fixing it by shipping the Lua draggers soon, which drag these models just fine and with no loss of other pre-existing functionality.
If so, that sounds good.
Yes, this is accurate.
I might also add that “soon” actually means soon in this case, as in, they should be enabled for everyone by default sometime in mid to late June.
