RThro packages make the position of HumanoidRootPart inconsistent with avatar scale settings disabled

image image image

image

As pictured above, using packages built for RThro will cause the humanoid root part to be located in different locations, even with all avatar scaling settings disabled. Non-Rthro packages do not do this, so I’m inclined to believe that this is not intended behavior, especially seeing as it would make sense that disabling avatar scaling should get you results that yield all avatars actually being the same scale.

10 Likes

imagine creating humanoidrootpart to act as the fundamental consistent factor between avatars…
and then throwing that principle out the window

13 Likes

I rely on this this being consistent for effects, teleporting, etc. Please fix.

1 Like

These inconsistencies apply to Rthro packages in general, as most of them appear to be completely different in terms of proportion and scale.

If you have the scaling values locked, you’d expect all packages to appear roughly the same. This is not the case, which causes a lot of problems not only for animations and visual effects but also for level design and overall balancing.

Say a certain package makes your character a few studs wider, so you can no longer fit through some doors. Or the package makes you too tall, so your head sticks out when crouching behind cover in an FPS game.

3 Likes

I am not sure what exactly you are referring to as different locations. From the provided examples, the largest difference is in the Y coordinate. What you are seeing in the Y axis is expected as we move from fixed joint locations to artist driven joint locations.

I suspect that the majority of the change that you are describing is due to the differences in leg lengths. The lengths of the equipped legs are used to automatically calculate the HipHeight to ensure that the character’s feet remain on the ground. This height, though, will be slightly different depending on the sizes of the legs that a character has equipped. If this automatic calculation is causing issues in your game, you can disable it by setting AutomaticScalingEnabled on the Humanoid to false. This will leave HipHeight set to whatever it was before the flag was set and will not recalculate it if the character’s parts or scales change. It may also result in the character’s feet floating above or sinking into the ground.

If you are concerned about certain body parts making your character too large or small, you can override the player’s appearance using the new Game Settings/Avatar options to create a custom yet consistent look for characters in your game.

1 Like

Not entirely sure how to interpret this. I was under the impression that the scaling values (height, width, body type etc) were supposed to control the proportions of the character, not the package parts themselves? So if you use the default scaling values, all packages would look similar to the R15 rig proportion wise (so rthro packages would look somewhat squished).

This doesn’t seem to be the case, as rthro packages drastically affect the character proportions when using default scaling values:

I’m sure there’s a reason behind the current implementation, but from my developer perspective it would be more convenient to base all packages around the R15 rig for consistency and backward compatibility.

5 Likes

Hipheight being based on leg length makes sense, but there’s a problem:
Rthro arms are all shrunk by the same proportion when placed on a classic rig, meaning standard Rthro arms will be the same length as classic arms and large Rthro arms will be larger than classic arms. This makes perfect sense, it makes Rthro parts fit well with classic rigs yet have their intended proportions relative to everything else.
Rthro legs, however, will not be shrunk at all to fit classic rigs. It looks silly.

I have a suspicion as to why Rthro legs don’t shrink: The upper and lower legs are narrower on classic rigs while the feet stay the same, just as upper and lower arms are shorter on classic rigs while the hands stay the same. This is a nonsensical behaviour (there’s no reason to narrow the legs) that is very close to the sensible behaviour we see for arms, the only difference being that legs get narrower instead of shorter.
A nonsensical behaviour that is almost identical to the sensible behaviour is very likely the result of a subtle mistake in the code, maybe this was never the intended behaviour at all and whoever programmed this just didn’t notice the weird scaling in testing? The issue is only blatantly obvious when using Rthro legs and a classic torso with classic proportions, so it’s entirely plausible that an unintended behaviour made it through testing unnoticed.