Posts made by endel

Hi @kayyos, please make sure to run the same version on the server and client, they both should be either 0.14 or 0.15.

Currently 0.15 is on preview, so you can fix this by installing 0.15@preview on the client-side:

npm install colyseus.js@preview --save

Hope this helps, cheers!

hey @Rangerz132, welcome!

onAdd is only called for "collections" of items, you could attach the onChange callback directly on it:

this.room.state.mole.onChange = (changes) => {};

Alternatively, I'd suggest using .listen() instead:

this.room.state.mole.listen("x", (value) => {})
this.room.state.mole.listen("y", (value) => {})

hey, we've answered this on Discord (link): the order callbacks are triggered matches the order fields are defined on the schema

Hi @chaimae, can you describe your real-world scenario on why you need filters?

The filters are experimental and currently consume way too much CPU, I wouldn't recommend for production scenario with many clients.

See docs: https://docs.colyseus.io/colyseus/state/schema/#filtering-data-per-client

HI @Alan-Jin, by the error message it seems like you're trying to add an Array item into the Array of players instead of a Player instance. The error is going to be thrown only at the next patch, that's why wrapping try/catch during assignments/pushes it doesn't catch it.

I suggest inspecting what's being added to the array.

if (item instanceof Player) {
  console.log("good!")
} else {
  console.log("will throw an error during encoding!")
}

Hope this helps, cheers!

Hey @chaimae, I'm in contact with the Arena team to check what's going on with your deployment 🤞 will get back to you soon, sorry for the inconvenience

Hey @chaimae, what's the server URL you're connecting to? We only found a indie plan with your username/email. Cheers!

Hi @arturspon,

Do you possibly re-use Schema instances? Depending on how the schema instance is being moved around (or re-used) within the state, the client-side callback may not trigger the way you expected, unfortunately. If you can provide a minimal reproduction example with your scenario it could help us understand the specific issue you're having.

You could potentially use spot.clone() to make sure a new object is created when sharing the instance is necessary

Hope this helps, cheers!

Hi Mitch,

I've never seen this issue being reported, could you share more details about the environment you're running in?

E.g. are you using Windows? which Node.js version? How do you spawn the process? If you can provide a way we can reproduce would also be nice. Thanks

Hi @MackeyK24, in the past I've made a simple demonstration of using linear interpolation using PixiJS here: https://github.com/endel/colyseus-pixijs-boilerplate/blob/53b490375f2ce065a880ffc1c87ca9fdee40dbf6/src/client/Application.ts#L119-L123

On this approach, the client-side is interpolating every entity's position towards the latest data available from the server at every frame. No action is being taken at the exact time the update came from the server but at every frame.

Hope this helps, let me know if that works for you

Hi @Terradon, welcome 👋

After running npm run build, you can upload the lib/ diretory to Arena and it should work!

Cheers

Hi @eddiwood, welcome!

That is a good question, afaik Arena does not currently support patching node_modules, I'm curious which package you're patching, and why?

Cheers

If you're using Arena, please use wss://server.colyseus.dev instead of ws://server.colyseus.dev:2567

Hi @Bright, can you share more details about your environment?

• Are you using PM2? How's your ecosystem config file?
• Which Presence and Driver have you configured on your Colyseus server?
• Which version of the proxy and Colyseus are you using?

If you can share the relevant pieces of source code it would be best. Cheers!

Hi @LouisonDVC, I think you're looking for autoDispose=false: https://docs.colyseus.io/colyseus/server/room/#autodispose-boolean

I suggest resetting a timeout yourself to dispose the room after 1h during onCreate() and every onLeave(). You can use this.disconnect() to forcibly disconnect & dispose the room when that timeout gets executed.

Hope this helps, cheers!

Hi @newbee, the possibility of cheating is going to depend on how the server receives and interprets the messages sent by the clients. You'd never act on behalf of "player 2" if "player 1" sent a message, for example. The sessionId's are meant to be shared so the client-side can know the identifier of each client and create the visual representation for them.

Hi @ttcong194, there's a migration guide available here: https://docs.colyseus.io/colyseus/migrating/0.14/

Hi @temka1234,

This is a good question, I know there are 2 experiments for Mobx integration with Colyseus' schema:

• https://github.com/a-rts/colyseus-mobx
• https://github.com/amir-arad/colyseus-mobx

When decoding the state, the schema is capable of returning the array containing all changes - this is not exposed by the framework currently, though: https://github.com/colyseus/schema/blob/04cde2e589fc8b02267d055716873db98c58a840/src/Schema.ts#L476-L481

Hi @metiscoda,

You can't have circular dependencies between your schema files. Your KamadiTest is requiring KawadiPlayer, which requires KamadiTest again.

I suggest refactoring your structures so you don't have circular dependencies. Cheers!