Multiplayer - On Peer Leave Room

0 favourites
  • 5 posts
From the Asset Store
Add calm and a lounge vibe to your games with these 8 tracks
  • Hello!

    Had two things I wanted to ask/share:

    "PeerCount" doesn't decrease when a peer uses "Leave Room"?

    Was testing last night, and can reproduce today still. When keeping track of "PeerCount" on both host and peer, and then having a peer join the same room as host, then both host and peer will see "PeerCount: 2", which is good.

    However, when the peer uses "leave room", then the peer will successfully leave and the peer's "PeerCount" goes to 0, but the host doesn't get any indication that the peer left and still see "PeerCount: 2", even after many minutes passed.

    Is this by design?

    This is important as if a player wanted to leave a room without restarting the game, they cannot gracefully leave. "On Peer Disconnect" does not trigger either.

    Here is a c3p file reproducing this effect. If anyone is happy to test this too? (You may want to change "Instance" when connecting to the game, as if anyone else tests, the peer count might be higher!)


    1. Preview the above C3P file, then hold ALT and click Preview to open a 2nd window.
    2. You will now have 2 preview windows. Reading the log, you will see one says "You are Host!" and "You are Peer!".
    3. Observe the "Peer Count" on both, it will be 2, which is correct.
    4. On the "Peer" window, click "Leave Room", you will see your PeerCount goes to 0, but then look over at Host, it still reports "2" and has no idea about the peer leaving the room. "On Peer Disconnect" doesn't trigger either.

    Scirra's Signalling Server Status

    Is there a way to see the status of the Scirra signalling server? Even things such as planned maintenance, just so we can know whether to debug our project extensively or not? I spent way too much time reviewing my events thinking I've messed something up.

    Below is my experience which I wanted to document as it was starting to get a bit tiresome troubleshooting the issue.

    Last night I was experiencing this very frequently, I left my project in this state as I couldn't resolve it, but testing this today without editing any events, I now cannot reproduce the issue anymore, it just works flawlessly... I had spend hours investigating this last night and still got the issue, but now it's ok and I'm not sure why.

    I've made a minimal c3p file that I will test if I find this issue happens again, and if it happens I will video record it as it may suddenly fix itself again in later hours.

    I was getting different results when doing the exact same motions of "Click preview, have two previews open, connected to signalling server, join same room on both preview windows", but once both windows have joined the room, either it would work fine, or the peer would simply be unable to send messages to the Host.

    I was definitely looking at the correct window, as I've plastered my project with debug info (which I've more than double-checked).

    The debug info logs any errors from the signalling server (none were appearing), and also logs all messages with "On Any Message Received", with no conditions other than to append text to a text object (that is onscreen at all times). All current room information is always displayed, the HostID is displayed, everything looks absolutely correct logically, but if the peer sends a "HelloHost" message (mapped to a key as a debug test, and I tap it multiple times), I can see the peer's log say that I've attempted to send the message to the host, but the host will either receive this or not (as in, I can send "HelloHost" multiple times, and the host will not receive ANY of these, or any other messages that I've programmed so far, even though debug info says we are in same room, peercount is 2, HostID is accurate when compared to the Host window, whether I change the message recepient to "" or muliplayer.hostID). But then, I could click preview again right after experiencing this, do the same exact steps, and it will just work, all accurate information, and the debug button is working and Host receives all messages. I did not pick "Unreliable" in any of my events, and had tested both "Reliable ordered" and "Reliable unordered".

    I left the project last night in this state as I was so bewildered as to what the issue is, and now I test today and it's working perfectly.

    EDIT3: Restructured whole post.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • Unbelievably, this "Host not receiving peer messages" issue started happening on my project again just now, so I tried the test minimal c3p file that I prepared so that I can rule out my project, and it is reproducible!

    C3P file:

    I recorded the behaviour with OBS, please view here (0:38 long):

    Subscribe to Construct videos now

    In the video, I do the following (Bare in mind it's random and very lucky I caught it like this):

    1. Click preview.
    2. Click preview again with ALT (to create extra window).
    3. Join room on Left Preview.
    4. Join room on Right Preview.
    5. I click "Send Hello" on peer, several times, you see peer's log say "Sent" so button is functional.
    6. I click over to Host, and nothing appears on the log. Notice the "PeerCount" is 2 on both previews, so same room.
    7. I click Preview (didn't touch any events).
    8. Repeat steps 3, 4.
    9. I click "Send Hello" on peer, several times, and it sends through and the Host log see's the messages.

    Is this a Multiplayer Plugin bug, or a Signalling Server bug, or something else entirely?

    I will look into filing a bug report (Haven't done one on github before).

  • Hi, I appear to be having similar issues. Did you ever figure this out?


  • Leave room is a signaling action, which will leave the signaling room. This does NOT disconnect the peer from the host in the current connected session.

    Use the disconnect action instead, which will disconnect from the current session, AND leave the signaling room.

  • Leave room is a signaling action, which will leave the signaling room. This does NOT disconnect the peer from the host in the current connected session.

    Use the disconnect action instead, which will disconnect from the current session, AND leave the signaling room.

    man, you just saved my first project, i was freaking out, thanks

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)