Hi @jdavid, welcome 👋

Unfortunately you'd need to implement these features yourself. There are no rules for password besides that it has to have > 2 chars https://github.com/colyseus/colyseus-social/blob/master/src/index.ts#L106-L109

Cheers

Hey @TeeTeeHaa, the Room in the client-side is supposed to expose all its useful events as callbacks (onLeave, onStateChange, etc), I might be wrong but I can't see an explicit advantage for declaring your own room class as opposed to doing what's provided & documented, such as:

try {
  const room = await client.joinOrCreate<MyState>("room", {});

  console.log("client joined!");
  room.onLeave(() => console.log("client left!"));
  room.onStateChange(() => console.log("state changed!"));

  // (...schema callbacks)
  room.state.players.onAdd = (player, key) => {/* ... */};

} catch (e) {
  console.error(e.message);
}

You'd generally create your own wrapper for the room on the client-side, connecting its events with changes in your client's UI and representation of the game state.

If you have a better proposal for dealing with this on the client-side I'm all in, though. Just have to convince me and other team members :D

Hi @govem, welcome 👋

This should've worked, can you provide a reproduction scenario where I could inspect this problem? Are you using @filterChildren() as well?

Hi @TeeTeeHaa,

I'm curious why you'd prefer extending both the Client and the Room rather than dealing with their instances?

IMO if something useful on userland could be achieved only by extending the room that's something the implementation should provide to you instead of forcing you to extend it like this.

You could extend as you've mentioned, but as you're going to deal with internal methods, they can be changed on future releases

That's lovely @davidhoare ❤️ Thanks for sharing!!

Hi @lee-orr, that is a really good question, and something we should think about for improvement in the future.

To allow "filtering by distance", I've used this piece of code on the pixijs demo:

entity['$changes'].touch(0); // 0 means fieldIndex: 0

Instances that should be re-evaluated need to be flagged as "dirty" by using this workaround.

I hope this helps! Cheers!

Hi @laladehulu, welcome 👋 glad you’re enjoying it so far!

Only state mutations (state changes) are broadcasted to all clients at every patch. Not the entire state.

If you’re making a browser game you can check the Network tab in the developer tools to check how many bytes you are receiving constantly.

If you’re not using any type of interpolation the experience will indeed feel laggy, even if played locally. The most simple approach you could take is using “lerp” (linear interpolation)

Hope this helps, and hope you stick around! Cheers!

Hi @tobspr, welcome! 👋 You did a great job digging the sources! Awesome!

It is very unlikely that the processId is going to collide when spawning a small number of servers, though. Ids are generated using nanoid which does a pretty decent job. Maybe ids could collide if you have an insane amount of ids to be generated at exactly the same time, like +10,000

Have you experienced some issue when deploying on multiple servers? If so, it may be that the issue you're experiencing has a different cause than processId collision.

Cheers!

Hi @TeeTeeHaa, I see, well there are many ways to go about this, If you'd like to use a traditional cookie/session, you can use this as a starting point: https://github.com/endel/colyseus-express-session (this example does not use the very latest version of Colyseus, but the sources should look exactly the same using it)

If you'd like to manually control creating and/or using an existing room by yourself, I'd suggest creating an HTTP route for that (e.g. GET /reserve-seat/), and returning a seat reservation (using any of the matchMaker methods that return a "seat reservation" from the server-side), and then consume the seat reservation from the client-side (.consumeSeatReservation()).

Generally using .joinOrCreate("xxx", {...}) is enough, but if you have a very specific use-case you might be better off making your own logic as described above.

I hope this helps! Cheers!

Hi @TeeTeeHaa! 👋 Can you explain your use case describing the real user interaction with the game? It may be easier for me to understand what you need starting with the problem first rather than the solution.

Can I cram all my authentication and my matchmaking and my asychronous code (async, await, promises, etc) into that function?

The verifyClient callback can only deny connections directly before they reach the Room's implementation, the scopes you have there are very limited, and you won't be able to exchange any messages during that, so "matchmaking" can't be done there

Glad to have you here, I hope you stick around! :)