Help with disconnects during load

EricS

Hello. Our team is continuing to see players of our game getting disconnects. We have recently updated to Pun version 1.9.4 based on the recommendation here:
https://forum.photonengine.com/discussion/comment/44398#Comment_44398

I have a couple of additional questions as I try to make improvements to our games loading sequence as the majority of our disconnects happen here.

Question #1. In the "Platform Specific Info Unity" section under "Analyzing Disconnects" at https://doc.photonengine.com/en-us/pun/current/troubleshooting/analyzing-disconnects , I see
info on turning off the message queue during load. Our game does this as we load 2 scene files during our load. However we turn this flag back on mid way through the load after the scene files are loaded. At this point,
we still have several prefabs which need to be instantiated. The flag must be turned back on as the load sequence relies on RPC calls.

In this same "Platform Specific Info Unity" section I notice a description of a process to implement a background thread to call "SendOutgoingCommands".

Would it be beneficial to add a background thread to do this after we have turned the message queue back on?

Question #2. Looking at our loading code, I noticed that in some places we are performing initialization of our network gameobjects in the Start(). Instead the documentation indicates we should use OnPhotonInstantiate(). It appears that Start() is called after OnPhotonInstantiate so I am not aware of any problem with our use of Start(). Right now we aren't using the a prefab pool implementing IPunPrefabPool.

Are there any issues where using Start() is unsafe for initializing network objects?

Tobias

Would it be beneficial to add a background thread to do this after we have turned the message queue back on?

The background thread is only needed when Unity doesn't call Update() for a bit. This happens when you load scenes but I think it can also be caused by loading assets. This may depend on how you do that.

I would suggest to modify PhotonHandler.FallbackSendAckThread() to not check !isMessageQueueRunning. Instead, it could SendAcksOnly() whenever more than 200ms passed without sending anything (which is controlled by the Update() loop).

We did that for PUN 2 and it should cover loading assets. It may improve your case.

Are there any issues where using Start() is unsafe for initializing network objects?

OnPhotonInstantiate() is optional for cases where you want to setup an instantiated object (as opposed to any new object). It gives you a little control over the execution order but you don't have to use it.

Using Start() is fine, as the PhotonView does some initialization in Awake() earlier. Keep in mind that Start() is only called once, which makes a difference when pooling. In PUN 2, we suggested to use OnEnable and OnDisable to reuse/pool objects.