# 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.

<!-- shot:bones-hierarchy-icon -->
```{image} ../_static/screenshots/shot-bones-hierarchy-icon-mockup.svg
:alt: bones hierarchy icon (placeholder mockup)
:width: 100%
```

Save the real screenshot as: `shot-bones-hierarchy-icon.png`
<!-- /shot -->

## 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
{doc}`tag-grammar` 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 {doc}`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

```text
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.

## See also

- {doc}`tag-grammar`: the `/` bone delimiter in the full addressing reference.
- {doc}`model`: how `@Zero` and the other special states resolve, for
  components and bones alike.
- {doc}`states`: the Transform bundle a bone target's state writes into.
- {doc}`../guides/control-panel`: the tree view and target picker that surface
  bones alongside components.
- {cpp:class}`FMovaIxSceneComponents` (`BoneNames`, index-aligned with
  `Components`) in the API reference.