This week I've made progress on a simple room where players can be joined and walk around.
I made it so that players would be moved simultaneous to see if the server could handle it.
It didn't quite run well with 2 or more browser sessions at the same time. Also a windows publication didn't fare well.
Yesterday I found out that the CPU on Windows and memory on HTML5 where draining. So today I made a simple version on my NyanCat project. I had it running on both html5 and windows and it had the same effect.
Then I stripped colyseus from the nyancat so that only the image was left with controlling keys and there was no problem with CPU.
With Colyseus:
And the non-colyseus version:
So Haxe client is consuming a lot of CPU !
At least it wasn't my client implementation since both have the same problem. I guess I need multiple computers from now on to do tests ....
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.
Hi @cmdt-ed,
Can someone confirm that the mutation is NOT sent out anywhere?
Only the server can mutate the state, mutations in the client-side are going to be replaced in the next patch
Can someone confirm that future changes to the server room state still get synced to the client?
Yes
Any other things to be aware of if the client tries to "cheat" by messing with the client room state?
You usually don't send messages from the client to the server telling what the state is, but rather the action a client is taking to be validated in the server-side, and then mutate the state in the server
Cheers
Hi @endel
It WORKS! Thanks a lot!
I learned just now that there're several ways of packing js. And maybe umd is suitable for CommonJS mentioned by @parkcd. So please use this way for future pack : )
@usamasermad yes, you should ensure the Client connection is open before performing a ReJoin. If you're going to instantiate a new Client, make sure it has the same client.id as the one who initiated the first connection to the room (https://github.com/colyseus/colyseus-unity3d/blob/master/Assets/Plugins/Colyseus/Client.cs#L66)
You can have global variables only if you're running the server on a single-thread. If you're running on multiple threads, you can use this.presence inside the room handler (see docs for presence api)
As @seiyria suggested, for preventing the same user for joining multiple rooms (or the same room) it would make more sense to authenticate the user, and check the database instead during onAuth. Cheers!
@ahtashamabbasse AFAIK you can't use forever with TypeScript files, you need to compile them into JavaScript and run it against the JavaScript output.
Compile the project:
tsc -p tsconfig.json
Start forever using compiled lib/index.js
forever start --minUptime 1000 --spinSleepTime 10000 ./lib/index.js
