Question Networked gameobject jumps back to original position on client

What does your parenting code look like?
This sounds like either:

• You are NetworkObject parenting and de-parenting with world position stays set to false
  • Just assure it is deparenting with world position stays set to true.
• You are just changing the parent of a child GameObject nested under the weapon's NetworkObject/GameObject(i.e. NetworkObject stays in its original location while the child is parented under the player's GameObject hierarchy) and reparenting it under the original weapon's NetworkObject's GameObject (or some child under it) causes the visual anomaly you are seeing.

Without having more details on how it is parented, the NetworkTransform settings, and how it is being "de-parented" it will be hard to determine the issue specifically.

 

Could you provide snippets of the code/script that is parenting and deparenting the objects or are you using the XR Grab directly?

 

This kind of issue is completely resolved in the near future distributed authority update.
Basically there will be either a new type of helper component provided or NetworkRigidbody will be updated to handle this.

Parenting with Rigidbodies will look like:

• Change ownership
• Parent object (TryParent)
  • Position if needed
• Add a FixedJoint to the child (this all might be "automatic and configurable")
  • Assign the parent's Rigidbody to the FixedJoint

Done.

Deparenting will look like:

• On the child:
  • Remove parent (TryRemoveParent)
  • Destroy the FixedJoint
  • Add a force or velocity to the object (optional)

Done.


For non-Rigidbody scenarios:

Parenting:

• Change ownership
• Parent

Done.

Deparenting:

• Remove parent

Done.

For now, I would get things working the best you can if you are not planning to release in the next 3'ish month (or so) and then check out the updates when the distributed authority version is released. Many things relating to visual synchronization and such have been improved greatly.

If you are planning on releasing relatively soon, ping me back and I will post a sample project here that you can use as a reference to get it working in v1.8.0/v1.7.1.

 

Actually, what I was talking about was if you have two NetworkObjects and you want to parent one under the other and especially if both have a Rigidbody component (i.e. get into a jeep and have fellow players jump in with you and drive around).

The issue you are describing, regarding the bone location of the object, can be accomplished with minimal script and just a little bit of preparation.

The general tendency is to lump everything on the root GameObject of a prefab, but for the scenario you are describing you should divide up your prefab where the root GameObject is really just a "container" for the actual object to be held.

As an example, you might want to be able to freely move an item around when it is not picked up (i.e. could be kicked, etc). In this case the root of your prefab should only have a NetworkObject and NetworkTransform:

• Root "ObjectToHoldParent" (GameObject)
  • Components:
    • NetworkObject
    • NetworkTransform

However, when the item is picked up, you want to be able to migrate certain parts of that prefab to a specific location on a model (i.e. like a player) while also keeping the ability for those parts to have NetworkBehaviours that still function correctly (i.e. RPCs, NetworkVariables, Netcode events, etc).

With this in mind you would want all of those parts to be nested under the root GameObject on a child:

• Root "ObjectToHoldParent" (GameObject)

• Components:
  • NetworkObject
  • NetworkTransform

• ObjectToHold (Child GameObject)

