- Last Active
- Registered, Moderator
You should disconnect when app goes to background and re connect when app moves back to foreground.
OnApplicationPauseto do so.
Read more here.6
Photon keeps same Actor Number (in PUN it's called Player ID) when you rejoin properly.
To rejoin properly:
- Use/re-use unique UserIDs.
RoomOptions.CheckUserOnJoin = truewhen you create rooms (should be the case by default for PUN if not hidden already)
RoomOptions.PlayerTTL > 0or
RoomOptions.PlayerTTL = -1when you create rooms. PlayerTTL is how long the player can stay inactive inside the room. An actor becomes inactive inside the room when it disconnects from it without leaving it for good and PlayerTTL != 0.
int.MaxValuemean actor never time out and can stay inactive inside the room forever.
Rejoinwith room name within PlayerTTL milliseconds from deactivation time. Deactivation time is when actor became inactive inside the room.
- If room becomes empty it will be destroyed after
RoomOptions.EmptyRoomTTL. A room is considered empty when there is no active actor left. A maximum value allowed for EmptyRoomTTL on public cloud is 300000 milliseconds (5 minutes). If you want to rejoin after that you need to persist room state to be able to save it and load it. We offer webhooks as a solution for this. Otherwise you may get "GameDoesNotExist" error.
ReconnectAndRejoinis a special shortcut in PUN. The above applies to it as well.- harder: keep name of room and old player ID and connect to Photon on disconnect then connect to the same room passing the old player ID also.This approach is deprecated. If you still need it passing -1 (or anything != 0) should work.1
Hi @Bonzy,Your solution looks good yes.
Solved it by adding an ID for each message sent, the reconnecting user sends last received ID.Is this the way to goIt depends on your game.is there another easier way to know that a message hasn't been received because of disconnect?No sorry. PUN and Photon Realtime in general has some reliability layer that makes use of ACKs to ensure messages get sent/resent. But in some edge cases like the one you are mentioning this does not happen.
PUN RPC are events under the hood. I'm more familiar with RaiseEvent so I will tell you about what I tried to do to solve this:
- cache event locally before sending it. use it to resend event after timeout or after recovering from unexpected disconnect.
- broadcast (send events to All including sender). receiving my own event is considered an ACK from server as RaiseEvent operation does not have operation response in case of success => remove local copy.
- cache important events inside the room.
- clean up cached events inside the room once it has been successfully transmitted. removing the event from cache is considered an ACK from target actor(s).1
You can't stack or combine the one time fee plan of 100CCUs.
If you want to go beyond you will need to purchase a monthly/yearly plan.1