Navigation

    • Register
    • Login
    • Search
    • Categories
    • Popular
    • Users
    1. Home
    2. endel
    • Continue chat with endel
    • Start new chat with endel
    • Flag Profile
    • block_user
    • Profile
    • Following
    • Followers
    • Topics
    • Posts
    • Best
    • Groups
    Save
    Saving

    endel

    @endel

    administrator

    56
    Reputation
    362
    Posts
    1864
    Profile views
    6
    Followers
    0
    Following
    Joined Last Online

    endel Follow
    administrator

    Posts made by endel

    • RE: Account registration question

      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

      posted in Questions & Help
      endel
    • RE: Can I extend the Client and the Room class?

      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

      posted in Questions & Help
      endel
    • RE: Nested schema levels

      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?

      posted in Questions & Help
      endel
    • RE: Can I extend the Client and the Room class?

      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

      posted in Questions & Help
      endel
    • RE: card-matching game

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

      posted in Showcase
      endel
    • RE: Re-triggering filter on condition changes

      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!

      posted in Questions & Help
      endel
    • RE: What exactly is sent at every patch rate?

      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!

      posted in Questions & Help
      endel
    • RE: Discover uses processId to distuingish nodes, which is not unique across multiple servers

      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!

      posted in Questions & Help
      endel
    • RE: Can server-side matchmaking be done in the server's verifyClient?

      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!

      posted in Questions & Help
      endel
    • RE: Can server-side matchmaking be done in the server's verifyClient?

      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! :)

      posted in Questions & Help
      endel