• Components:
  • AutoParentChildNetworkBehaviour (** see below)
  • NetworkAnimator (just for example purposes, not required)
  • CustomObjectNetworkBehaviour (object's custom behaviours)
  • etc.

​

The key to "easy parenting" is all contained within the child ObjectToHold's AutoParentChildNetworkBehaviour. Here is a partially functional (the parenting part) pseudo code example of how to use the above prefab layout and get every client (late join or connected) to keep synchronized with the parented child object and have the parented child object move smoothly with the player's "holding node" (i.e. hand or the like):

Code (CSharp):

1.  
2. public class PlayerLogicBehaviour : NetworkBehaviour
3. {
4.     // Assigned in-editor to the child node on the player prefab where you want
5.     // things to be held relative to the player.
6.     public GameObject ObjectHoldNode;
7.  
8.     // The rest of your player logic
9. }
10.  
11. // This should be placed on the child object (i.e. ObjectToHold) that has the visuals and such
12. // that really represent the "object being held".
13. public class AutoParentChildNetworkBehaviour : NetworkBehaviour
14. {
15.     private Vector3 m_ObjectPositionBeforeParenting;
16.     private Transform m_OriginalParent;
17.     private void Awake()
18.     {
19.         // Preserve the original parent and local space position relative to the parent.
20.         // All client instances will initialize these to the same prefab preset values.
21.         m_OriginalParent = transform.parent;
22.         m_ObjectPositionBeforeParenting = transform.localPosition;
23.     }
24.     public override void OnNetworkDespawn()
25.     {
26.         // Assure it is "re-attached" to the original transform parent and has the same position,
27.         // in the event it is being used in an object pool, when despawned.
28.         transform.SetParent(m_OriginalParent, false);
29.         transform.localPosition = m_ObjectPositionBeforeParenting;
30.         base.OnNetworkDespawn();
31.     }
32.  
33.     // This is automatically invoked on all clients when a NetworkObject's parent changes
34.     public override void OnNetworkObjectParentChanged(NetworkObject parentNetworkObject)
35.     {
36.         // If a parent is assigned...
37.         if (parentNetworkObject != null)
38.         {
39.             var playerLogicBehaviour = parentNetworkObject.GetComponent<PlayerLogicBehaviour>();
40.             // If a player picked it up
41.             if (playerLogicBehaviour != null)
42.             {
43.                 // Set the parent to the player's assigned ObjectHoldNode's transform
44.                 transform.SetParent(playerLogicBehaviour.ObjectHoldNode.transform);
45.                 // Zero out the local space position so the held object moves and rotates with
46.                 // the player's  ObjectHoldNode's transform
47.                 transform.localPosition = Vector3.zero;
48.             }
49.         }
50.         else // Otherwise, a parent was removed...
51.         {
52.             // The item was dropped/removed. Put the child back under its original transform and
53.             // apply any pre-set local space offset.
54.             transform.SetParent(m_OriginalParent);
55.             transform.localPosition = m_ObjectPositionBeforeParenting;
56.         }
57.         base.OnNetworkObjectParentChanged(parentNetworkObject);
58.     }
59. }
60.  

So, as long as the "ObjectToHoldParent" is spawned, it doesn't really matter where you place its children as they have already been associated with the ObjectToHoldParent's NetworkObject. So really all you need to know about is when the child's parent NetworkObject has been parented or removed from a parent in order to handle the automatic parenting of the child object. The code is sever-client agnostic and should be updated on connected and late joining clients automatically.

This approach works fine in NGO today. The only area where you might want to possibly smooth up is the picking up or dropping transition... which you can modify the above to handle lerping to the target parent position (use a coroutine or the like) of the ObjectToHold... but that is more specific to your project's visual needs/goals in regards to picking things up and dropping them.

The above approach works very well for objects that "move with" a player or other object (typically based on animation and/or motion). However, when you start getting a mix of NetworkObjects with Rigidbodies that all could be parented under a single NetworkObject with a Rigidbody (i.e. a bunch of players board a large vehicle like a ship or spaceship and the players can all move around and interact with things on the moving vehcile)...then it can become complex with NGO as it is today.

Side note:
Just worth mentioning that the ObjectToHold and any children of the ObjectToHold do not require a NetworkTransform to synchronize the motion. The player object and the motion (i.e. due to animations) of the ObjectHoldNode will automatically move the parented ObjectToHold.

​

 

Yeah, I hear you on this (for sure) and we definitely need to start populating the Unity.Netcode.Components namespace with things like the above example. There were some recent PRs to update all of the NetworkVariable container issues (you now have dictionaries and such) as well as PR-2820 that provides some additional functionality you might find of interest.

However, like you mentioned we need to provide more examples (like above) as companion components to the SDK... but readily available within the SDK (i.e. you don't need to hunt down/install another package or the like). This is something we are looking to improve in the near future after we finish some foundational updates.

 

There were a few minor adjustments I made:

• UniversalRpcs should end with Rpc (using ServerRpc will conflict with the legacy ServerRpc)
• You don't need to send the identifiers who is sending (that is handled for you in the RpcParams)
• When dealing with ownership things, it is recommended setting the RequireOwnership to false in the attribute decoration (otherwise it won't be processed if the sender is not the owner).

Either case,
Here are the adjustments made:

Code (CSharp):

1. public class NetworkGrabInteractable : XRGrabInteractable
2. {
3.     private NetworkObject networkObject;
4.  
5.     protected override void Awake()
6.     {
7.         base.Awake();
8.         networkObject = GetComponent<NetworkObject>();
9.     }
10.  
11.     protected override void OnSelectEntered(SelectEnterEventArgs args)
12.     {
13.         base.OnSelectEntered(args);
14.  
15.         RequestOwnershipRpc();
16.     }
17.  
18.     protected override void OnSelectExited(SelectExitEventArgs args)
19.     {
20.         base.OnSelectExited(args);
21.  
22.         RemoveOwnershipRpc();
23.  
24.     }
25.  
26.     [Rpc(SendTo.Server, RequireOwnership = false)]
27.     private void RequestOwnershipRpc(ServerRpcParams rpcParams = default)
28.     {
29.         if (networkObject.OwnerClientId == rpcParams.Receive.SenderClientId)
30.         {
31.             return;
32.         }
33.  
34.         networkObject.ChangeOwnership(rpcParams.Receive.SenderClientId);
35.     }
36.  
37.     [Rpc(SendTo.Server, RequireOwnership = false)]
38.     private void RemoveOwnershipRpc(ServerRpcParams rpcParams = default)
39.     {
40.         if (networkObject.OwnerClientId != rpcParams.Receive.SenderClientId)
41.         {
42.             return;
43.         }
44.  
45.         if (!networkObject.TryRemoveParent())
46.         {
47.             Debug.LogWarning("Failed to remove parent");
48.         }
49.     }
50. }

Let me know if this resolves your issue?

 

PR-2813

• Added: NetworkVariable now includes built-in support for NativeHashSet, NativeHashMap, List, HashSet, and Dictionary
• Added: NetworkVariable now includes delta compression for collection values (NativeList, NativeArray, NativeHashSet, NativeHashMap, List, HashSet, Dictionary, and FixedString types) to save bandwidth by only sending the values that changed. (Note: For NativeList, NativeArray, and List, this algorithm works differently than that used in NetworkList. This algorithm will use less bandwidth for "set" and "add" operations, but NetworkList is more bandwidth-efficient if you are performing frequent "insert" operations.)

 

You can thank @Kitty-Unity for that PR... she has been busy indeed!

 

Apologies for not responding sooner.
I have been working on a new "session mode" for NGO (distributed authority) which would indeed provide an easier way to handle this, but that isn't an option at this time. My intention is to put together an XR sample with as simple of an implementation as possible to grab and drop objects... of course that is my intention...

Depending upon how the day shapes up for me, I might get an hour to churn a small example project out... if not maybe over the weekend I can make it my "personal project" (typically I do one or two code related things if I have the time).