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