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?
What if you wanna weld both parts that has different RootParts? We don’t have any way to determine which one here should be welded or any way to determine which one should dominate (Part0 or Part1)
And the behaviour would be like this: (I am currently setting Part1 here)
The example below is like a plane I used a click detector to make it so the player can ride it, and the behaviour I expected is that it should be the plane that should dominate and not the Player.
So if you want to change the relative orientation between two parts welded together with a weld constraint, is the correct method to disable the weld constraint, move the part, then re-enable it? This method works, though it feels quite hacky.
Yes, that’s the intended way to do it. In fact, that’s exactly what the dragger tools in Studio are doing.
1 Like
I found how to solve it.
C0 (Or dominator) has to have bigger mass to control C1
OR
C1 has to be massles.
I’ve got the issue when I was making animation and C1 Part was controlling C0, so i made C1 part massless and it worked fine!
You should use BasePart.RootPriority to guarantee that what you want is the root part. A modern explanation for the selection of the root part exists in the docs.
Assuming the assembly doesn’t have an anchored BasePart, the non-massless BasePart with the highest RootPriority will be chosen as the root part. If there is a tie for the highest root priority, it comes down to sizes and names, which shouldn’t be relied upon.
In the case of a Humanoid, always give the HumanoidRootPart the highest RootPriority of the assembly, and don’t make it massless. This will ensure that it is chosen as the root part, and will thus stay stationary when animations are played.
1 Like
Now I got how does it works. Thank you for the reply.
I tried to search an answer, but didnt find it at all. After sitting for 2-3 hours, I realized that the larger the size (mass) the greater the chance that my animation will play correctly. Your comment has radically changed my situation, it will greatly help me in creating the game. Thank you again!