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.
15 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.
2 Likes
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.
2 Likes
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!