As per requested by — Brace yourself, crazy instruction is coming.
Describing the problem is beyond my understanding and knowledge of what's happening, however you can read the symptom and observation here. It would be helpful if other user can understand the problem, please notify me, I will update this section. Specific test on the problem is not possible because the information of breaking change between r178 and r179 is unavailable.
However the best description I can give is, the client will be DC/kicked unnaturally after connecting to a room (duelroom) with a condition of it has joined then left other room previously (lobbyroom). This also affect all my recovery mechanism upon disconnection. Tell me if this is confusing, I'll try to rephrase.
Attach a Capx. Download link below.
Please follow the instruction carefully as the project minimized tremendously, as all fail-proof mechanism/events were removed for readability of the real problem.
- Provided capx is as minimal as it can be to simulate the problem, expect 20+ events for each capx. Tests in smaller scale than this doesn't help.
- Capx provided is in r178, so that you can duplicate it to test in both r178 and r179.
- All marked "nothing to see here" are prerequisite to re-simulate the problem, but doesn't play any role on the issue. You can Ignore these.
- Ping functionality are left for tester to play around.
Description of Capx
- [LobbyHostDFN.capx] This is the host for the lobby, which responsible to create Duelhost and managing the transfer of peer.
- [DuelHostDFN.capx] This is the duelhost for the two client in duel.
- [CCGclientDFN.capx] This is the client for the game.
Steps to Reproduce Bug, applicable for both r178 and r179
Note: this is doable with just a single type of browser.
- Open all capx in different instance of C2. [3 instance]
- If your default preview port is localhost:50000, or change the address in LobbyHostDFN.capx Line17 accordingly.
- Run Preview LobbyHostDFN.capx first and grab Localhost:50000
- Run Preview DuelHostDFN.capx second to grab Localhost:50001. If it grabbed other port, change the address in LobbyHostDFN.capx Line17.
- Run Preview CCGclientDFN.capx third and grab Localhost:50002 [important: run 2 instance/window/tab of this]
- Once you run preview all three, you can close Localhost:50001.
- By default, Lobbyhost (50000) will attempt to connect on start layout. You should see 4 logs [connect, login, joining, joined as HOST]
- By default, Client will check whether Lobbyhost is already exist or not, if yes, the go to lobby button will be enabled.
- Enter username in each client, click go to lobby. Observe the log in Lobbyhost and Client to see connection status. Play around with the ping button to see if they are communicating. If they are, they should be ready to request match.
- Click Request Match button, Localhost:50001 will popup, this is duelhost popping up. Ensure to enable popup from localhost, check your address bar.
- The process is pretty much automatic from here, both client will leave LobbyRoom upon confirmation from lobbyhost, then it will attempt to connect duelhost.
- Observe the duelhost and clients logs. See observation section. Play with ping button a bit.
Observed Result: r179
Observation from both client log r179. This is the unnatural DC I'm talking about. Ping failed.
Observation from duelhost log r179. Host failed to log leave reason, only error message managed to be logged. Ping failed.
Expected Result: r178
Observation from both client log r178. Ping works!
Observation from duelhost log r178. Ping works!
- Please read event group description to help on the investigation.
Affected Browsers: All version are latest
- Chrome: (YES)
- FireFox: (YES) Note: Lousiest of the three in term of WebRTC.
- Opera: (YES) Note: Opera seems to be second most responsive for WebRTC, after Chrome .
- IE: (WebRTC unsupported)
Operating System and Service Pack
Construct 2 Version ID