Strange Animation Behaviour

[Arch_Mage]

So, when making animations for an enemy in my game, I found that strange behaviour was occurring.

When in the animation editor, and if the HumanoidRootPart was anchored, the animation would be played back correctly.

https://a.pomf.cat/oiphke.webm

However, in-game, when the HumanoidRootPart was unanchored, the behaviour would be quite strange indeed.

https://a.pomf.cat/xuuqrz.webm

The HRP is highlighted as neon red. The HRP moves, but the torso seems to remain mostly static? It’s also rotated strangely.

Some help in remedying this would be appreciated.

@AbstractAlex

[AbstractAlex]

Questions:

1. Do you have a part named HumanoidRootPart? Torso?

2. If so, what are their sizes?

Often when I see these issues it is because the HumanoidRootPart does not become the assembly root because it does not have enough mass.

[Arch_Mage]

Ah, thanks.

I resized the HRP up slightly and that appeared to fix it.

Is there anything that could be fixed here on your end, or is it easier to just allow players to work it out :?

[AbstractAlex]

Can you try making your HumanoidRootPart larger than the torso and seeing if the issue persists? Just to rule out one possible reason it wouldn’t work.

Edit: (Ninja’d) Glad that works!

On our end, the way the physics engine works is by taking the larger part as the root of the geometry. There are special “mass multipliers” that apply to Torso, hrp and Seats to ensure they usually get to be assigned as an assembly root. I believe this is still how we do it.

To answer your question, I do not believe this will change on our end. A way of detecting this in the editor would be fantastic though. I’ll look into implementing something like this.

[Arch_Mage]

Hmm, alright.

Thanks for the help, though!

What’s curious is that earlier I tried setting Torso density to 0.01 (in run-time, i believe), and that didn’t actually fix it.

[AbstractAlex]

I don’t believe density plays any role in determining an assembly (what we call a chain of connected parts) root.

I could be wrong though, @Khanovich would know for sure!

[Arch_Mage]

Sorry for probably asking the wrong person here, but do you reckon that’s intended behaviour?

[EchoReaper]

@AbstractAlex

On our end, the way the physics engine works is by taking the larger part as the root of the geometry. There are special “mass multipliers” that apply to Torso, hrp and Seats to ensure they usually get to be assigned as an assembly root. I believe this is still how we do it.

This arbitrary behavior needs to stop. Part0 should be the root and Part1 should be the subpart. @CodeWriter @Silent137 here’s another reason to add onto the ones you responded to in these threads:

When editing a motor's C0/C1, Part0 gets moved instead of Part1

This behavior broke a plugin of mine. Looks like it just started happening in the last day or so. Repro: https://www.dropbox.com/s/6v8vq9ixwsbev5l/motor%20bug.rbxl?dl=0 Click run and the script in the workspace will edit C0. Watch how Part0 moves instead of Part1. Pls fix. [image]

New weld system needs to go

The new weld system completely disregards the Part0/Part1 properties and makes the largest part Part0 and the smallest part Part1. That causes this to happen: [image] [image] The weld system can’t make up its mind which one is largest so if I go into Play mode one time with the below script running, I could have my torso be in the correct place and the first-person one behind it like it should be, or the weld system could pick the first person torso (the blue one) to be Part0 despite explic…

[AbstractAlex]

Could you post the original sizes of your Torso and hrp? Before you fixed it?

[Arch_Mage]

“hrp is 2, 2, 2
torso is 2.765, 3.134, 4.8”

and then I resized HRP to 3,3,3, which fixed the issue