Closed davidyrgilbert closed 1 year ago
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.
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):
true
) and so the child will remain in its current location no matter where you move the parent (client side relative).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:
**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:
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).
@davidyrgilbert Was wondering if you were able to resolve your issue based on the response provided?
This should be resolved in NGO v1.2.0.
@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! :)
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.
Given the following scene setup:
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.
Given the following scene setup:
This leads to a wrongly scaled Child Cube on the Client in 1.1.0.
Reproduce Steps
Actual Outcome
Expected Outcome
1.0.2 and 1.1.0 lead to the same result.
Environment
Additional Context
Minimal sample project is here: https://github.com/VRGroupRWTH/netcode_issue