Clearing QueuedOutgoingCommands & QueuedIncomingCommands
Options
Is it possible to manually clear all networkingPeer.QueuedOutgoingCommands and networkingPeer.QueuedIncomingCommands so that none of the commands/RPC's are sent or processed?
The reason I ask is that when I load a new scene, but remain in the same room, I would like to prevent rpc's sent in the previous scene from arriving in the new scene. The scene would essentially start with a clean slate.
What I would like to do is:
1) setting isMessageQueueRunning to false
2) loading the new scene
3) clearing the outgoing and incoming commads in Awake()
4) setting isMessageQueueRunning to true
I imagine an alternative approach would be to change rooms between scene loads.
Thanks.
The reason I ask is that when I load a new scene, but remain in the same room, I would like to prevent rpc's sent in the previous scene from arriving in the new scene. The scene would essentially start with a clean slate.
What I would like to do is:
1) setting isMessageQueueRunning to false
2) loading the new scene
3) clearing the outgoing and incoming commads in Awake()
4) setting isMessageQueueRunning to true
I imagine an alternative approach would be to change rooms between scene loads.
Thanks.
0
Comments
-
That's tricky.
While you load, you won't create updates (Update() is not called by the engine) and you at least don't have to clear outgoing stuff.
You don't really control when other clients are switching levels and much less how fast they are done doing so. If you just drop all messages without looking at them, you might miss info that targets the new scene or "i loaded everything, too" messages.
You can have a look at the PUN 1.19's synchronized level loading. This should do the trick in most cases or give you a hint what we think should be done.0 -
Hi Tobais
I think I would encounter the same issues using synchronized level loading since rpc's sent from the previous scene could still potentially arrive in the current scene.
My solution was to increment all the scene view ID's by one on every scene load, so the old rpc's won't correspond to the correct scene owned game object if they arrive in the next scene. It's not bullet proof, but its good enough for now.0 -
Hm, right.
You could also use the Level Prefix. It's like your solution: A prefix defines which level you are currently in and the RPCs and updates with other prefixes are ignored.
Sadly, it's not bullet proof either. As you only get buffered messages (like RPCs) once when you join the room, it means dropped RPCs are gone for good, unless you re-join the game.
Actually, it might be the best solution not to cram multiple scenes into one room. What's the benefit?
Or, if you do, use only a few fixed PhotonViews that are the same in all scenes. You can still communicate with those. But you loose the ability to use the IDs. This renders parts of PUN into non-used framework and you could better implement this with the Unity Client SDK and it's "plain" API. You get more flexibility out of that.0 -
Level prefixes work perfectly, thanks!
The benefit of using a single room is quicker load times between scenes which is quite important as the game has frequent level changing and restarts.
For interest sake, this is the game I'm working on: http://steamcommunity.com/sharedfiles/f ... d=93927889
What does the Unity Client SDK refer to? Is it the built in unity networking, or something offered by exit games?0 -
I'm glad the prefixes work.
Keep in mind they discard stuff you actually received. So if your game runs a while and a lot of RPCs get buffered, this might sum up to a lot of messages loaded. Connections might fail due to excessive messages.
PUN = Photon Unity Networking. You're currently using this and it resembles Unity's built in networking.
The Photon Client SDK for Unity is more or less the foundation for PUN. It's a plain api without viewIDs and RPCs, etc. This can be downloaded from our page:
https://www.exitgames.com/download0
