Bones: addressing a rig like a component¶

@DoorMesh/hinge_01 targets a bone, not a component: driven by the same states, keyframes, and Groups as any other target. Rotate the hinge bone and the whole door follows with its lock and handles attached, the same way you'd pose a rig in Blender, without splitting the door into separate actors.

Save the real screenshot as: shot-bones-hierarchy-icon.png

The address: `/` after `@`¶

A trailing /Bone on an @ hop switches the target from the component itself to a named bone on it:

Form	Means
`@DoorMesh`	the component `DoorMesh`, moved as a whole
`@DoorMesh/hinge_01`	the bone `hinge_01` on `DoorMesh`: the mesh itself stays put

/ is a bone delimiter only under @. A plain DoorMesh/hinge_01 with no @ isn't a valid address at all, it's rejected as unparseable, because the component has to be scoped first before a bone within it means anything. See Tag Grammar Reference for the rest of the addressing syntax this composes with (^ delegation, : state, wildcards all still apply to the component hop).

Why `UPoseableMeshComponent`, not `USkeletalMeshComponent`¶

Bone targeting requires the component to be a Poseable Mesh. A regular skeletal mesh is continuously driven by its AnimInstance: every tick, the anim graph computes a full pose and writes it to the skeleton. If MovaInteract also wrote a bone transform on that same component, the two writers fight: whichever ran last wins for one frame, and the result flickers or gets overwritten with no warning. A Poseable Mesh has no AnimInstance in the loop, so the bone belongs entirely to whoever poses it: MovaInteract, in this case, with the same predictability as it gets driving a plain scene component.

If a bone is addressed on a component that isn't poseable, it can't be driven and the Control Panel warns about it at capture time, instead of letting it fail with no error at runtime.

Component-space driving¶

The bone is driven in component space. Anything skinned beneath it in the skeleton (a handle mesh weighted to the hinge, a lock plate riding the door panel) follows automatically, same as in a DCC tool. You don't re-target child bones separately: posing the parent carries its skinned children.

Deltas layer onto the captured `@Zero` bone pose¶

Like a component target, a bone's written Location/Rotation deltas are not absolute, they layer onto the bone's captured @Zero pose (its reference pose at capture time), not the world or component origin. A bone whose reference pose sits rotated 10° already, driven by a state written as +25°, ends at 35°, not 25°. This is the same rule The Model describes for @Zero on ordinary components: bones don't get a special case.

Showing up in the panel¶

A bone target appears in the Control Panel's hierarchy tree alongside regular components, with its own distinct icon so it reads at a glance as "a bone, not a component." The target picker offers bones the same way it offers components and tagged components (search, select, done) so setting up a hinge target never requires typing the /hinge_01 path by hand.

Worked example: a door with a rigged hinge¶

State "Open":
  Target: @DoorMesh/hinge_01
  Rotation: (Yaw: 90)

An Action targeting @DoorMesh/hinge_01 with a keyframe at 1.0 → Open swings only the hinge bone 90°. The door panel, handle, and lock plate (all skinned to bones beneath hinge_01 in the rig) swing with it. No separate Action is needed for the handle: it isn't a sibling component being animated in parallel, it's geometry that follows the bone.

Bones: addressing a rig like a component¶

The address: / after @¶

Why UPoseableMeshComponent, not USkeletalMeshComponent¶