Updating from 1.0.2 to 1.1.0 leads to different behaviour for in-scene placed NetworkObjects regarding initial scale and position.

[davidyrgilbert]

Description

I've noticed a breaking change or bug regarding the initial syncing of in-scene places NetworkObjects that had either their position changed before a client connects, or which are in a hierarchy that contains scaled GameObjects.
Below is a link to a sample project which demonstrates this better than I can explain.

For both issues, the server starts on a bootstrap scene and then loads a SampleScene via the (Network)SceneManager.
The described setups are in the SampleScene.

1. Initial position sync for in-scene placed network objects:

Given the following scene setup:

• Parent Cube (No NetworkObject)
  • Child Cube (NetworkObject)

They are stacked on each other somewhere in the scene. On Start(), the Parent Cube is moved from its original position to the desired one (0, 0.5, 0), such that the stack appears right in front of the respective players - Start() is executed on both client and server. This works fine on the connecting client in 1.0.2, but in 1.1.0 only the parent cube is being moved.

2. Initial scale sync for in-scene places network objects:

Given the following scene setup:

• Parent Cube (No NetworkObject)
  • Scale Gameobject (No NetworkObject)
    • Scaled Child Cube (NetworkObject)

This leads to a wrongly scaled Child Cube on the Client in 1.1.0.

Reproduce Steps

1. Checkout the sample at https://github.com/VRGroupRWTH/netcode_issue
2. Start a second unity instance (ParrelSync is included)
3. Load Bootstrap scene on both
4. Start Server on one
5. Start Client on the other
6. Switch Netcode version
7. Restart Unity and repeat

Actual Outcome

1. Only the Parent Cube is being moved on the client.
2. The Childcube has the wrong scale applied on the client.
3. Both are correct on the Host, and on 1.0.2 on the client as well.

Expected Outcome

1.0.2 and 1.1.0 lead to the same result.

Environment

• OS: Windows and Linux (Host, Server, Dedicated Server Build, all lead to the same)
• Unity Version: 2020.3
• Netcode Version: 1.1.0

Additional Context

Minimal sample project is here: https://github.com/VRGroupRWTH/netcode_issue

[NoelStephensUnity]

Hi @davidyrgilbert,
Our develop branch has a fix for this issue where the Auto Object Parent Sync was not being taken into consideration with the parenting and scale updates in v1.1.0.
#2281 is the PR that resolves the Auto Object Parent Sync issue.
You can update your project's manifest file's com.unity.netcode.gameobjects entry with this:
"com.unity.netcode.gameobjects": "https://github.com/Unity-Technologies/com.unity.netcode.gameobjects.git?path=com.unity.netcode.gameobjects#develop",
To get the fix for the parent sync issue until the next update.
With the Auto Object Parent Sync fix update (via manifest update above):

• Parent1 had to do with the Auto Object Parent Sync being turned off on the Child1 NetworkObject and the parent of Child1 having a scale other than Vector3.one. With the fix no changes are required for that to function properly.
• Parent2 actually requires one of two adjustments:
  • Option 1: Turning Auto Object Parent Sync back on for Child2 will automatically move local space relative with the parent.
    • With it disabled, it will use the default "WorldPositionStays" value (which is true) and so the child will remain in its current location no matter where you move the parent (client side relative).
  • Option 2: If you would like to keep the Auto Object Parent Sync disabled, then you need to add a NetworkTransform to Child2 and enable local space synchronization.

I apologize for any inconvenience the newly introduce Auto Object Parent Sync issue may have impacted your development schedule. There were a good deal of parenting fixes of which neither WorldPositionStays (when parenting via NetworkObject) nor scale were being synchronized with clients. As well, there were several other issues involving parenting (in-scene placed and dynamically spawned) that were fixed...during which I overlooked the Auto Object Parent Sync element.

Either case, the one aspect that you might need to make adjustments for on your side for your project is how you are using the Auto Object Parent Sync option and how that impacts already parented in-scene placed NetworkObjects.
In-Scene Placed NetworkObject Auto Object Parent Sync Usage:

• When disabled, the NetworkObject ignores its parent and considers all of its transform values as being world space synchronized (i.e. no matter where you move or rotate its parent, it will maintain its current position and rotation on the client side)
  • Typically, when disabling this you need to handle synchronizing the client either through your own custom messages or RPCS or add a NetworkTransform component to it. This is only useful if you want to have some global parent that might shift or have transform values that you don't want to impact the NetworkObject in question.
• When enabled, the NetworkObject is aware of its parent and will treat all of its transform values as being local space synchronized.

**The caveat to the above is scale: Scale is treated always as local space relative for pre-parented (i.e. in-scene placed) NetworkObjects. For dynamically spawned NetworkObjects it depends upon what WorldPositionStays value you use when parenting the NetworkObject in question.
WorldPositionStays = true: Everything is world space relative.
WorldPositionStays = false: Everything is local space relative.

The final note is that without the use of a NetworkTransform clients are only synchronized with the transform values when:

• A client is being synchronized with the NetworkObject in question
  • During the client's first synchronization
  • When a server spawns a new NetworkObject
• A NetworkObject has been parented (or a parent removed). The server can override the NetworkBehaviour.OnNetworkObjectParentChanged method and adjust the transform values when that is invoked and those changes will be synchronized with clients.

I hope this information is useful and that you are able to continue developing your project using the fix for this issue.
The fix will be included in the next update, and at that time I will post a notification here when the update is available as well as close this issue (unless you have further issues after using the develop branch via the manifest update I included above...in that case feel free to post any issues or further questions that you might have here).

[NoelStephensUnity]

@davidyrgilbert
Was wondering if you were able to resolve your issue based on the response provided?

[NoelStephensUnity]

This should be resolved in NGO v1.2.0.

[davidyrgilbert]

@davidyrgilbert Was wondering if you were able to resolve your issue based on the response provided?

Yes, we managed to resolve it. There were some other issues with SmoothSync that interfered as well, but as far as we can tell it seems to work fine now. Thanks again for the fix! :)