Documentation on parenting NetworkObjects seems contradictory

I’m trying to understand parenting of NetworkObjects because I am getting errors when I try to nested a NetworkObject under another in various situations. The documentation seems completely contradictory so can someone please explain the following to me:

In this article we have the following to excerpts which seem to directly contract each other:

You can perform the same parenting actions with in-scene placed NetworkObjects as you can with dynamically spawned NetworkObject components.
You can parent dynamically spawned NetworkObject components under in-scene placed NetworkObject components and vice versa.

Only spawned NetworkObjects can be parented
A NetworkObject component can only be parented if it’s spawned and can only be parented under another spawned NetworkObject component.

So which is it?

Thanks,

Gareth

THE #1 rule of network parenting is: don‘t do it!

When you think about it you quickly realize that you never actually need to do so. For one, it‘s common to think that a player-held weapon needs to be parented when in fact that held weapon is merely a visualization that should not be networked at all. Instead the whole weapon logic remains in the root and the weapon visualization merely reacts to events (switch, reload, fire).

The other case where, say a character enters a vehicle, is quite similar. Instead of parenting the player to the vehicle, you only need to give the player control over the vehicle and place the character (perhaps a visual-only replacement while the actual character is simply hidden and inactive for gameplay) only visually inside the vehicle.

Even in scenarios where parenting would be useful, like attaching an object to a player‘s VR hands you can do the same. But you can also keep the attached object as a network object on the root, and merely update its transform position + rotation to match the hand bone‘s transform in LateUpdate.

So for all intents and purposes, network parenting is not needed and you‘ll make your life easier by just not using parenting.

Lastly, to answer your question: try it out. It doesn‘t take longer than writing a forum post about this provided you already have an operational network project. :wink:

Thanks for the response. I am developing a game where there are lots of objects in the environment which a player can pick up and put down/throw.

Is the recommended approach in this type of game, then, to hide objects when a player picks them up and then spawn a fake object instead and then when the player puts the object down, destroy it and show the “real” object again?

I did try it out but I got various different errors however I tried to parent one network object to another so I was hoping the documentation would clear up for me what the rules were but they just made me more confused. Whether or not parenting network objects is recommended, it’d be great if the documentation was clear enough to allow me to make an informed decision for myself.

Thanks!

I would implement it this way:

  • PickupItem is a NetworkObject, has no renderer
  • PickupItem instantiates its visualization from a separate, non-networked prefab
  • Move PickupItem in the world will naturally move its visualization
  • If picked up, the PickupItem NetworkObject reparents its visualization to the players hand, and then gets despawned. You may also have to transfer any data relevant to the item to the player’s inventory of sorts.
  • When the item gets dropped, this will spawn a PickupItem at the player’s hand, and then the visualization from the player’s hand gets reparented into PickupItem.

Networking becomes a lot easier when you think of objects as logical entities separate from their visualization.

Thanks, that’s really helpful! It’s shifted my thinking.

How I should be thinking about it is that the actual entity, its logic and its visualisation are all independent of the network object. The network object is just a thin object with rigid body, network transform and that’s about it.

The real entity can be parented to a network object with a rigid body when it’s not attached to a player and then when the player picks it up, it can be parented to the player.

It actually solves a number of other complexities in my design so thanks again.

1 Like