Hello developers,
I'm making a game supporting drop-in drop-out multiplayer, where the state for the rooms is changed by RPCs and stored in instantiated scene objects. Now most of the time this works great, if a player drops and reconnects then the master client can resend the state when they rejoin - the problem is when the very last player disconnects (e.g. due to timeout) and then on reconnection receives the PhotonNetwork.Instantiate made objects in their original state, overriding the current ones in the scene.
Am I just approaching this the wrong way? Most tutorials and documentation recommend storing state on instantiated objects (and using observed components with OnPhotonSerializeView functions), so I went this way as it seems most natural with the API.
I don't need to support reconnecting to a totally player-less game, only reconnecting due to timeout when still in the scene room.
It seems to me that the standard behaviour for a reconnecting player should be to just carry on with the instantiated objects they own, rather than delete them, re-instantiate them, then require someone else to fill the data. This would fix the "last player reconnect" case, but also wouldn't harm the rest of the logic.
Without such a 'keep alive my own objects on disconnect' option (and I don't mean autocleanup = false, as the network instantiates replace the objects anyway), then my only options seem to be:
1) Move ALL state to room properties (a total refactor, and probably less efficient)
2) Move ALL state to un-instantiated scene objects (again a total refactor, as would still need boiler plate code to sync up visual objects to centralised state)
3) Give up on reconnecting and just re-create a new room after regaining connectivity - maybe the simplest option but annoying as I use photon room events for playfab integration.
I realise this is kind-of a rage-post, but this is a big blocker at the moment, and I wanted to know what the Photon Community would suggest. Surely someone else has hit this issue?
Thank you for your time,
Duncan Stead
I'm making a game supporting drop-in drop-out multiplayer, where the state for the rooms is changed by RPCs and stored in instantiated scene objects. Now most of the time this works great, if a player drops and reconnects then the master client can resend the state when they rejoin - the problem is when the very last player disconnects (e.g. due to timeout) and then on reconnection receives the PhotonNetwork.Instantiate made objects in their original state, overriding the current ones in the scene.
Am I just approaching this the wrong way? Most tutorials and documentation recommend storing state on instantiated objects (and using observed components with OnPhotonSerializeView functions), so I went this way as it seems most natural with the API.
I don't need to support reconnecting to a totally player-less game, only reconnecting due to timeout when still in the scene room.
It seems to me that the standard behaviour for a reconnecting player should be to just carry on with the instantiated objects they own, rather than delete them, re-instantiate them, then require someone else to fill the data. This would fix the "last player reconnect" case, but also wouldn't harm the rest of the logic.
Without such a 'keep alive my own objects on disconnect' option (and I don't mean autocleanup = false, as the network instantiates replace the objects anyway), then my only options seem to be:
1) Move ALL state to room properties (a total refactor, and probably less efficient)
2) Move ALL state to un-instantiated scene objects (again a total refactor, as would still need boiler plate code to sync up visual objects to centralised state)
3) Give up on reconnecting and just re-create a new room after regaining connectivity - maybe the simplest option but annoying as I use photon room events for playfab integration.
I realise this is kind-of a rage-post, but this is a big blocker at the moment, and I wanted to know what the Photon Community would suggest. Surely someone else has hit this issue?
Thank you for your time,
Duncan Stead
