Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NetworkTransform 1.11.0 can initialize world space objects to wrong position #3080

Open
zachstronaut opened this issue Sep 27, 2024 · 0 comments
Assignees
Labels
Investigating Issue is currently being investigated stat:awaiting triage Status - Awaiting triage from the Netcode team. type:bug Bug Report

Comments

@zachstronaut
Copy link

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`

Monster NetworkObject 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

Monster NetworkTransform 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

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.

@zachstronaut zachstronaut added stat:awaiting triage Status - Awaiting triage from the Netcode team. type:bug Bug Report labels Sep 27, 2024
@NoelStephensUnity NoelStephensUnity self-assigned this Sep 27, 2024
@NoelStephensUnity NoelStephensUnity added the Investigating Issue is currently being investigated label Sep 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Investigating Issue is currently being investigated stat:awaiting triage Status - Awaiting triage from the Netcode team. type:bug Bug Report
Projects
None yet
Development

No branches or pull requests

2 participants