I think this addon has wrong implementation

S

sibichakravarthy

New member
I bought the asset and took a look. I noticed that you instantiate the gameobject on the masterclient first and then instantiate on the player who joined. This could lead to many problems particularly in mobile because if a second player joined a game and the masterclient went to background the player would not get instantiated and if the masterclient decided to never resume again then the next masterclient set after timeout will never spawn the gameobject because you use onplayerenteredroom callback to instantiate the gameobject which other connected clients would already have called. Also from what I can tell there is not host migration logic either. Sorry for my english.
 
When the master client goes idle the client disconnects and it's then migrated to the next client. A simple test would be to create two instances, disconnect the first, and notice that the second one becomes the master client. The SpanManagerBase handles this aspect.
 
hi I think you mean SpawnManagerBase class. I just searched your whole asset SetMasterClient is never called. You only switch when game gets disconnected which is fine for pc games but not for mobile games, I have been using pun for past year. A simple host migration would be to call SetMasterClient OnApplicationPause and SendAllOutGoingCommands immediately. even with that consider the following scenario

There are two players in the room player 1 goes to background but still in room. now player 2 becomes master.
then player 2 also goes to background. Now when player 3 joins the room there won't be a masterclient active in the room. If both clients decide to never come back player 3 will never get instantiated.

Your approach does skip use of resources folder but I don't understand why only masterclient should authorize to instantiate new players. Why not just instantiate locally and send a buffered RPC.
 
It has been awhile since I performed these tests but when I last performed them I received the disconnect callback on Android devices. Photon also automatically switched the MasterClient for me so it wasn't necessary to call that.

sibichakravarthy said:
Your approach does skip use of resources folder but I don't understand why only masterclient should authorize to instantiate new players. Why not just instantiate locally and send a buffered RPC.
Click to expand...
For that I followed Photon's recommended approach under Manual Instantiation: https://doc.photonengine.com/en-US/pun/current/gameplay/instantiation
 
Hi I just tested it is not getting instantiated. just build your demo scene and join room from mobile then go to home screen. now join from editor it won't get instantiated. If the game returns from home screen it will get instantiated. I understand you use manual instantiation but what is the need behind using masterclient to instantiate joining players?
 
Based off of those tests it does sound like PUN should issue a disconnect when OnApplicationPause is called for mobile. If I do a search it looks like they have some comments in PhotonNetwork related to that:

/// Unity's OnApplicationPause() callback is broken in some exports (Android) of some Unity versions.
/// Make sure OnApplicationPause() gets the callbacks you expect on the platform you target!
/// Check PhotonHandler.OnApplicationPause(bool pause) to see the implementation.
Click to expand...

If you reduce the PhotonHandler.Instance.KeepAliveInBackground value does it disconnect sooner?
 
Hi if you want to switch masterclient you can do like this.

private void OnApplicationPause(bool pauseStatus)
{
if (pauseStatus)
{
if (!PhotonNetwork.IsConnected || !PhotonNetwork.InRoom || !PhotonNetwork.IsMasterClient)
return;


PhotonNetwork.SetMasterClient(newMaster);
PhotonNetwork.SendAllOutgoingCommands(); // send it right now

}
}


But this should not be the approach since OnApplicationPause is called by unity when users are watching Advertisements etc. Also maybe the player you set as masterclient is also on background. I think you should just change the way you instantiate new players. I don't understand the need for masterclient to instantiate new players in your implementation.

This also applies even on PC when the masterclient gets their internet connection lost or crashed etc.
 
Last edited:
The PUN comments mention changing the KeepAliveInBackground value - have you tried that?
sibichakravarthy said:
I don't understand the need for masterclient to instantiate new players in your implementation.
Click to expand...
I was following the recommended approach by the PUN manual.
 
I think that value only defines how long a client should keep a connection in background. But since in mobile games won't run in background you should not rely on that. Why not just use PhotonNetwork.Instantiate?. If you want object to persist after client disconnect you can just instantiate room objects. I think their default solution is very robust and well though out.
 
When I initially worked on the add-on I talked to the PUN developers and they suggested the instantiation method in the docs. With that said, I am planning on revamping the SpawnManagerBase to more easily support AI agents and I can take a look at this then.
 
Thanks, I'll take a look. Instead of destroying/instantiating a new Photon Player for changing the character I would just change the character's mesh/animator. This will give you the most seamless transition and also provide the least amount of network traffic.
 
Bump! Indeed this implementation lead to some problems and have some constrains.

Justin said:
I am planning on revamping the SpawnManagerBase to more easily support AI agents and I can take a look at this then.
Click to expand...

Any ETA for this? Would be cool if the SpawnManager implement the "default" way of instantiation and be able to spawn on demand (like clicking a button - for team /character selection purpose)
 
The latest update includes AI agent support. The Spawn Manager didn't require many changes and the custom instantiation gives the best results.
 
You must log in or register to reply here.
Top