[UNITY PUN2] Sending network data when Time.timeScale is at zero
Options
In my game, when the round ends, I set Unity's timeScale to 0 to freeze the background and overlay a UI. When the master client, presses continue I use PhotonNetwork.LoadLevel. However, this level change is never communicated to the other clients. I've tried using RaiseEvent to tell the clients to reset their timescale back to 1 and I've tried using RPCs. Is there any way to send network data while Time.timeScale is zero?
Thanks in advance!
Thanks in advance!
0
Comments
-
I am having this same issue. In my case, I am starting out a loaded level as paused(0 timescale) until all players are loaded. But player properties are not synchronized when Time.timeScale is 0. I'm not sure, but I think this used to work in PUN 1.1
-
Any workarounds for this issue?0
-
It's not ideal, but I set the time scale to a 0.01 and then back to zero every couple frames to check for any network changes. I'm fairly certain that a previous version of PUN2 didn't have this issue. Hopefully, a PUN2 dev will look into a proper fix.jRocket said:Any workarounds for this issue?
0 -
Hi @TheSLAP,
Thank you for choosing Photon!
What is not working exactly when Time.timScale is set to zero? (Level sync, is that it?)
What is the expected behaviour and current behaviour?
How can we reproduce with minimal steps?Is there any way to send network data while Time.timeScale is zero?Actually PUN uses Time.realtimeSinceStartup which is independent from Time.timeScale. See "PhotonHandler.cs".
Hi @jRocket,But player properties are not synchronized when Time.timeScale is 0How do you set player properties? and what made you say this and come to this conclusion? how did you test this?
--
What PUN version and Unity version do you use to reproduce this?
Does this happen in editor and in build? which platforms?0 -
@JohnTube I had this happen in my own game while switching scenes and waiting for other players to switch. I have a matchmaking/lobby unity scene, and whenever the players are ready, an RPC is sent out to request that each client change the scene to the game scene. Then, whenever the scene is loaded, I set a player prop to indicate that the player has loaded the scene, and set the Time.timescale to 0 until all players have set that prop. However, that player property is never replicated over
I'm not sure if it's an issue sending it or receiving it.
The Asteroids demo does the same thing with player props, and I was able to reproduce my issue by setting Time.timescale to 0 in the Start() method of the AsteroidsGameManager. When doing that, OnPlayerPropertiesUpdate is never called so the game doesn't know if the other player has loaded the scene.
I using PUN 2.12 on Unity 5.6 on Windows, testing with 1 client on the Editor and 1 on a development build. Hope that description helps.0 -
Maybe another thread, but photon clients don't receive PunRPC calls when their timeScale is 00
-
We have faced the same issue, but after we changed it to Update, it started working fine. As you have mentioned, what are drawbacks of doing so? Please explain. Will you fix it in future updates?0
-
I am experiencing issues connecting to the master when timeScale is set to 0. Once I set timeScale back to 1, it instantly connects.
Is there any way to get Photon to connect without having to reset timeScale?
edit: I was able to fix it by setting PhotonNetwork.MinimalTimeScaleToDispatchInFixedUpdate in my script that changes timeScale.0 -
-
-
Sorry to ressurrect this thread, but I was having the same issue and lost many hours trying to understand and workaround it.
Here's the solution I found (combining also mrbug2's solution presented above, but hopefully being less stable due to changing PUN's code less): Add this code to PhotonHandler.cs:
/// <summary>A workaround to continue sending RPC calls if timescale is ZERO</summary>
protected void Update() {
if(Time.timeScale == 0f) {
this.Dispatch();
}
}
It will simply change to dispatching in update when Timescale is 0.
I've tested and it is working to send and receive RPCs at least (which is my use-case).
0