This behavior broke a plugin of mine. Looks like it just started happening in the last day or so.
Repro: Dropbox - Error - Simplify your life
Click run and the script in the workspace will edit C0. Watch how Part0 moves instead of Part1. Pls fix.
5 Likes
What are you trying to get this to do?
The root part of a motor (The one that doesn’t move) is whichever part is larger, or arbitrary if they’re equal in size.
[quote] What are you trying to get this to do?
The root part of a motor (The one that doesn’t move) is whichever part is larger, or arbitrary if they’re equal in size. [/quote]
By any chance would we be able to change this? I can see a few uses where forcing a certain object to move relative to another using welds would be easier.
1 Like
[quote] What are you trying to get this to do?
The root part of a motor (The one that doesn’t move) is whichever part is larger, or arbitrary if they’re equal in size. [/quote]
Well that doesn’t make much sense. I was always under the impression that Part0 was the root part. Is there any chance that could be changed so that Part0 is the root part? If the root part selection is really arbitrary like you say then I have no way of fixing this buggy behavior in my plugin.
3 Likes
[quote] What are you trying to get this to do?
The root part of a motor (The one that doesn’t move) is whichever part is larger, or arbitrary if they’re equal in size. [/quote]
In cases where you can give us developers control rather than having to wrangle with an arbitrary system like this, please choose to give us control. Part0 being the root part is much more logical to me and gives me much more freedom. I am incapable of doing certain things because of this system, such as using Ethan’s fantastic plugin.
1 Like
Yeah – Part0 was always the root part. Making it whichever is larger just broke every script in existence that used welds. And plus, if they’re the same size, there’s no way to tell which one will move, so you can’t do anything with the weld at that point.
1 Like
Just set the CFrame of the part before you create the weld :uhhh:
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: Documentation - Roblox Creator Hub
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