FANDOM


The 751 revision of Runescape was launched on February 21, 2013. While the Evolution of Combat was launched
Ss (2013-10-28 at 07.37.26)

A 751 RSPS

during the 743 revision of
 November 20, 2012, this page covers the first EoC revision of RSPS. 751 has been a popular revision in the EoC private server community due to it's high availability of resources and contribution. 

AboutEdit

The 751 protocol is very similar to previous Runescape revisions. Not surprisingly, little has changed from the jump from pre-EoC to post EoC. Very little developers have participated in building the 751 or EoC era, because people either have little interest in EoC, or people don't have the required skill level to contribute. In the next paragraphs, you will learn about how the basic EoC protocol works, from update server to ground items.

Note: ShoeOnHead doesn't know what a protocol is. Be warned.

Js5/Handshake ProtocolEdit

First, a byte is read to indicate the type of protocol to decode.

Opcodes:

  • 15 - Js5 Update (Stage at which the server updates the client by sending cache files)
  • 14 - Js5 Login (Stage at which the server finishes Js5 update and is ready to show the login screen)

If the state of the protocol is to check the version, an unsigned byte is read from the buffer. This byte is the buffer length, in bytes, to check if the decoder knows what to expect from the client. Then, the version and sub-version are read as integers. Afterwords, the client expects a satus code, and an array of 25 integers that represent the update blueprints. The update status codes include:

  • 0 - Status OK
  • 6 - Status out of date
  • 7  - Status full

Otherwise, the decoder should read an unsigned byte known as the packets. These packets tells the server what data to decode.

Opcodes:

  • 0
  • 1
  • 2
  • 3
  • 4

Opcode 0 and 1:

Opcode 0 and 1 are responsible for telling the server that there is a new file request, the information is read by first reading a byte as the type. Next, an int is read as the file ID. However, if the opcode is 1, then the file request is marked as a "priority" file.

A file is encoded by first, writing a byte as the type. Next, and int is written as the file ID. A bitwise OR mask is written as a byte, containing 0x80 as the compression type. The end of the buffer should contain 0xFF as a byte.

Opcode 2 and 3:

Opcode 2 and 3 tell the server that the client is either, 2, performing a log in. Or 3, performing a log out. This keeps the server updated on the state of the client.

Opcode 4:

Opcode 4 is responsible for telling the server that there sould be an update in the encyption. An int is read as the encryption key, and a short is read as the padding.

The Login ProtocolEdit

The first byte read from the login buffer is a connection request. The connection requests veries depending on the stage of login you are at; or if the client is re-connecting after a lost connection to the server. A short is read directly after, which is always 0.

The connection requests include:

  • 16 - Represents an initial login into the lobby.
  • 18 - Represents a re-connection login after the client has lost communication with the server
  • 19 - Represents A login into the world; via lobby

These connection requests will change a few things in the decoding process. So RS keeps track of the connection being processed. The next stage in the login protocol is to decode the client version and details. An int is read containing the client version, followed but a second int representing the sub version, which is normally 1. If the connection type represented a world login, then an extra useless byte is read. 

Next step is the encrypted buffer decode, which is encrypted using RSA to protect user credentials and private details. First, a byte is read as the buffer length, in bytes. This is to make sure there is enough data to decode. Next, the RSA buffer is intialized by using a private key and modulus key in a big integer.

A byte is read as the "magic number", which should be 10. After the magic number, 4 integers are read containing the XTEA keys. A long is then read as a verification, usually 0. Next and importantly, a null terminated string is read to represent the player's password. Then, a client session key and server session key are read as longs.

The next stage is to decode the XTEA buffer. The buffer is generated by deciphering the seeds that were sent earlier during the RSA buffer. Which is filled into an array of 4 keys. A boolean is read to indicate if the player's username should be read as a base37 string, or a regular string. If true, then Runescape reads the string as a base37. Otherwise it's just read as a null terminated string. After that, a byte is read to indicate the display mode of the user's client. A useless byte is read after the display mode, and if the connection type is world, then 2 useless shorts are read.

Next, machine information is decoded. RS reads this in a 24 byte block, and is usually skipped because it is not needed in RSPS.

After the machine information is either skipped or read, the CRC data is decoded. This is used to make sure the client is up to date. A string is read as the 'token', if the connection type is a lobby login, a byte is then read to intialize an array to represnt the index files. Then the data is read as an integer which should be intializing a new array. The array is filled by reading integers into the array. If the connection type is a world login, then a useless integer is read. Afterwords, a byte is read to indicate the amount of data to expect. This is just ignored.

Now for encoding login details to the client. This stage lets the client know about the player's profile, including rights or if they are a member or not. This stage also flags the client a response, letting it know if it should proceed to log in the player, or just notify as to why they cannot proceed. Such as invalid credentials.

First to notify the client of the login response, a var byte packet with the response code is sent. Following, is the login details. Lobby and world are different, have a lot of unkown data, and are lengthy to cover every byte. Most of the data is useless to RSPS, but some isn't; such as the last logged in date, subscription time left, messages in message centre, etc. This is all handled in the lobby. The rights and username are handled in both the lobby and world, this is to notify the client of the priveliges that the player has, and give an intial name to call the player by.

During the login session in the lobby, the player will recieve a packet that represents a worldlist update request. This will be covered later in this article.

Game PacketsEdit

Game packets will be covered in this section of the article. Some packets will be left out due to the lack of knowlege of them.

Outgoing:

Opcode Type Name Description
 117  Var Short  Friend Chat Channel   Initializes a friend chat channel in the client. 
 41  Var Short   Friend  Sends a friend on the friend list.
 53  Var  Byte  Game Message  Sends a game message to the client.
 148  N/A  Game Panel  Sends the game panel screen.
 50  N/A  Ground Item  Sends ground item to the region.
 38  N/A  Interface  Opens an interface.
 16  N/A  Interface Settings  Alters the settings of an interface.
 150  Var Short  Item  Sends an item into a container.
  3  N/A  Keep Alive  Tells the client that the server is still connected. 
 142  N/A  Logout To Lobby  Logs the character out into the lobby.
 60  N/A  Logout  Logs the character out of the game.
 1  Var Short  Player Render  Renders a character on the screen.
 130  Var Short  Outgoing Private Message   Sends a private message to another player.
 105  Var Short  Incoming Private Message  Recieves a private message from a player.
 11  Var Byte  Public Chat Message  Sends a public chat message.
 13  N/A  Run Energy  Sends run energy to the character.
 83  Var Short  Scene Graph  Sends a scene graph to the client.
 78  Var Short  Scene Graph (Secondary Region)   Sends a dynamic scene graph to the client.
 133  N/A  Skill Level  Sends a skill level.
 2  N/A  Outlier Varpbit  Sends an outlier bit varp.
 137  N/A  Normal Varpbit  Sends a normal bit varp.
 129   N/A  Outlier Varp  Sends an outlier varp.
 87   N/A  Varp  Sends a normal varp
 39  Var Short  World List  Sends the world list.

Incoming:

Opcode Name Description
 101  Add Friend  Tells the server that a friend was recently added.  
 27  Attack NPC   Indicates that an NPC was recently attacked.
 79  Command  Sends a command to the server.
 84  Display Mode   Handles the process of a display mode change.
 91  Ground Item  Handles the interaction of a ground item.
 62  Interface Click   Notifies the server of an interface click.
 9  Keep Alive  Requests the server for a keep alive verification.
 38  Object Click  Notifies the server of an object interaction.
 32  Public Chat  Notifies the server of a nearby public chat.
 107  Walk  Notifies the server of a movement request.
 109  Minimap Walk  Notifies the server of a movement request via Minimap. 
 103  World List  Requests the server for a world list update.


Player RenderEdit

The only change in the rendering process that Jagex has implemented over the past few revisions is a new slot. The slot is 'pocket', and it is written after the existing aura slot. If the item is null, a null byte is written. Otherwise, 0x4000 + the pocket item ID is written as a short. Another simple change is a sheathing update. The bit mask is changed for the global data, and a single 0x1 byte is written, followed by 2 large smarts that indicate the model ID of the sheathed weapon. This block of slot data is written in the weapon or shield section (During the 3rd and 5th loop around the equipment slots).

ResourcesEdit

Downloadable sources: