JohnTube mod

About

Username
JohnTube
Joined
Visits
2,873
Last Active
Roles
Registered, Moderator
Points
335
Badges
16
  • Re: PUN reconnect / player actorID

    Hi @Bonzy,

    Photon keeps same Actor Number (in PUN it's called Player ID) when you rejoin properly.
    To rejoin properly:
    - Use/re-use unique UserIDs.
    - Set RoomOptions.CheckUserOnJoin = true when you create rooms (should be the case by default for PUN if not hidden already)
    - Set RoomOptions.PlayerTTL > 0 or RoomOptions.PlayerTTL = -1 when 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. -1 or int.MaxValue mean actor never time out and can stay inactive inside the room forever.
    - Call Rejoin with 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.

    ReconnectAndRejoin is 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.
  • Re: PUN Reconnect

    Hi @Bonzy,

    Solved it by adding an ID for each message sent, the reconnecting user sends last received ID.
    Your solution looks good yes.
    Is this the way to go
    It 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).
  • Re: Custom room props: Custom objects ok?

    Hi @xblade724,

    Yes you should be able to do so.
    You may need to register this custom type.
    I think those can't be used as Lobby Properties and as a filter for matchmaking though.
  • Re: Price question about 100CCU 60-month buy

    Hi @xblade724,

    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.
  • Re: Seeking clarification on IsOpen and IsVisible

    Hi @xblade724,

    To not get confused let's use IsVisible and IsOpen only. And I think you meant "IsOpen" when saying "IsClosed". Anyway, I edited your questions:

    If I make it IsVisible = true, IsOpen = false, people won't automatically joinRandomRoom() into it, right? In other words, will it skip this room, or will it fail to join?
    Yes; the room will not be available for random matchmaking.
    If IsVisible = true, IsOpen = false, I can still view room properties in the lobby but just can't join, right?
    Yes; only expected actors or inactive actors can [re]join. New actors will get an error.
    If I set IsOpen = false, this will even block reconnections with TTL remaining, right?
    No; expected actors or inactive actors can still [re]join. New actors will get an error.