OK, I'll look into doing that. I don't have much experience with redis, promises, async and even javascript but I'll see what I can do.

Thanks.

Looking at the code it seems like maybe I should look at this.presence.smembers(roomName) to get a list of all rooms (not just the available ones). Does that sound like the right thing to check to make sure I am not creating a roomId which already exists?

Thanks. That sounds great. Since javascript is single-threaded, I should just be able to check the proposed roomId on the server, right?

Could you point me to the property or method to get the room IDs on the server?

Thanks.

Is there a way to choose or influence what the roomId will be when a new instance of a room is created?

For example, if I do something like

gameServer.register("chat", ChatRoom).then((handler) => {
  handler.
    on("create", (room) => console.log("room created:", room.roomId)).
    on("dispose", (room) => console.log("room disposed:", room.roomId)).
    on("join", (room, client) => console.log(client.id, "joined", room.roomId)).
    on("leave", (room, client) => console.log(client.id, "left", room.roomId));
})

and set max clients to 2, when a new client joins the "chat" room then a new room instance gets created with a unique roomId. That's great, but the room IDs are not so friendly and so if I want one player to give his room ID to another so they can play in the same game, I would like friendlier room IDs. Can the server (or better yet the client) somehow influence the room ID either by choosing it directly or providing a suffix or prefix?

Thanks.

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.

I understand that I'm supposed to call setState to initialize my state and that state gets synced. I understand that I should call @nosync for properties inside my state that I do not want synced.

What happens if I have properties in my room outside the state without @nosync? For example, if I do something like the following, will the secrets property get synced?

export class BattleRoom extends Room {

  onInit (options: any) {
    this.setState({
      players: {}
    });
    this.secrets = {x: 1, y:2}
  }
  // other code omitted
}

I see that if the server room state is mutated then the client room state is automatically updated to match the server room state. But what happens if the client room mutates the state? It looks like the client state mutation is NOT synced to the server. This is actually what I want so that is great, but I just want to verify that.

So if the client mutates the room state:

1. Can someone confirm that the mutation is NOT sent out anywhere?
2. Can someone confirm that future changes to the server room state still get synced to the client?
3. Any other things to be aware of if the client tries to "cheat" by messing with the client room state?

Thanks.

@endel Sounds reasonable to me. I'm just not used to discourse I guess. Thanks.

Thank you for producing the Colyseus software and creating this forum.

Why does signing up for the forum require consenting to data harvesting and receiving emails? I would like to be able to search the forum but doing so requires signing up. Signing up requires checking two consent boxes agreeing to have my information harvested and getting digest emails. Is this really necessary?