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.
[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.
[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.
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.
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.
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.
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.
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.
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.
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.
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:
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.