Just set the CFrame of the part before you create the weld :uhhh:[/quote]
And when I go to manipulate the C0/C1 after setting the initial CFrame and the complete opposite of the one I wanted to move is moved?
All you have to do is attach a bigger part to the C0/C1 that you want to stay still.
This issue has also hurt me today. I don’t get why it goes to the “larger one”. That doesn’t make any sense.
Current System: You can’t specify
I’d Prefer: You specify
Changing this would really help 
2 Likes
In a non-emotionally charged statement:
the expected behavior is that Part0 is always the root part. Regardless of the size or anchored state of either part in a joint, Part1 moves to Part1’s space.
1 Like
The general issue is that the Motor instance doesn’t work the way we’d expect. I’d also like this to be changed. Welding larger parts isn’t always an option.
Here’s a topic I posted about the same issue 8 months ago: http://developer.roblox.com/forum/development-discussion/8305-motor-is-rotating-the-wrong-part-solved
So yeah, please fix.
ROBLOX pls. This is ridiculous. I just tried to attach a large part to the top of a smaller part but the smaller part ended up getting attached to the larger part instead, even though the smaller part was Part0.
Repro file: Repro.rbxl (10.9 KB)
Run this bit of code in the command bar and watch A (Part0) move relative to B (Part1) instead of the proper, other way around:
w = Instance.new("Weld", a); w.Part0 = a; w.Part1 = b; w.C0 = CFrame.new(0,2,0)
Related quotes from other threads regarding this weld behavior:
I don’t know if @CodeWriter didn’t see the replies to his post here, but it’s pretty clear this bad behavior needs to go.
1 Like
What behavior is expected when they have equal masses? it just doesn’t make sense >_>
Right now, if you have an assembly where 1 large part is connected to 10 smaller parts that sum up to a greater mass, the 10 smaller parts will get rotated, even though it’s heavier. Either the motor should take into account the total mass of the two assemblies and rotate the smaller one around the larger one, or it should always rotate Part1 around Part0.
That first option is not good for a game engine imo. I’m not making a physics toy, I’m making a machine that I want to work in the context of my game regardless of how its weight is actually distributed between invisible floating motors.
1 Like
Then in that case it should take into account the moment of inertia of the two assemblies and rotate them around each other based on that.
EDIT: Also, I did suggest having Part1 always rotate around Part0.
I meant if you have 2 parts with equal properties attached with a single weld, which one should be dominant? It becomes ambiguous
Part0. That’s the most logical choice I think. Even when they have different masses as a game developer I want a switch that I can control, it’s annoying to fiddle with part sizes to get something to work the way you want.
4 Likes
When I initially set up the joints for a fishing rod, the line coming from the tip of the rod to the bobber is about as long as the rod but thinner, so the rod has more volume and it gets put together properly:
When I go fishing, that line extends:
If I try to update the rod again (e.g. to cancel fishing and return it to its normal state), now the fishing line is longer and even though thinner it has more volume than part of the rod, so this happens:
Thanks ObamaROBLOX! Has it become apparently obvious why you shouldn’t make joint behavior arbitrary yet? Part0 should always be the root and Part1 should always be the subpart. Fix now pls.
5 Likes
This didn’t fix the problem. Can Part0 be the rootpart always and Part1 be the subpart? Strangely however, even though the current weld behavior (as of August 2016) is theoretically wrong and should output very glitchy-looking weld animations, it seemingly doesn’t. I still want it changed, though. (it works but is theoretically wrong, which is like supporting a working, yet deprecated feature, dangerous)
1 Like
Character was created with Animation Editor. Motor’s Part0 is Torso and Part1 is the part on the ground. Floating transparent part is HumanoidRootPart.
Code used to create motor:
p0 = game.Selection:Get()[1]; p1 = game.Selection:Get()[2]; m = Instance.new("Motor"); m.Part0 = p0; m.Part1 = p1; m.Parent = p0
This is getting pretty absurd. Why is Part0 moving to Part1? Especially when it’s already attached to another part. Fix pls.
We’ve reported this issue starting almost two years ago. Is there a reason this hasn’t been fixed yet? Can we get a staff response on this issue? Anything?
4 Likes
I make weld animations knowing that welds are badly set up like this, and the weld animations surprisingly don’t come out wonky. However I still wouldn’t let this current weld logic slide, it’s like promoting use of a deprecated entity, so yeah it would be nice if the logic was changed.
hi please fix ty
Since we don’t have this documented anywhere, I’ll explain real quick.
The Truth About Welds
Weld, Snap, WeldConstraint, Motor, and Motor6D joints all combine multiple parts into the same Assembly. An assembly is a rigid body if none of it’s parts are anchored. No physical forces can ever separate the parts of an Assembly or move them relative to each other unless the joints are removed or updated. They’re a single body.
Every Assembly has a root part, see BasePart:GetRootPart. When a weld is C0/C1 is modified the root part will stay where it was.
Welds do not have any directionality. Part0 or Part1, doesn’t matter. You can imagine rigid joints forming a tree branching down from the root part. All the parts down the tree from root will move, and their welded “children” in this tree will move with them.
The root part is picked based on the surface area of the largest face of a part’s object aligned bounding box (defined by Size). A Humanoid’s HumanoidRootPart has a 10x multiplier and a Seat has a 20x multiplier. All else being equal it will sort based on the replicated internal ID of the part. Root selection is deterministic and has to be because we rely on it for physics replication, but externally it’s effectively random. Basically it’s impossible for you to determine which part will be root ahead of time. Yes, root selection is… odd.
A typical Roblox avatar is a single assembly. Here’s a visualization of this tree in a basic R15 humanoid rig on the left, and a representation of this implicit tree of which parts move relative to which parts on the right.
It’s actually been this way forever. Coincidences and occasional bugs have make this behavior hard to intuit.
Caution!!!
You should avoid relying on a particular part being root and generally try to write code that works agnostic of this. For example: the newer WeldConstraint avoids this by forcing you to position the two parts correctly how you want relative to each other, and just locks that relative orientation in as soon as it is enabled. It doesn’t matter which part is root. You move the parts how you want to and we make sure it stays that way.
You should avoid relying on specifics of this implementation where possible. We’re not completely satisfied with this system, but it’s very risky to change it. Last time we tried to increase the root weight multiplier for HumanoidRootPart several popular games broke. We do have plans to rewrite some of these systems in the future to clean some of this up and allow for more control, but we plan these changes cautiously and try very hard to minimize breaking changes.
I hope this helps understand and work with it in the meantime.
14 Likes
Can’t their be 2 api functions for the root rotate part, the current one that stays the same and a new one like motor2 or something that has the changes?