# Deeply-nested CoherenceSyncs

While the basic case of direct parent-child relationships between CoherenceSync entities is handled automatically by **coherence**, more complex hierarchies (with multiple levels) need a specific component.

{% hint style="info" %}
An example of such a hierarchy would be a synced Player Prefab with a hierarchical bone structure, where you want to place an item (e.g. a flashlight) in the hand:

*Player > Shoulder > Arm > Hand*
{% endhint %}

### Implementation

To prepare the child Prefab that you want to parent at runtime, add the `CoherenceNode` component to it (in addition to its `CoherenceSync`). In the example above, that would be the flashlight you want your player to be able to pick up. No additional changes are required.

This setup allows you to place instances of the flashlight Prefab anywhere in the hierarchy of the Player (you could even move it from one hand to the other, and it would work).

![A CoherenceNode before pressing Play](https://content.gitbook.com/content/NGFZGdbLA4bzHQXTuDMT/blobs/ATHWtQpv0B4UwNHeaesM/CoherenceNode.png)

You **don't** need to input any value in the fields of the `CoherenceNode`. They are used at runtime, by coherence, automatically.

To recap, for deep-nesting network entities to work, you need two things:

1. The parent: a Prefab with `CoherenceSync` that has some hierarchy of child transforms (these child transforms are not networked entities themselves).
2. The child: another connected Prefab with `CoherenceSync` and `CoherenceNode`.

### Ensuring hierarchies are in sync

One important constraint for using `CoherenceNode` is that the **hierarchies have to be identical on all Clients**.

{% hint style="success" %}
Example: if on Client A an object is parented to *Player > Shoulder > Arm > Hand*, the hierarchy on Client B needs to be exactly: *Player > Shoulder > Arm > Hand*.

Removing or moving an intermediate child (such as *Shoulder* or *Arm*) would lead to undesirable results, and desynchronisation.
{% endhint %}

**Position and rotation**

Similarly to the above, intermediate children objects need to have **the same position and rotation on all Clients**. If not, that would lead to desync because the parented entity doesn't track the position of its parent object(s).

If you plan to move these intermediate children, then we suggest to sync the position and/or rotation of those objects as part of the containing Prefab.

{% hint style="success" %}
Following the previous example, if an object is parented to *Player > Shoulder > Arm > Hand*, you might want to mark the position and rotation of *Shoulder*, *Arm* and *Hand* as synced*,* as part of the prefab *Player*.

This way if any of them moves, the movement will be replicated correctly on all clients, and the object parented to *Hand* will also look correct.
{% endhint %}

Keep in mind that there is no penalty for synching positions of objects that never or rarely move, because the position is not synched every frame if it hasn't changed.

{% hint style="info" %}
For an example of a `CoherenceSync` parenting and unparenting at runtime in a deep hierarchy, check out the **First Steps** sample project, [lesson 5](https://docs.coherence.io/1.7/getting-started/samples-and-tutorials/first-steps-tutorial/5-complex-hierarchies).

<img src="https://content.gitbook.com/content/NGFZGdbLA4bzHQXTuDMT/blobs/55urZFy056B09sPflZst/RobotArm_DeepHierarchies.jpg" alt="" data-size="original">
{% endhint %}