Seeing some scripts accessing RootRigAttachment of the players humanoid. Yet I am unable to find where the RootRigAttachment is documented as a part of the humanoid, or in fact where any of its structure is documented. The Humanoid page only mentions HumanoidRootPart and Head and that’s it. Where is the humanoids structure documented? Is it not?
Realistically, much of the Humanoid structure is undocumented as far as I can tell, and it varies between R6 and R15. The Characters Guide can serve as something of a jumping-off point, but it approaches things more from the angle of creating characters externally and getting them to work rather than the nitty-gritty of the technical backend. I can share at least some specifics I have learned, at least. The list is likely not exhaustive, but it’s what comes to mind at the moment:
There are standardized part names between R6 and R15, but the best way I can tell of learning them all is to just generate a rig using the built-in Rig Builder plugin and reading the names. “R6” and “R15” are references to the number of parts that compose the different rig types, and there are different standardized names between the rig types. For behavior that applies to the “Torso” on an R6 rig, the “UpperTorso” is used on an R15 rig, and behavior that applies to the “Right Arm” on an R6 rig uses the “RightHand” on an R15 rig. I will outline some part-specific information further down, but, generally speaking, the standardized part names are important, because they’re what all ROBLOX-published animations are looking for when they try to animate characters.
Atachments with “Rig” in their name are used for constructing joints with the Humanoid:BuildRigFromAttachments() method,. and that method will generate Motor6D joints connecting two parts that both contain Attachments with matching names. The joint name is set to the string preceding “Rig” in the Attachment name, and it is parented to the “furthest” part from the root. As far as I can tell, the method will only generate joints for Attachments whose names match the “standardized” joint names, even if there are other Attachments in the model matching the format.
Attachments without “Rig” in their name point to the places where Accessories will be applied to the model. Marketplace Accessories contain Attachments with matching names, and the Accessories will be welded to the character such that these two Attachments line up.
The “HumanoidRootPart” is really the only “required” part to give functionality to a Humanoid, and that is consistent between R6 and R15. A part with this name will become the Humanoid’s RootPart, and this property will be set to the most-recently-added, immediately-descending part matching this criteria. If no such part exists, the property will try and use the torso instead (following the same ancestry rules).
A part named “Head” is used in displaying the name and health of a Humanoid when such features are enabled. If a Humanoid has RequiresNeck set to true, then the Humanoid.Health will be se to 0 if all JointInstances connecting the head part to the torso part are destroyed or disabled. Despite what the documentation says, the joints do not need to be named “Neck” or be a Motor6Ds specifically, and directionality does not matter (either part can be Part0 versus Part1), but engine-generated necks will be Motor6D objects named “Neck.”
When trying to equip a Tool object, the engine first looks for the “Right Arm”/“RightHand” part of the rig. If it finds one, it checks for an Attachment named “RightGripAttachment.” If the Attachment exists, the Tool will be welded such that its grip aligns to that Attachment; otherwise, it will simply weld to the bottom edge of the part with Tool.Grip's forward vector aligned with the part’s down vector. If the part does not exist, the tool will just spawn in front of the player (unwelded) and drop to the ground.
2 Likes
I’ve already corrected this within the main post, but I want to point out a fairly egregious error I had originally made. I had stated that animations care about joint name, but the truth is the opposite: animations do not care about joint names, only joint hierarchies where the Part0 and Part1 properties point to parts whose names match what the animation expects.
There is also Avatar Characters | Documentation - Roblox Creator Hub, but it seems to describe the expectations of the automated importing tools rather than the general structure of avatars.