this is excellent plugin,
however how can I change the "END POINT" property ( URL of Colyseus srv) from the C2 script itself,
now url needs to be hard coded through properties dialog which makes it very difficult to run both
debug and release versions of game, there is a need to contact two different servers.
It would be very handy feature to give the server URL as parameter to Colyseus.Connect( any server name here)
instead of editing xml file by hand:
<instance type="Colyseus" uid="3">
<properties>
<end-point>wss://srvnamehere</end-point>
</properties>
</instance>
@mdotedot now to think of it. Perhaps static/02-state-handler.html does not work for you because you don't use haxe rc2 to compile server. Thing is that haxe prior to rc2 will still compile the js server code but it will be ES5 javascript. Code generated in this way does not work with states for example; perhaps I need to add some compilation error for this case.
So you need to be sure that js got generated with ES6 features with classes and all that. Check generated index.js - it should contain classes, something like this: class server_rooms_StateHandlerRoom extends colyseus_server_Room
First off, you shouldn't do this. It's meant to be a state, which holds data. Not a lot more than that.
That said, if you really want to, you can add a @nonenumerable or @nosync attribute to the room variable. to make it not serialized.
This week I've worked on :
Player in Seat - ServerSide
TurnBased RoomType: NextTurn, isTurn
MasterPlayerID for Client Side logic Room Type
Lock Mechanism
The lock mechanism was flawed by not release locks and to not compare clientside grid with serverside grid.
CLIENT
For example when the client pushes a block from position 25 to 15 it will need to send 15=0,25=2,35=1000 to the server and request a lock on them:
grid[15]=0; // free space
grid[25]=2; // block
grid[35]=1000; // playernr
SERVER
Server receives the lockrequest (15=0,25=2,35=1000)
It checks his own grid if the positions match the client request lock. If the grids are out of sync it will send an error back.
The client will then request a complete grid from the server as it is apparently behind.
If the server grid position matches the requested lock positions a lock will be attempted: (pseudo-code)
attemptposition=new Array();
isOK=true;
for each lockposition{
if(isOK && gridlock[lockposition] == 0){
gridlock[lockposition]=time;
attemptposition.push(lockposition)
}else{
isOK=false;
// there is a lock on one of the
for(each attemptpositon p) gridlock[p]=0;
}
}
When the server was able to lock all gridpositions it will send a success to the client
CLIENT
The client will do a grid request if the return state was an error.
The client will send the changed data to the server when it was success, otherwise it will not do the move as there was/is a lock.
SERVER
When server receives the griddata it will set the new grid values and afterwards set the lockpositions to 0-time.
After each request the server checks the gridlock table if the currenttime - locktime > 2 seconds .. when it finds one it will reset the lock.
CLIENT
Sends unlock to server.
A room with four player-bots ran for over 4 hours and still they were in sync.
Next I will need to figure out how to do classes with overloading / inheritence in TypeScript.
I want all the room types to share code that are common in all rooms.
For instance I need PlayerInSeat, PingTime, getPlayersInRoom etc.. code in all typescript rooms.
Hi @DinhNguyen,
The requestJoin() method has a isNew as a second argument, you may check for it whenever requesting to join a room with a password.
Example:
requestJoin(options, isNew) {
if (options.password) {
// this forces to accept only if a room already exists
return this.password === options.password && !isNew;
} else {
// always dissallow joining without a password
// (you may want to change this)
return false;
}
}
I haven't tested this code, you may need to modify it slighly
hey @henrydavidzhu, you can always find the latest colyseus.js file here: https://github.com/colyseus/colyseus.js/tree/master/dist
colyseus.js: server error: no available handler for "1mnyb24wwjtwkdbld"
This error means you're trying to join a room handler named "1mnyb24wwjtwkdbld" that doesn't exist. You must register the room handler in the server.
gameServer.register("1mnyb24wwjtwkdbld", YourRoomHandler)
class YourRoomHandler extends Room {
// ...
}
I highly recommend you read the documentation:
https://docs.colyseus.io/server/api/
https://docs.colyseus.io/server/room/
@DinhNguyen and @rscata I think you both are looking for rejoin the game. Below snippet will solve your problem. For more details: Rejoin Link.
async onLeave (client, consented: boolean) {
// flag client as inactive for other users
this.state.players[client.sessionId].connected = false;
try {
if (consented) {
throw new Error("consented leave");
}
// allow disconnected client to rejoin into this room until 20 seconds
await this.allowReconnection(client, 20);
// client returned! let's re-activate it.
this.state.players[client.sessionId].connected = true;
} catch (e) {
// 20 seconds expired. let's remove the client.
delete this.state.players[client.sessionId];
}
}
Sorry to reply to an old post but this was the one that finally helped me understand how to use listen so I thought it might be helpful to clarify for other users who are as dense as I am.
The documentation for listen at https://docs.colyseus.io/client-state-synchronization/ is painfully terse and confusing especially in how it uses the colon (:). From my understanding, if you have something like the following as your state:
{foo: bar: {baz: 'somevalue'} }
then you can listen for baz via
room.listen('foo/bar/baz', ...)
or via something like
room.listen('foo/:wildcard_1/:wildcard-2', ...)
That is you can either use the exact path or use wildcards but the text after the colon has no special meaning. I kept thinking that the :id and :attribute wildcards in the docs had a special meaning.
Hope that helps others who got confused like me.
Thanks again.
Excellent! Thanks for the quick response.
I was confused on this so I'll summarize in case others come to this post in the future.
The @nosync decorator is needed because you might create an object foo that will be inside the state object and foo has properties bar and baz with bar being visible and baz being private. You would then use @nosync on baz since it is something inside the state that you want private. But for just other properties of the room but outside the state, those will not be synced.
