Owernship None doesn't work

[marcusx2]

Description

I have a network object owned by a client. The Ownership is set to None. When the client disconnects, the ownership is transferred to the server.

Expected Outcome

The ownership should remain to the disconnected client. The documentation states that I should use None to avoid ownership transfer, but it's happening anyway. I am using
private void OnClientDisconnect(ulong clientId) on the server, and I want to check if the client is the owner of something, despawn it on the server. I can't do that, because the ownership keeps being transferred to the server.

[NoelStephensUnity]

Hi @marcusx2,
Ownership permissions is a distributed authority only property.

When a client disconnects from either type of network topology, all NetworkObjects instantiated and spawned locally on the client that disconnected will be despawned and if not registered with a network prefab handler it will be destroyed.

When using a client-server network topology, to assure the NetworkObject owned by a client is not persisted when the client disconnects you should make sure don't destroy with owner is unchecked.

However, the ownership permissions will have no impact on NetworkObjects when using a client-server network topology as the server/host will always have full permissions/authority over all spawned NetworkObject instances (with the only caveats being NetworkTransform when using an owner authoritative motion model and NetworkVariables when using owner write permissions).

[marcusx2]

If it's working as intended, the documentation isn't clear about it. You say that ownership permissions is only valid for a distributed authority configuration, but we have Ownership permission settings, where we can select distributed as one of the options, so it sure doesn't seem like ownership permissions only pertain to distributed topology.

[NoelStephensUnity]

@marcusx2
That is understandable.
There was a decision made about when to expose those settings as a project can have more than one NetworkManager instance (in different scenes) and the NetworkObject being edited within the inspector view could be during a prefab editing session or could be in a scene that does not contain a NetworkManager component. As such, there was no valid way to determine if the intended usage of a NetworkObject was for strictly a client-server, distributed authority, or both network topologies. In the end, the decision to make it available if the multiplayer services SDK was installed was made.

The documentation on Ownership permission settings does state:

The following ownership permission settings, defined by NetworkObject.OwnershipStatus, are only available when running in distributed authority mode:

Since we do cover the network topologies in our documentation which does state:

Client-server games use a server authority model. In this network topology the server has final authority on the state of the game.

and

In a distributed authority topology, game instances share responsibility for owning and tracking the state of objects in the network using a distributed authority model.

We felt that the separation between a client-server and distributed authority network topology would make sense as to why ownership permissions are not used when running a client-server network topology.

Do you feel it would help if we more clearly state within the Ownership permission settings that ownership permissions, while still visible if using a client-server network topology and the multiplayer SDK is included, will have no effect/impact on ownership if running a client-server network topology since the server always has authority?

[marcusx2]

Do you feel it would help if we more clearly state within the Ownership permission settings that ownership permissions, while still visible if using a client-server network topology and the multiplayer SDK is included, will have no effect/impact on ownership if running a client-server network topology since the server always has authority?

Definitely, yes. I'm not even the only one confused by this.

[NoelStephensUnity]

Ok, made an update to the documentation and the PR should land soon.