this what I searching for several weeks, thanks man that really halping me to jakarta selatanbest regards

I see! Glad you found out. There is a TypeScript configuration to prevent this from happening called forceConsistentCasingInFileNames: // tsconfig.json { "compilerOptions": { // (...) "forceConsistentCasingInFileNames": true, } } ``

Thank you for your fast and positive response, @endel. I suggest the following additional changes to make the documentation fully consistent within in itself: send(type, message) I think this should be: send(identifier, message) Send message a type of message to the client. I think this should be: Send message with identifier and payload message to the client. The type can be either a string or a number. I think this should be: The identifier can be either a string or a number. // sending message with string type I think this should be: // sending message with string identifier Because it should be consistent with: // sending message with number identifier The green "Tip - See how to handle these messages on client-side." was removed. I'm not sure whether this was intentional. I think it should come back.

Thanks @DevenWen ! A new beta is coming out soon with some good fixes and new features :)

Posting to expand on the answer, was stuck on this one for several hours. In my project I have a typescript colyseus server and a client which uses typescript, react & webpack. I had tsconfig.json in both server/ and client/ directories + a basic one in the project root with just experimentalDecorators and esModuleInterop set to true to get things going. I tried setting target to ES2016 in ./tsconfig.json and ./client/tsconfig.json but that did nothing until I added "include": ["node_modules/colyseus.js/**/*" ] into the root config. - That helped me. Hope this helps someone down the line.

what i did was create a new Helper class file (Javascript Class), then added all the Colyseus functionalities and listeners and everything there. so I can store the room in a variable there like this.room which can be accessed from any other component on my whole application. class ActivityRoom { constructor() { this.client = new Colyseus.Client(clientUrl); } connect = async (username, rating, photoUrl) => { this.name = username; this.rating = rating; this.photoUrl = photoUrl; try { const room = await this.client.joinById('AR1', { username, rating, photoUrl }); this.room = room; this.sessionId = room.sessionId; this.Room_Listeners(); } catch (error) {} console.error(error); } }; leaveRoom() { this.room.leave(); } } then call the leaveRoom like ActivityRoom.leaveRoom from any other Component i want.

I see, no problem, thank you for getting back to me

Can't make it work... Well, for now I will be using a server side "hack" to trigger the state change at the start of a match. Oh, and I also add this to the Schema.cs file to the error go away:

It was Node 15. Downgrading to Node 14 worked. On a Mac, that's rm -rf /usr/local/bin/node rm -rf /usr/local/bin/npm and then reinstalling Node 14. I created two test servers, one with typescript and one with javascript. For typescript, I had to run npm install first, then npm start, whereas with javascript npm start worked immediately. 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?

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

Thanks, this works! My client now receives new data it gains access to. It's not significant in my case (at least not yet), but the client doesn't lose access to data it had access to before - though doesn't seem to get updates to it. My hope is that if it re-gains access to that data, it'll update again, but I can't test that yet... If I have issues there I'll post again.

That cleared my question. Thank you so much!

Hello @endel . I will have a look at that example. Your recommendation regarding an HTTP route for authentication and seat reservation sounds like a better idea than the one I explained above. Thank you for your input. 👍

Hey, I was actually assuming node.processId would equal to process.pid, but since nanoid is used then the whole thing is not an issue at all - thanks for the super quick response! (I should probably have digged a bit further ...) Thanks!