Trying to equip mulitple avatars via the inventory "Equip" button does not work as it will just delete any avatars you are wearing first then equips the new one.
You can however equip multiple avatars via the Equip Avatar node and via the context menu when clicking on an avatar.
The default avatar is made of 4 different avatars that are generated to fill the head, the ViewVisual (3rd Person Camera) and either hand, these bodynodes will be auto filled if they are empty when equipping an avatar.
If you equip an avatar that is set up as only an AvatarPoseNode set to the Left Hand it would auto generate the Right Hand and the Head default avatars.
AvatarRoot
- This is generated by the Avatar Creator Dialog
- This handles the click to equip context menu when clicking on avatars
- Appears to effectively equip to the Root bodynode
- Equiping an AvatarPoseNode set to root will dequip an AvatarRoot
- You can only equip one of these at a time as this appears to equip to the Root bodynode
- This can be equipped without an AvatarGroup
AvatarGroup
- This is generated by the Avatar Creator Dialog
- This can be equipped without an AvatarRoot
- If equipping with an AvatarRoot component, the AvatarGroup must be either on the same slot or under the AvatarRoot otherwise they will be treated as separate avatars
- This houses AvatarPoseNodes to make them all act as one avatar
- This means that when you dequip/equip the root all avatars under also get dequipped/equipped from their respective bodynodes
- You can equip multiple AvatarGroups with their own AvatarPoseNodes , as long as those AvatarPoseNodes do not conflict with other already equipped AvatarPoseNodes
AvatarPoseNode
- This is generated by the Avatar Creator Dialog
- These are the "Proxy" slots you find under an avatar when created via the Avatar Creator Dialog
- The pose nodes that are currently generated as of writing are: Head, Hips, Chest, Both Hands, Both Elbows, Both Feet, Both Knees
- Does not require an AvatarRoot nor an AvatarGroup component and can be directly equipped
- AvatarPoseNodes equip to individual AvatarObjectSlots/BodyNodes
- Only one AvatarPoseNode per AvatarObjectSlot/BodyNode
- If an avatar you are equipping has an AvatarPoseNode set to Head for example, you cannot equip another head but you would be able to equip a hand
- Only conflics with AvatarRoots/Groups IF they have AvatarPoseNode set to the same BodyNode
- The MutuallyExclusiveNodes list will cause the AvatarPoseNode to dequip anything currently equipped to the specified BodyNodes when the AvatarPoseNode is equipped. However if something equips to those BodyNodes after the AvatarPoseNode is already equipped this will not prevent equipping nor will it dequip the AvatarPoseNode
AvatarObjectSlot
- This component is usually generated under the user's user root
- This component allows AvatarPoseNodes to equip to specific BodyNodes and tells them the transforms
- This component also controls the "SourceIsTracking" and "SourceIsActive" booleans on an AvatarPoseNode
- This component has options for "DriveActive" and "DriveScale", these allow making the AvatarPoseNode copy the slot active state and the slot global scale of the AvatarObjectSlot
- View, Head, Controllers, Hands, are all default BodyNodes generated by the CommonAvatarBuilder
- More *might* be generated if using full body, I have not checked this
- You can manually inject new AvatarObjectSlots allowing for more available bodynodes for avatars to equip
- Avoid setting the node to NONE as this can cause issues
- I would also avoid setting the node to Root, I have not fully tested if this actually does anything
- Putting a new AvatarObjectSlot under CommonAvatarBuilder's AutoInject happens before avatar creation, meaning it is compatible with the AvatarTemplates
- Does not need to be directly under the user to work, can be nested under slots
- The bodynode can be set to any arbitrary int value and AvatarPoseNodes can equip to those arbitrary int values, this allows avoiding conflicts with peoples avatars for in world systems
- This behavior is probably unsupported and can eventually be changed