You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
NetworkTransform in Netcode 1.11.0 (Unity 2022.3.10f1) can move objects with world space sync configuration to the incorrect location. This was initially reported as #2913, but I have now identified the full repro case and cause, and it was not fixed via #2888.
I have a good trace of the problem where it seems the host is never sending a NetworkTransformMessage, or I have not been able to identify where the remote client is ignoring the message.
The gist of the issue is that all objects begin their life with local space position updates and then NetworkTransform sends a single NetworkTransformMessage with a NetworkTransformState that changes InLocalSpace to False while also HasPositionChange is True and a new PositionX/Y/Z is provided. Subsequent messages also have InLocalSpace be False but there may be no position changes. I am seeing -- often, but intermittently -- the first and most important message never arrive or never get processed by clients. This results in that object with the NetworkTransform having its NetworkObject initialization local space coordinates be applied as world coordinates, and so the object is moved to the wrong location.
Repro
I have a large gameplay scene that is additively loaded. It has over 300 NetworkObjects and over 50 NetworkTransforms.
There is one type of object that ends up being moved by the NetworkTransform to the incorrect location. (The bug is intermittent, and it feels like a CPU race condition rather than a latency-based network race condition?) I can repro the bug in local two-Editor testing with ParrelSync and also in builds when connecting to a remote client over WAN. The bug seemed slightly more common in the build scenario.
Here is an example Hiearchy for this type of object:
0,0,0 (NetworkObject)
0,0,0
0,0,0
0,-3,0
36.648571,-2.14999914,-39.3971443
0,0,0
-14.4399996,0.150002956,-10.0100002 (NetworkObject, NetworkTransform) name = Monster
Monster is an in-scene placed NetworkObject prefab with a NetworkTransform. It has no Rigidbody. It is active in the scene. It has a bunch of non-NetworkObject parents -- some of them are not at 0,0,0 -- and then one parent at the root level that is a NetworkObject.
Root NetworkObject settings are:
Always Replicate = True
Sync Transform = True
Active Scene Sync = False
Scene Migration Sync = True
Spawn With Observ = True
Dont Destroy = False
Auto Object Parent Sync = False or True... tested both, doesn't matter`
MonsterNetworkObject settings are:
Always Replicate = False
Sync Transform = True
Active Scene Sync = False
Scene Migration Sync = True
Spawn With Observ = True
Dont Destroy = False
Auto Object Parent Sync = True
MonsterNetworkTransform settings are:
yes to sync all of the Transform parts
default Thresholds
Use Unreliable Deltas = False
In Local Space = False
Interpolate = True
Slerp = False
Use Quat Sync = False
Use Half Float = False
These changes were used to generate the gratuitous logging above. Also noteworthy is some of the gratuitous logging that did not show up in the logs as well... which is what indicates to me that the NetworkTransformMessage is never even received by the remote client when the bug happens.
The text was updated successfully, but these errors were encountered:
NetworkTransform
in Netcode 1.11.0 (Unity 2022.3.10f1) can move objects with world space sync configuration to the incorrect location. This was initially reported as #2913, but I have now identified the full repro case and cause, and it was not fixed via #2888.I have a good trace of the problem where it seems the host is never sending a
NetworkTransformMessage
, or I have not been able to identify where the remote client is ignoring the message.The gist of the issue is that all objects begin their life with local space position updates and then
NetworkTransform
sends a singleNetworkTransformMessage
with aNetworkTransformState
that changesInLocalSpace
toFalse
while alsoHasPositionChange
isTrue
and a newPositionX/Y/Z
is provided. Subsequent messages also haveInLocalSpace
beFalse
but there may be no position changes. I am seeing -- often, but intermittently -- the first and most important message never arrive or never get processed by clients. This results in that object with theNetworkTransform
having itsNetworkObject
initialization local space coordinates be applied as world coordinates, and so the object is moved to the wrong location.Repro
I have a large gameplay scene that is additively loaded. It has over 300
NetworkObjects
and over 50NetworkTransforms
.There is one type of object that ends up being moved by the
NetworkTransform
to the incorrect location. (The bug is intermittent, and it feels like a CPU race condition rather than a latency-based network race condition?) I can repro the bug in local two-Editor testing with ParrelSync and also in builds when connecting to a remote client over WAN. The bug seemed slightly more common in the build scenario.Here is an example Hiearchy for this type of object:
0,0,0
(NetworkObject
)0,0,0
0,0,0
0,-3,0
36.648571,-2.14999914,-39.3971443
0,0,0
-14.4399996,0.150002956,-10.0100002
(NetworkObject
,NetworkTransform
) name = MonsterMonster is an in-scene placed
NetworkObject
prefab with aNetworkTransform
. It has noRigidbody
. It is active in the scene. It has a bunch of non-NetworkObject
parents -- some of them are not at0,0,0
-- and then one parent at the root level that is aNetworkObject
.Root
NetworkObject
settings are:Monster
NetworkObject
settings are:Monster
NetworkTransform
settings are:Trace
When it doesn't happen:
When it does happen:
Changed Netcode 1.11.0 files
These changes were used to generate the gratuitous logging above. Also noteworthy is some of the gratuitous logging that did not show up in the logs as well... which is what indicates to me that the
NetworkTransformMessage
is never even received by the remote client when the bug happens.The text was updated successfully, but these errors were encountered: