Can't set a client's local player object without destroying/reinstantiating
Is your feature request related to a problem? Please describe. It is currently not possible to set a NetworkObject as the player's player object without destroying/instantiating back the object.
Describe the solution you'd like Add a new method SetPlayerObject like the ChangeOwnership method.
This is related to NCCBUG-15
hey @NaolShow ! would you like to give a better understanding of what you are trying to achieve? we'd like to know why you want to change your local PlayerObject at runtime, use-case-wise?
Hi @MFatihMAR !
One of the use case is if your game is based on changing character. (I have no example in my head, but there is few indie games that are based on that). So to keep track of the current controlled creature by the player we would need to change it's Local Player Object.
Also, for me (in my game) there is another case. When a player joins a server, a Lobby Player is created, then when the game start, all the players get a new GamePlayer object, here it's simple I just use the NetworkObject.SpawnAsPlayer so that the GamePlayer is set as the client's local object.
BUUUTTT, when the clients get back to the lobby (at the end of the game), I destroy the game players (by the way there's also some problems on this side see #902 ) and after destroying it, I would like to set back the lobby player as the local player for each clients. So as a fix, for know I just set manually the NetworkClient.PlayerObject to the lobby player object (I didn't test if this is networked, I think no)
But I am remembering something, I think that when I spawned my game players as the local object, the lobby players was still having the IsLocalPlayer flag to true even if the Game Player have been spawned, is this a bug or an intended behaviours ?
Thanks!
Should be doable - SpawnNetworkObjectLocallyCommon already handles overwriting the player object. Would require changing reference on NetworkClient, IsPlayerObject, and creating a new message type to synchronize the change.
This won't make it to the top of Unity's backlog any time soon, but community contributions are welcome.