Errors from a client joining a room the moment it becomes empty


I'm running into an interesting problem with the following steps:

1. A client creates a room as the master client.
2. The master client leaves.
3. At the same time (or very shortly thereafter, probably based on latency), a separate client joins the same [now empty] room and takes over as the master client.

From that point on, the game works as I'd expect until leaving the room, at which point player objects aren't cleaned up. I'm relying on Photon to clean up player objects automatically, so I did some digging around that setting. I found that joining a room this way causes the room's RoomInfo to get set up with nearly empty settings. RoomInfo.maxPlayersField is 0 and RoomInfo.autoCleanUpField remains false, although the room was initially instantiated with max players of 4 and autoCleanUp set to true.

Does the RoomInfo get lost as the last player leaves the room?
Is there something I should be doing to better handle this case?



  • edited January 2018
    From my experience, I would suggest using CustomProperties of the joining player to save the room's info. Check from Lobby on what the room's info and properties are, save whatever necessary data to the player, then whenever a MasterClient leaves, set the room's info to that.

    EDIT: I'm re-familiarizing myself with RoomInfo and the above suggestion may prove more difficult than it's worth. I'm not so sure if you're able to set RoomInfo from inside a room as oppose to in the Lobby. I think you may be better off making that joining client create a new room rather than taking over a closing room. Still, it's worth a try for both approaches if you have time.
  • Hi @DavidKnopp,

    Thank you for choosing Photon!

    As @AndyWasHere suggested, I think the issue here is that you are getting wrong values because you are trying to get it from RoomInfo class and not from Room class (I don't know from where you got that btw), please get those from
  • Hey @AndyWasHere,
    Thanks for your insights! Yeah, from my tests yesterday, I wasn't able to find a method for re-enabling the auto-cleanup feature from within a room. I'd have to agree that the best method is probably just creating a new game. Were you thinking I could simply detect the bad state and force the joining client to leave/create a new game? Or is there a way to prevent the initial join altogether that you know of?

    Sorry, I was trying to be specific, but I think I ended up being misleading instead o:) . The values I'm reading from are from, I was just mentioning the base class members because I was following their internal initialization.
  • JohnTubeJohnTube mod
    edited January 2018
    Hi @DavidKnopp,

    Do you use Webhooks?
    I mean could it be that the room state is being saved (after the room becomes empty) and loaded by the actor who joins/rejoins?

    In your repro. scenario,
    How long does it take to go from step 2 to step 3?
    In step 2 how does the master client leave?

    What PUN version are you using?
    Photon Cloud or Photon Server?
  • Hey @JohnTube

    Ah, thanks for reminding me of that!

    I am using Webhooks.
    I'm able to go from step 2 to 3 up to around 3-4 seconds after the host leaves.
    Master client leaves by calling PhotonNetwork.LeaveRoom()
    I'm using Photon Cloud and PUN v1.86.

    I think the problem may lie within a work-around to an issue just like this.
    Games were getting created if they didn't exist, even though I'm using PhotonNetwork.JoinRoom. Unfortunately, setting IsPersistent to false didn't fix the issue in my testing. So, my solution was to keep track of the room list locally using OnReceivedRoomListUpdate() and only join rooms contained within the list. This fixed the room creation problem, but my guess is rooms aren't cleared out after getting closed in time if you try to join one as it's closed. However, OnCreatedRoom() isn't called, so it appears that the room is in the middle of closing.

    I'm not very familiar with the webhooks - is there settings that I should take a closer look at that would help prevent this situation, perhaps?

    Thanks again!
  • Hey @JohnTube

    Ah, thanks for reminding me!

    I am using Webhooks.
    I'm able to go from step 2 to 3 up to 3-4 seconds or so after the master client leaves.
    The master leaves the room with PhotonNetwork.LeaveRoom().
    I'm using Photon Cloud with PUN v1.86.

    I think the problem lies with a work-around I implemented for an issue exactly like this one (though no PlayFab in my situation). Games were getting created when trying to join if they didn't exist, even though PhotonNetwork.JoinRoom is being used. I tried experimenting with the IsPersistent flag in the webhooks settings, but that didn't fix the issue in my testing. So, I'm now caching the room list in OnReceivedRoomListUpdate() and checking that before joining. This allows me to avoid calling PhotonNetwork.JoinRoom when a room doesn't exist, but my guess is stale rooms remain in this list for a bit, letting users join games as they close.

    I'm not too familiar with webhooks - is there settings that you'd recommend looking at that could potentially prevent the issue of clients joining games as they close?
  • Hi @DavidKnopp,

    I'm curious; why do you need Webhooks in the first place?
    Do you save and load room state? What web service do you use?

    I'm not too familiar with webhooks - is there settings that you'd recommend looking at that could potentially prevent the issue of clients joining games as they close?
    Please add "AsyncJoin" key with value "false" to disable that behavior of calling PathCreate, Type="Load" when you call PhotonNetwork.JoinRoom when it does not exist. You may need to re do the setup all over to add a key/value. Please choose Webhooks 1.2 as it's the recommended now.
Sign In or Register to comment.