Thread: Synchronising other players movements, how does this procedure work?

Page 1 of 2 12 LastLast
Results 1 to 10 of 15
  1. #1 Synchronising other players movements, how does this procedure work? 
    Registered Member
    Join Date
    Sep 2019
    Posts
    29
    Thanks given
    2
    Thanks received
    8
    Rep Power
    65
    Hey again all,

    I'm reading through syncing other players movements but thought it may save me sometime to just ask here .

    As far as I can tell, it just takes the amount of players in the server as a whole? But what I'm move confused about is it does the ordinary movement update procedure alike the initial local player movement updating method. Should I be sending any movements other players do relative to the local player in this? I'm not sure how I'd track that either honestly. Just confused with this altogether so any help is appreciated!

    And as a bonus question, for the player list updating. It takes an 11 bit value representing the 'next' player to be updated, will this be the player ID sent back from the client in the login protocol? And should I send every single player to it?

    Thanks in advance!

    Update:
    I'm gonna try the following...

    Every tick, if the player has moved (i.e., movetype isn't 0) then I'm gonna push it + their client uid given in the login block and direction taken to a local server store. Then when we come to P81 for each individual client, I'll filter out all of the updates for other players by checking that our ID != to theirs. After this, I think I can just grab the length of my cached list, send that for the amount and then set it on a loop to send each of the bits per the players in the cached list. This is a pretty wild guess but if it works I'll update this post for anyone else who wasn't/isn't sure how to approach this.

    Update 2:
    RESOLVED

    Read a little more, you can't actually update the players movements until you update the local list, duhh I know lol. So on your initial packet 81 of another connection coming in, you'll ignore their movements and actually just update your next P81 with their connection index (I check this via adding my local index to my socket cache). Apply the update flag for their masks and update their appearance. After this, your next tick in which you send 81, you can THEN update their movements and afterwards again, loop through the player list looking for others who need mask updates. Not before. Whilst testing I just omitted sending an appearance update for the other player and went directly to their movements once I updated them in my local list. Comparing their index to my currently cached local player index for my local socket, I was able to differentiate between us both.

    The player list handles their location at all times btw, relative to our player. That's how it caches it, so these two P81 methods work in tandem to co-ordinate the entire thing but the second method, updating the player list, always takes precedence .

    The 2047 in player list updating signifies you're the only player. It's a quick shot flag to stop us anticipating others who don't exist, it's not a magic number.

    Anyone else struggling I hope this helps!
    Reply With Quote  
     

  2. #2  
    Registered Member

    Join Date
    Feb 2010
    Posts
    3,253
    Thanks given
    1,145
    Thanks received
    909
    Rep Power
    2081
    2047 - Magic number to indicate an update required and the max number of players.

    255 - Maximum number of local players.

    96 - (I think this is correct) number of actual players that can be updated simultaneously on the users screen. I

    Every cycle an update will take place. The server will iterate over every player (assuming you don't use an event driven model which passively responds) and decide whether the player needs to be updated.

    Modern servers complicate the procedure by appending the update block at the end. You need to send the update block at the end but there isn't any need to append it. Just tell the client you are not updating this player (set the initial bit value to terminate the update this player and set bit 8 to 1) and then send the magic number and the following update.

    The procedure is basically:

    1. Update this player if needed.
    2. If not updating this player we are obviously updating another player so.
    3. Check the player list.
    4. If there is a new player add them.
    5. Send the update masks.

    The 11 bit value is the player index so the client knows to add the player to the list to consider next time. If the server works out next cycle that the player has been removed the client needs to be told to remove the player from the list.

    The client is the real brains. Your job is to verify the integrity of the packet to prevent cheating and guarantee everything is sent correctly.
    Reply With Quote  
     

  3. #3  
    Registered Member
    Join Date
    Sep 2019
    Posts
    29
    Thanks given
    2
    Thanks received
    8
    Rep Power
    65
    Quote Originally Posted by Fire Cape View Post
    2047 - Magic number to indicate an update required and the max number of players.

    255 - Maximum number of local players.

    96 - (I think this is correct) number of actual players that can be updated simultaneously on the users screen. I

    Every cycle an update will take place. The server will iterate over every player (assuming you don't use an event driven model which passively responds) and decide whether the player needs to be updated.

    Modern servers complicate the procedure by appending the update block at the end. You need to send the update block at the end but there isn't any need to append it. Just tell the client you are not updating this player (set the initial bit value to terminate the update this player) and then send the magic number and the following update.

    The procedure is basically:

    1. Update this player if needed.
    2. If not updating this player we are obviously updating another player so.
    2. Check the player list.
    3. If there is a new player add them.
    4. Send the update masks.

    The 11 bit value is the player index so the client knows to add the player to the list to consider next time. If the server works out next cycle that the player has been removed the client needs to be told to remove the player from the list.

    The client is the real brains. Your job is to verify the integrity of the packet to prevent cheating and guarantee everything is sent correctly.
    Hey, I appreciate the response but my question is more about the movement updating for other players and their appearance not our local players.

    It seems to read the movements for each player and expects me to write them? That's what I don't get,

    Like this:

    Code:
    int count = buffer.readBits(8);
    Reads the count of players we wish to update movements for in our local area.

    Then immediately does this after it:
    Code:
    		playerCount = 0;
    		for (int i = 0; i < count; i++) {
    			int index = playerList[i];
    			Player player = players[index];
    
    			int updateRequired = buffer.readBits(1);
    The rest of the block is identical to movement updates like P81. WHo's bits am I sending here lol? (movement bits, as it expects it every player we send... surely I don't send all of them in my local area right?)

    Like this:
    Code:
    				if (movementType == 0) {
    					playerList[playerCount++] = index;
    					player.time = tick;
    					mobsAwaitingUpdate[mobsAwaitingUpdateCount++] = index;
    				} else if (movementType == 1) {
    					playerList[playerCount++] = index;
    					player.time = tick;
    					int direction = buffer.readBits(3);
    					player.walk(direction, false);
    					int update = buffer.readBits(1);
    
    					if (update == 1) {
    						mobsAwaitingUpdate[mobsAwaitingUpdateCount++] = index;
    					}
    				}
    I've got 0 idea how I'd determine their bloody movements lol

    As for the index, I presume it's that initial uid sent in the login procedure for each new client? Shall I loop over everyone?

    Also about the masks, you need to send it after previous data if you are updating this player, that isn't optional man.

    I am using an event based observable architecture which emits on a specified tick too btw
    Reply With Quote  
     

  4. #4  
    Registered Member

    Join Date
    Feb 2010
    Posts
    3,253
    Thanks given
    1,145
    Thanks received
    909
    Rep Power
    2081
    Quote Originally Posted by wolfajk View Post
    Hey, I appreciate the response but my question is more about the movement updating for other players and their appearance not our local players.

    It seems to read the movements for each player and expects me to write them? That's what I don't get,

    Like this:

    Code:
    int count = buffer.readBits(8);
    Reads the count of players we wish to update movements for in our local area.

    Then immediately does this after it:
    Code:
    		playerCount = 0;
    		for (int i = 0; i < count; i++) {
    			int index = playerList[i];
    			Player player = players[index];
    
    			int updateRequired = buffer.readBits(1);
    The rest of the block is identical to movement updates like P81. WHo's bits am I sending here lol? (movement bits, as it expects it every player we send... surely I don't send all of them in my local area right?)

    Like this:
    Code:
    				if (movementType == 0) {
    					playerList[playerCount++] = index;
    					player.time = tick;
    					mobsAwaitingUpdate[mobsAwaitingUpdateCount++] = index;
    				} else if (movementType == 1) {
    					playerList[playerCount++] = index;
    					player.time = tick;
    					int direction = buffer.readBits(3);
    					player.walk(direction, false);
    					int update = buffer.readBits(1);
    
    					if (update == 1) {
    						mobsAwaitingUpdate[mobsAwaitingUpdateCount++] = index;
    					}
    				}
    I've got 0 idea how I'd determine their bloody movements lol

    As for the index, I presume it's that initial uid sent in the login procedure for each new client? Shall I loop over everyone?

    Also about the masks, you need to send it after previous data if you are updating this player, that isn't optional man.

    I am using an event based observable architecture which emits on a specified tick too btw
    The index is not the uid but I don't see why it couldn't be used to distinguish players since that's kind of the point.

    You don't need to work out the other players movement, the client does it for you. And yes the movement update is almost identical for the one for this players. Unless you use a model that passively responds to movement updates yeah you will have to loop through every player. How else would the server know what everyone else was doing? The first bit for the other player movement lets the client know if the update is even needed. It will get the index of the player list and decide whether that player is standing, walking, running etc.

    And yes you are correct the mask does need to be sent afterwards but that is not what I actually said. You do have to send the mask afterwards but you don't have to append it on the way. In most servers it is currently appended to the end of the bloc which in my opinion causes confusion, you can break and send the bloc at the end without appending on the way. It's how I'm doing it in my server in C.
    Reply With Quote  
     

  5. #5  
    Registered Member
    Join Date
    Sep 2019
    Posts
    29
    Thanks given
    2
    Thanks received
    8
    Rep Power
    65
    Quote Originally Posted by Fire Cape View Post
    The index is not the uid but I don't see why it couldn't be used to distinguish players since that's kind of the point.

    You don't need to work out the other players movement, the client does it for you. And yes the movement update is almost identical for the one for this players. Unless you use a model that passively responds to movement updates yeah you will have to loop through every player. How else would the server know what everyone else was doing? The first bit for the other player movement lets the client know if the update is even needed. It will get the index of the player list and decide whether that player is standing, walking, running etc.

    And yes you are correct the mask does need to be sent afterwards but that is not what I actually said. You do have to send the mask afterwards but you don't have to append it on the way. In most servers it is currently appended to the end of the bloc which in my opinion causes confusion, you can break and send the bloc at the end without appending on the way. It's how I'm doing it in my server in C.
    Ah oki, so for the other players movements I need to tell the client in what direction they moved, what, relative to our local player? I'm still confused sorry lol how am I to determine that? I.e., the movements others made, how can I track this? Or is it more a case of watching for when they update their own movements and just updating like that|?
    Reply With Quote  
     

  6. #6  
    Registered Member

    Join Date
    Feb 2010
    Posts
    3,253
    Thanks given
    1,145
    Thanks received
    909
    Rep Power
    2081
    Quote Originally Posted by wolfajk View Post
    Ah oki, so for the other players movements I need to tell the client in what direction they moved, what, relative to our local player? I'm still confused sorry lol how am I to determine that? I.e., the movements others made, how can I track this? Or is it more a case of watching for when they update their own movements and just updating like that|?
    You only need to set the bit for the client to do it. Think of the run button. You click the run button and the player runs. What's going on here?

    1. The button clicking packet is called.
    2. You would then tell the server that the current player requires a movement update (a boolean) and another to say that they are running.
    3. The cycle will take place. The server will set the bits to say the player is moving, and that they are running. The client works out what index this player is so every other player knows what they are doing.
    4. The client will sync the movements based on the local list.
    Reply With Quote  
     

  7. #7  
    Registered Member
    Join Date
    Sep 2019
    Posts
    29
    Thanks given
    2
    Thanks received
    8
    Rep Power
    65
    Quote Originally Posted by Fire Cape View Post
    You only need to set the bit for the client to do it. Think of the run button. You click the run button and the player runs. What's going on here?

    1. The button clicking packet is called.
    2. You would then tell the server that the current player requires a movement update (a boolean) and another to say that they are running.
    3. The cycle will take place. The server will set the bits to say the player is moving, and that they are running.
    4. The client will sync the movements based on the local list.
    How is the client supposed to know of other players though without me manually updating it? That doesn't make sense to me man. Also just to mention idk if you know, but buttons are packets 241 (a click location) and 182 (a toggle button) with an id (ordinary action id) btw.
    I think you may be misunderstanding my question so I'll try word it better:
    The client basically reads the amount of [other] players to update movements for, whether or not to actually update their movements or add to the local index but in each movement update, it's gonna read what their movements are via the server [identical to how local player movements work]. How can I approach letting it know of others movements? My idea was to store all the movements for each player (i.e., local server store per connections.length) in a hashmap id -> movement bits and write per player. But this felt a little heavy, but I really can't figure another way around it. (And then wipe per tick obviously aha)
    Reply With Quote  
     

  8. #8  
    Registered Member

    Join Date
    Feb 2010
    Posts
    3,253
    Thanks given
    1,145
    Thanks received
    909
    Rep Power
    2081
    Because you are telling it. The client knows the position of the current player. The server loops through every player (client) and tells the client to update by setting the bits. There is a list which keeps track of current players.

    The player updating procedure only updates the movement but it does not actually do the movement. You need to implement packet 164 the walking packet. The client can work out where the current player has moved to and when you update it, it will know. Debug packet 164 you will see the client knows the players current and new position.

    185 is button click btw.
    Reply With Quote  
     

  9. #9  
    Registered Member
    Join Date
    Sep 2019
    Posts
    29
    Thanks given
    2
    Thanks received
    8
    Rep Power
    65
    Quote Originally Posted by Fire Cape View Post
    Because you are telling it. The client knows the position of the current player. The server loops through every player (client) and tells the client by setting the bits. There is a list which keeps track of current players.

    The player updating procedure only updates the movement but it does not actually do the movement. You need to implement packet 164 the walking packet. The client can work out where the current player has moved to and when you update it, it will know. Debug packet 164 you will see the client knows the players current and new position.

    185 is button click btw.
    Everyone has their own client, so it'll have no idea about other players until you update it so. I.e., update their movements for the local players client too. Sorry I think you're wrong. & oh sorry it's 185 yeah lol.
    Reply With Quote  
     

  10. #10  
    Registered Member

    Join Date
    Feb 2010
    Posts
    3,253
    Thanks given
    1,145
    Thanks received
    909
    Rep Power
    2081
    Quote Originally Posted by wolfajk View Post
    Everyone has their own client, so it'll have no idea about other players until you update it so. I.e., update their movements for the local players client too. Sorry I think you're wrong. & oh sorry it's 185 yeah lol.
    The client doesn't need to know about the physical existence of other clients. The server interfaces between the them. What do you think an appearance update is doing? It is notifying the client about the appearance not just of a player but of all players in the list (notice that the walk and run animation is set in this block). A movement update is doing the same thing. This is sent for every player in the list so that the player who the client is actually controlling can see them moving. There aren't actually multiple players in an OOP sense, it is fake.
    Reply With Quote  
     

Page 1 of 2 12 LastLast

Thread Information
Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)


User Tag List

Similar Threads

  1. Replies: 14
    Last Post: 07-21-2015, 03:59 PM
  2. [Rep++] How does this dupe works?
    By Gr1nderscape in forum Help
    Replies: 4
    Last Post: 01-02-2012, 01:22 PM
  3. How does this look, guys?
    By Xenocide in forum Graphics
    Replies: 22
    Last Post: 07-09-2010, 05:03 AM
  4. How does this look?
    By Proffessor Oak in forum Chat
    Replies: 3
    Last Post: 02-19-2010, 02:24 PM
  5. How does this work??Rep++
    By Mini in forum Help
    Replies: 1
    Last Post: 12-20-2009, 11:22 PM
Posting Permissions
  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •