Thread: The Player Updating Procedure

Page 1 of 5 123 ... LastLast
Results 1 to 10 of 46
  1. #1 The Player Updating Procedure 
    Renown Programmer
    Method's Avatar
    Join Date
    Feb 2009
    Posts
    1,455
    Thanks given
    0
    Thanks received
    845
    Rep Power
    3019
    The Player Updating Procedure [570+]

    Note: There is a patent by Jagex describing the protocol in detail, which you should take a look at if you want to implement it from scratch or just want a full description. You can find it here: https://www.google.com/patents/US8441486

    Player updating in clients after revision 570 consists of two major parts:

    • General updating (movement, local player list)
      • Local player updating
      • External player updating
    • Flag-based appearance updating


    This update system is fairly different from the older updating procedure and still isn't fully understood, but this document should provide some clarification and guidance for implementing player updating on your server.

    General updating

    The client processes most of the updating in this part of the procedure. It is split up into two parts, local player updating and external player updating, each of which loop twice through their respective players. Of note in this process is the ability to "skip" players when updating. To see whether or not a player will be updated, the client reads a one bit flag. If it is not set, the client reads a two bit quantity indicating the size of the number of players to be skipped, which is then read as a five, eight, or eleven bit number. If the skip number is read during one of the loops, the client flags the current player as being skipped and continues to do so for the amount sent by the server. If the update flag is set, the player will be updated. This process then repeats until the end of the loop.

    Local player updating processes players who were not skipped during the last update first and players who were skipped second, while external player updating does this the other way around.

    Local player updating

    When a local player is updated, a one bit flag is read to indicate whether or not the player requires flag-based updating after it is done being updated. After that, a two bit "type" value is read to signify what sort of update needs to be done to the current player. The available types are:

    • 0
    • 1
    • 2
    • 3


    When moving, if the update flag is not set, the client simply changes the player's position. However, when this flag is set, more data needs to be sent in the flag-based updating part. This will be discussed later.

    Type 0 is used to remove a player from the local list and add it to the external player list. If the "update" flag was set, however, the player is not removed from the local list and is just added to the list of players needing flag-based updating. In this case the player receives no movement update. If the update flag was not set, the player is transfered from the local list to the external list and a one bit flag is read to determine if the player is to be updated by the external player update method. If so, it is updated immediately.

    Type 1 is used in walking. A three bit value containing the direction of movement is read and used to determine the player's next step.

    Type 2 contains similar data to type 1, except four bits are read instead of three. This is used for running.

    Type 3 has two different cases, both of which are used for teleporting or other forms of instantaneous movement. A one bit flag is read to determine whether or not the player is moving more than -16 to 15 tiles away, so the client knows what data to expect.

    If the player is not moving more than -16 to 15 tiles away, a 12 bit packed integer is read. The highest two bits represent the offset to the player's plane. The next five bits represent the delta x coordinate while the other five bits represent the delta y coordinate. It is important to note that an x or y value less than zero needs to have 32 added to it before sending the data to the client. This type is used for teleporting within the local player's viewport.

    If the player is moving more than -16 to 15 tiles away, a 30 bit packed integer is read instead. As with the other type, the high two bits contain the plane offset. However, the x and y offsets are fourteen bits each, allowing for a much wider range of coordinate values. This can be used for teleporting the local player to another region (or outside the viewport) or for moving other players more than -16 or 15 tiles within the local player's viewport.

    External player updating

    Once local player updating is done, external player updating can begin. The server keeps the client informed of regional changes in player movement outside of the local area. Like in local player updating, a two bit "type" value is read to see what update needs to be done. The available types are:

    • 0
    • 1
    • 2
    • 3


    Type 0 is the counterpart of local player updating's type 0 and is used to add a player to the local list from the external list. First, a bit is read to see if the external player needs its regional location updated before it is added to the list. If it does, the method is called again and one of the other types are used to update the player's regional location before adding it to the local player list. After this, two six bit values representing the player's delta x and delta y values from the start of the region the player is in are read. Next, a one bit "update" flag is read to see if the player requires any further flag-based updates. If a player is updated using this update type, it will be counted as having been skipped in the current update.

    Type 1 is used to inform the client of a change to an external player's plane. Two bits are used to represent the offset from the stored plane value.

    Type 2 is similar to the movement change types in local player updating. It contains a 5 bit packed integer containing a plane offset in the high two bits and the direction of movement in the low three bits. This type is used for informing a client about an external player moving to a region adjacent to its current one.

    Type 3 is similar to type 2, except it is used for clients that do not move to an adjacent region. An 18 bit packed integer is read containing the plane offset as the high two bits and the regional x and y offsets as the next 8 bits each.

    Flag-based appearance updating

    As is the case with the older updating system, appearance updating is done through a flag-based updating system. A flag is read from the server, containing the update flag data. The data is then compared with a number of bitwise masks to see if an update is required. If more data than can be stored in an unsigned byte is required, another byte is read, making the flag a little endian short. If even more data is required, another byte is read, making the flag a little endian medium integer. These changes to the data are indicated through specific bit masks that change from revision to revision.

    There are over 15 available updates, including:

    • Two different graphic types
    • Animation
    • Primary and secondary damage
    • "Force movement"
    • Movement type change
    • Temporary movement type change
    • Chat message
    • General appearance update (resend player information including gender, equipment, body colors, name, etc.)
    • Character target (for npc/player interaction)
    • Orientation change


    The graphic updates both read a short, an int, and a byte. Respectively, they contain the id, settings (delay and height), and possibly orientation.

    The animation update reads a short and a byte for the id and delay.

    Primary and secondary hit updates read a smart for damage and a byte for the type of hit. The primary hit update also reads a byte containing the player's hitpoint ratio, used for drawing the health bar above the player's head.

    The force movement update, used in agility and a few other instances, reads four bytes representing the starting and ending coordinates of the movement, two shorts representing delays from the current game loop cycle that are used to calculate the speed of movement, and a byte for the player's orientation when moving.

    The movement type updates are used to signify how the player is moving currently. Both types read a byte as the movement type. The first type stores the value in the client so it remembers the player's last movement type. The second type is used if the player needs to temporarily move in a different way (for example to walk the last step in running movement). This temporary value, if set, overrides the cached value in the client. A value of 1 is used for walking while 2 is used for running. If the value 127 is sent for the temporary movement type, the player is teleported to the position sent in the movement update. The actual position updating occurs at the end of the flag-based updating for a particular player.

    The chat message update reads a null-terminated string that represents a message to be displayed over the player's head. Unlike the old player updating procedure, the message attributes are not sent along with this update.

    The general appearance update reads a byte to determine the length of the data and then reads that amount of bytes. It is used to update gender, head icons, equipment, body colors, name, combat level, and other player-specific values.

    Both the character target and orientation change updates change the direction the player faces. The first type reads a short containing the local index of the npc or player to interact with. If a player is to be interacted with, the player's index needs to have 32768 added to it before being sent to the client. The second type reads a short representing the new orientation for the player.

    There are a few update types I have not figured out yet, including one that displays a different minimap dot for the player. If you have any information on the ones I missed, feel free to let me know. Thanks to super_ for his documentation on the previous protocol and Graham for his documentation on this one.
    Last edited by Method; 08-14-2011 at 09:18 PM.
    :-)
    Reply With Quote  
     

  2. Thankful users:


  3. #2  
    Registered Member
    Join Date
    Apr 2010
    Posts
    368
    Thanks given
    7
    Thanks received
    64
    Rep Power
    18
    kwl, didnt read much but gj
    Reply With Quote  
     

  4. #3  
    Registered Member

    Join Date
    Oct 2008
    Posts
    2,358
    Thanks given
    146
    Thanks received
    1,041
    Rep Power
    869
    ok all you said its correct and that we all knew =p. Well we didnt know rs updates external ppl localhash. Oh you forgot to say theres a limit of adding players per loop.
    Attached image

    Attached image

    Reply With Quote  
     

  5. #4  
    RuneCasino


    Join Date
    Jul 2007
    Posts
    1,647
    Thanks given
    175
    Thanks received
    257
    Rep Power
    358
    I researched about this all before I'm pretty sure, didn't read the whole thing. Good job!
    Reply With Quote  
     

  6. #5  
    Programmer, Contributor, RM and Veteran




    Join Date
    Mar 2007
    Posts
    5,147
    Thanks given
    2,656
    Thanks received
    3,731
    Rep Power
    5000
    Nice work Method
    .
    Reply With Quote  
     

  7. #6  
     

    Vastiko's Avatar
    Join Date
    Dec 2006
    Posts
    5,700
    Thanks given
    300
    Thanks received
    663
    Rep Power
    5000
    Excellent job Method.
    Reply With Quote  
     

  8. #7  
    Hi.

    'Mystic Flow's Avatar
    Join Date
    Nov 2007
    Posts
    7,146
    Thanks given
    256
    Thanks received
    1,252
    Rep Power
    3714
    Where are my credits ??? Gj anyways lol



    Reply With Quote  
     

  9. #8  
    Registered Member

    Join Date
    Aug 2009
    Posts
    1,712
    Thanks given
    96
    Thanks received
    198
    Rep Power
    78
    I must say method, you and super_ are the best informative thread posters. You kinda keep this section alive.
    Also you don't post useless comments and you don't flame, they did a good job making you a moderator.

    OT: Ty for 1 mask I didn't know about
    removed
    Reply With Quote  
     

  10. Thankful users:


  11. #9  
    :doge:

    Join Date
    Jan 2009
    Posts
    3,758
    Thanks given
    221
    Thanks received
    817
    Rep Power
    2116
    wtf is an orientation change? other than that good work
    Reply With Quote  
     

  12. #10  
    Renown Programmer
    Method's Avatar
    Join Date
    Feb 2009
    Posts
    1,455
    Thanks given
    0
    Thanks received
    845
    Rep Power
    3019
    Quote Originally Posted by `Discardedx2 View Post
    wtf is an orientation change? other than that good work
    The orientation update is probably what you guys refer to as the "turn to" update.
    :-)
    Reply With Quote  
     

Page 1 of 5 123 ... LastLast

Thread Information
Users Browsing this Thread

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


User Tag List

Posting Permissions
  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •