Why is ClientNetworkTransform not included in the package?

Hey everyone!
ClientNetworkTransform seems really useful, any reason why it’s not included in the main package but rather in a separate sample?
Is there some hidden serious downside that means I shouldn’t use it? I understand the potential issues with a client-authoritative component.
Thanks!

1 Like

Hi @CodeMonkeyYT

The client network transform component lives separately within Unitilies in our sample repo because of a number of reasons. The main reason is that we are not able to meet the quality bar we set for features within NGO.

There are many potential issues, yes:

  • Ownership transfer doesn’t reconcile appropriately in many cases (you can experience a big jump/teleport, and may even desync in some cases).
  • Hierarchical ownership isn’t enforced (that is, a CNT under a server NT isn’t prevented, tested or supported).
  • There is no mechanism for a server to reject a transform update from the client (it’s client ownership, not dual client + server ownership).
  • There is no way for a server to move an object anywhere at instantiation time (it’s client ownership, not dual client + server ownership)

In some cases, these are deeply implementation dependent, and in other cases would require substantial architectural changes to the SDK.

Ultimately some of these may work 90% of the time and some 100% of the time.

We wanted to retain the CNT component as a way to do client ownership transforms, and we support that through our Utilities package in the Boss Room repo.

Thanks,
Chris

Oh I see, I hadn’t considered those issues where the server cannot enforce anything on the client. Thanks!

1 Like