You will not be able to easily restart game loops and etc after the server restarts. The best you can do is persist the relevant state to the DB and load it when the room is created again.
Hi @DenisNP, welcome. This is not available at the current state of the framework.
The only encoding option the framework provides today is a binary-diff using fossil-delta. The diff transferred to all clients consists in diff of the msgpack-encoded version of the previous state with the current one.
A custom state encoding would be necessary to allow this behaviour.
I do not have a solution strictly speaking to counter the problem in a "clean" way, only a way to circumvent the problem by adding a condition that would remove an element of the dictionary if it already exists
Hi @Oviol, this sounds really good, sorry the delay to reply here. Would you mind creating a pull-request in the colyseus-unity3d project with this update?
Cheers!
Hi @donghung, have you tried replacing the file mentioned by the author? (https://github.com/deniszykov/msgpack-unity3d/issues/21#issuecomment-451642818)
I don't have Unity3D installed right now. Let me know if it works for you!
Awesome, feel free to share what you are doing here on the forums or the Discord chat! Not many people are using the Haxe client yet! Good luck with your project!
@endel said in listen event disconnect on client and server:
Hi @jack1604, that's a good question, the client reference you're using on this.send() is the one that has been disconnected. The new - reconnected - client will be returned from the allowReconnection() method.
Example:
try {
const reconnectedClient = await this.allowReconnection(client, 20);
this.send(reconnectedClient, reconnectedClient.sessionId + ' rejoined');
} catch (e) {
console.log(e);
}
Hope this helps! Cheers!
hello,
if client disconnect or leave room , it will receive event on room.leave(), how to detect it is disconnect or leave room? because if client is disconnected, client will rejoin. if client leave room, client will not rejoin.
Hi @jack1604, you're on the right track.
You must have a way to identify users uniquely, not based on client.id or client.sessionId for that. Ideally you'd use authentication (onAuth) with an external service, which will ensure you'll have a unique id per user.
The client.id will be the same if you open multiple tabs in the same browser. You can use that for testing. Not suitable for a real scenario, though.
Having this unique id, you can create a map of player by ids (e.g. this.players), and close his previous connection, exactly as in your example:
var old_client = this.players[userId];
old_client.close();
Cheers
Hi @jack1604, welcome!
Sorry, this was a bug introduced on the latest build, this has just been fixed on 0.9.24. Please upgrade, and you should be fine!
Cheers, happy holidays!
Hi @Enriqueto! Nice to see you around here! Are you locking the room after the match has started?
Maybe the second player closed the connection - which freed up space for another user, you when you called to join it again, you could be matched against yourself. Is that the case?
Happy holidays!
Cheers
Hi @davidhoare, welcome!
This is the classical mistake regarding the this scope in JavaScript, no worries, everyone's been there! Here's a related discussion in the forum.
To preserve the this scope in JavaScript, you can either use this.botUpdate.bind(this), or create an arrow function.
Examples:
// using Function.prototype.bind
this.clock.setTimeout(this.botUpdate.bind(this), 1000, {botID : data.botID});
// using arrow functions (block)
this.clock.setTimeout(() => {
this.botUpdate();
}, 1000, {botID : data.botID});
// using arrow functions (single line; shorthand)
this.clock.setTimeout(() => this.botUpdate(), 1000, {botID : data.botID});
Hope this helps! Happy holidays!
