317 Protocol & Packets Explained

[acesucks 1,316]

Packet structure

When the client sends a packet to the server, the first byte encapsulates its

This is the hidden content, please

• Sign In
• or
• Sign Up

. This specific opcode is encrypted with a value generated by the

This is the hidden content, please

• Sign In
• or
• Sign Up

This is the hidden content, please

• Sign In
• or
• Sign Up

seeded with a dynamically server-generated key during the login block. The server decrypts it and associates the opcode to the packet's respective predefined size. If the packet does not contain a fixed size, the opcode will be followed by either a byte or a word - varying per packet - for its proper size. This is then followed by the

This is the hidden content, please

• Sign In
• or
• Sign Up

.

Login Protocol Overview

Every connection to the main 'gateway' server sends a single byte of data, mostly well known as the connection type. The connection type tells the main server which type of connection you wish to initiate. The old engine list consists of:

• Login request - connection type 14
• Update - connection type 15
• New connection login - connection type 16
• Reconnecting login - connection type 18

The connection type we will cover in the following paragraphs is the login connection type, 14. After the login handshake initiating connection type, the client writes a small bit of data derived from the logging in player's username. This is believed to help select the appropriate login server. On successful handshake, the server sends back 8 ignored bytes.

long l = TextUtils.encodeAsBase37Integer(username);
int i = (int) (l >> 16 & 31L);
out.offset = 0;
out.writeByte(14); // Initiate connection type
out.writeByte(i); // "small bit of data derived from... player's username"
in.queueBytes(2, out.payload);
for (int j = 0; j < 8; j++) in.read();

At this point, the client reads in one byte, called the status code. The status code 0 is expected to start the login protocol correctly. If the status code is 0, the client reads a long, dubbed by many as the server session key. This is used to help generate a unique seed for the client session's packet opcode masking. The client then stores two ints that are the upper and lower ints of the client session key, which has the same purpose as the server's key. The client then starts writing the login block, which is RSA encrypted.

The login block starts with the byte 10, which is considered a magic number. Following it is the client session key and server session key longs. After the session keys, the session's UID (unique identifier or user identifier) is written to the block. This is used to distinguish between multiple sessions. Trailing behind the UID comes the client's username and password written as modified C-strings that are rather terminated with a 10 byte than a NUL byte. This block is then RSA encrypted and stored for later use.

Now starts the login request packet. It starts off with a flag telling the server whether or not the client is reconnecting or connecting for the first time. The byte is 18 or 16, respectively. [NOW CLASSIFIED AS A CONNECTION TYPE] Following is the size of the rest of the login response packet, including the login block that trails at the end, to tip the server how much data it should expect. Later comes the magic number byte 255, and right behind it the client revision short. The packet is just about crafted completely. A flag byte that represents if the client is running in low memory or high memory modes is sent, and after the 9 CRC32 checksums of the file system 0 basic archives (this includes versionlist, media, config, etc.). To top it off, the RSA encrypted login block is appended to the end and the packet is sent to the server.

The ISAAC ciphers are seeded for packet opcode masking after adding 50 to each int of the session keys, and the status code is reread. This finishes the login protocol.

Login Protocol Breakdown

The login is comprised of four stages in which the client and server switch in regards to which one is reading and which one is writing.

Variables:

The login process has a lot of variable data, compiled here is a list of the variables and their different values.

Name Hash

A hash of the player name, thought to be used to select an appropriate login server. This has no use in current private servers.

Server Session Key

The server-session-key is one of two ciphers used to encrypt the game protocol, using the ISAAC algorithms.

"Data File Version"

The CRC checks for the cache files

User ID

The ID of the user.

Username

The username of the player, used to identify their account.

Password

The password of the player account, used so only they can log into their account.

Client Session Key

The client-session-key is one of two ciphers used to encrypt the game protocol, using the ISAAC algorithms.

Connect Status

The status of the connection.

Value	Status
16	It signifies that the session is new.
18	Signifies that the session is reconnecting a previously lost connection.

Size

The size of the unencrypted login packet, used to determine how many bytes need to be read from the stream by the server.

Client Version

The memory-version of the game client.

Value	Status
0	Signifies the client is a low-memory client.
1	Signifies that the client is a high-memory client.

CRC Values

9 4-byte values, Each containing the CRC of their respective cache files. Used by the server to verify the client is up to date.

Player Status

The in-game player status - player, player moderator, or an administrator.

Value	Status
0	Signifies that this player is a normal player.
1	Signifies that this player is a player moderator.
2	Signifies that this player is an administrator.

Flagged

If set to 1, information about mouse movements etc. are sent to the server. Suspected bot accounts are flagged.

Response Codes

At the beginning and end of the login procedure, we send different values to the client to allow or deny a login. The various values show different messages on the login box on the client or do something internally.

Value	Response
-1	Waits for 2000ms and tries again while counting failures.
0	Exchanges session keys, player name, password, etc.
1	Waits for 2000ms and tries again.
2	Client made a successful login.
3	"Invalid username or password."
4	"Your account has been disabled. Please check your message-center for details."
5	"Your account is already logged in. Try again in 60 secs..."
6	"RuneScape has been updated! Please reload this page."
7	"This world is full. Please use a different world."
8	"Unable to connect. Login server offline."
9	"Login limit exceeded. Too many connections from your address."
10	"Unable to connect. Bad session-id."
11	"Login server rejected session. Please try again."
12	"You need a members account to login to this world. Please subscribe, or use a different world."
13	"Could not complete the login. Please try using a different world."
14	"The server is being updated. Please wait 1 minute and try again."
15	See the notes below
16	"Login attempts exceeded. Please wait 1 minute and try again."
17	"You are standing in a members-only area. To play on this world move to a free area first."
20	"Invalid loginserver requested. Please try using a different world."
21	"You have only just left another world. Your profile will be transferred in: (number) seconds."
None of the above	"Unexpected server response. Please try using a different world."

Regarding response code 15

On the server, players are not unregistered for quite some time. This can be best witnessed when the client forcefully closes the connection while in combat. If you're quick enough before the player dies or kills the NPC, login attempts during that time return that the account is already logged in. This probably explains why the message says "try again in 60 seconds", and they just reused the response when the player is truly logged in.

Going along with this "players aren't offline yet" idea, when the client experiences some lag and performs a reconnect, it sends byte 18 as it's connection type to the server.

The server most likely saves this as a boolean (reconnect = var == 18;). When the login is entirely validated, meaning the password's are okay and the server isn't full, it can either send back the normal response, 2, or 15.

But why 15? If you look at the client code, you'll see that the chat messages aren't cleared. If you've ever had a poor connection you've noticed that your chat stays there upon a reconnect, and this is exactly why. When you implement response code 15 though, you do NOT need to send the "player status" or the "flagged" bytes.

Login Process:

Stage 1: Client -> Server

Data Type	Value
ubyte	14
ubyte	"name hash"

 

Stage 2: Server -> Client

Data Type	Value
byte	0
byte	0
byte	0
byte	0
byte	0
byte	0
byte	0
byte	0
byte	"response code"
long	"server session key"

 

Stage 3: Client -> Server

Data Type	Value
byte	"connect status"
byte	"size"
byte	255
short	317
byte	"client version"
int	"crc values"[0]
int	"crc values"[1]
int	"crc values"[2]
int	"crc values"[3]
int	"crc values"[4]
int	"crc values"[5]
int	"crc values"[6]
int	"crc values"[7]
int	"crc values"[8]
byte	"size"
byte	10
long	"client session key"
long	"server session key"
int	"user id"
RS String	"username"
RS String	"password"

 

Stage 4: Server -> Client

Data Type	Value
byte	"response code"
byte	"player status"
byte	"flagged"

 

Player Updating

The player updating process consists of 4 parts:

• a) Our player movement updates
• b) Other player movement updates
• c) Player list updating
  • a) Apperance updating
  • b) Location updating
• d) Player update block flag-based updates

Our player movement updates

The client begins by reading 1 bit. This bit tells the client whether or not it is currently updating 'our player', or the player the client is controlling. If it's not updating our player, it exits and goes onto step b. If it is, it then reads 2 bits. The value is called the movement update type. There are 4 recognized movement update types:

• Type 0 basically tells the client there is nothing to update for our player, just add its index to the local updating list.

• Type 1 tells the client you moved in one direction. The client reads 3 bits, which represents the direction you moved in, and then 1 bit, which states whether further update is required. If so, it adds it to the updating list. This is used in walking.

• Type 2 functions in much of the same way as its previous, only this time it reads two 3 bit values. The first represents the player's last direction, and the second it's current direction. Trailing behind it is also the 1 bit 'update required' flag as type 1. This is used in running.

• Type 3 on the other hand is different. It reads in 2 bits which represents our player's plane, or its level of height, in the game world.

Only 0-3 inclusive are appropriate planes supported by the client. It then reads 1 bit, which describes whether or not to clear the awaiting-waypoint queue, basically to stop client from further queued stepping, such as used in teleporting. After this, it reads the 'update required' bit, and checks to see if further update is required. Directly after, it reads two 7 bit quantities, representing the new relative X and relative Y coordinates of our player to our current map region's origin. It then sets our players position to the plane, x, and y positions as told to.

 

Other player movement updates

The client begins by reading an 8 bit value telling the client how many players there are to update. It then enters a loop for each player there is to update.

Inside this loop, the client reads 1 bit. This is the movement update required flag. If the flag is 0, it sets the current updating player's last update cycle time to the current game logic loop cycle time, and adds the player to the local player list. If the flag is not 0, it then reads the movement update type, which is a 2 bit quantity. The following known types are:

• 0, the client updates the current player's last update cycle time, adds the current player to the local player list, and adds it to the updating list.

• 1, the client updates the current player's last update cycle time and adds the current player to the local player list as well, but also reads in 3 bit quantity. This represents the current player's direction it walked to. It then reads the a 1 bit value that specifies whether or not to add the player to the updating list.

• 2, the client does the exact same thing as the type 2 update, except it reads in two of the 3 bit quantities. The first represents the current player's last direction, and the second its current direction running.

• 3, it only adds the player to the needing-update list, or so believed. Type 3 is not well known.

 

Player list updating

The next step in the player updating procedure is the player list updating, or where the client recieves data on every player in its local list, such as appearance and location relative to ours. The client loops through a process for each player in the updating.

The client reads an 11 bit quantity from the buffer, which is the next player in the updated list to be informed about. The clietn then checks if it has a cached buffer for that player's updating, and if it does, it updates the player appearance.

 

Appearance updating

Appearance updating starts off by first reading an unsigned byte that represents the current player's gender. Then it reads another unsigned byte that represents the player's over-head icon id. This is used with prayer icons above heads. Next, a loop occurs 12 times to read equipment data.

In the loop, the client reads an unsigned byte that is the equipment slot's item id high byte. If it is 0, the player's equpment slot has no item. If it is not 0, another unsigned byte is read the merged with the previous to create the equipment's item id. If the id is 65535 (written as a -1 signed short), then the player's appearance is that of an NPC. The client reads in an unsigned short representing the NPC's id and sets the player's definition to that NPC's.

After the equipment loop, it loops 5 times, once for each type of coloured body part. In each loop, the client reads an unsigned short and assigns it as the color of the current loop idx (which represents the body part).

Finally, after the color loop, the client reads 7 unsigned shorts representing animation indices; the animations belong to:

• Standing still
• Turning while standing
• Walking
• Turning around (backwards)
• Turning a quarter-way clockwise
• Turning a quarter-way counter clockwise
• Running

 

After these animation indices are read, a long representing the player's name is read, an unsigned byte representing the combat level, and an unsigned short representing the players skill level (for things where players arent ranked by levels, such as where it states '<player name> (skill <skill>)' as an action menu text).

 

Location updating

After the appearance updating, the client starts to update that player's location relative to our player. The player is added to the local player list and it's last update cycle time. It then reads a 1 bit quantity that defines whether or not the client has a chunk in the player update block list. If it does, it adds it to the updating list. The next bit states whether or not to discard the awaiting-waypoint queue, such as when teleporting. It then reads to 5 bit values that determine the players relative X and Y coordinates to our player. The local player area is 16x16, so if the delta of the two coordinates is > 15, 32 is subtracted from it to signify the player is on the other side of ours. The client then sets the player's position, ending the player list updating process.

 

Update block flag-based updating

The following is what most people think of when they say 'update mask' and 'update flag'. This process of the updating procedure is very important. It begins with looping through ALL players in the local player update list, reading an unsigned byte which from now on will be called the update flag. All further updates are seen to be 'included' by comparing a bitwise mask to this flag. If the flag has the bits for 0x40 all on, this signifies that the flag was too large for a simple unsigned byte and reads in another unsigned byte, which it uses as the upper unsigned byte, therefore the update flag is an unsigned little-endian short. The client then passes off the data to a helper method which processes all updates this flag signifies.

 

Inside this method, many different bitwise masks are compared to the player's flag, and if the mask is set, logic is performed. These masks are frequently called update masks. A list of player update masks are below:

• 0x400 The 0x400 mask is used to update the player so they appear to be asynchronously animating and walking. This mask is often used for the
  This is the hidden content, please

  • Sign In
  • or
  • Sign Up
  skill. The data associated goes in order of: byte (type C) which is the first location's X coordinate value, byte (type S) which is the first location's Y coordinate value, byte (type S) which is the second location's X coordinate value, byte (type C) the second location's Y coordinate value. After the locations are written, there is a required movement speed which is written as a short which marks how fast to move from position 1 to position 2. Another short (type A) is written as the movement speed going from position 2 to position 1. Finally one byte is written to end the mask block, which marks the direction.

 

• 0x100 The 0x100 mask is responsible for player graphics updating. The data associated is a little-endian unsigned short which represents the graphics id, and an int which is the graphics delay.

 

• 0x8 Animations are handled by the 0x8 mask. The payload for this update is a little-endian unsigned short that is the animation id, and an unsigned inversed byte which states the animation's delay.

 

• 0x4 The beloved 0x4 mask takes care of forced player text that is only displayed above the player's model. The only data associated with this is a jagex ASCII string with a terminator of 10.

 

• 0x80 Unlike the previous, the 0x80 mask handles normal player chat text. The client will read a little-endian unsigned short which holds chat text attributes. It holds the text color and chat effects. Next, the client reads an unsigned byte which states the player's priveleges (normal player, player moderator, moderator, staff) to give the chatter's name a crown. Right behind it trails an unsigned inversed byte that gives chat text length in bytes. Trailing afterwards is dictionary-compressed chat text. All chat text characters become indexes into a valid character table and are written as nibbles (4 bit quantities).

 

• 0x1 Updating the player's current interacting-entity is done via mask 0x1. The entity id is written as a little-endian unsigned short.

 

• 0x10 The 0x10 mask updates appearance of the player in exact same way as in updating player list. Only difference is that appearance is updated from a set-sized buffer filled from the current buffer. An unsigned inversed byte is read first which describes appearance buffer size, and the buffer is filled.

 

• 0x2 Facing coordinate updating is signified by the 0x2 mask. The player's facing-towards X and Y are set to read values; specifically, an unsigned lower-inverted short and little-endian unsigned short, respectively.

 

• 0x20 Notifying client's of a player's health is done via the 0x20 mask. The hitpoint damage done to the player is sent as an unsigned byte, followed by the hit type as a positive inverted byte. The player's current and max health are read as an unsigned inverted byte and unsigned byte, respectively.

 

• 0x200 The 0x200 mask acts in the same way as the 0x20 mask and is most likely associated with special attacks from weapons that have the ability to hit twice at the same time. Hitpoint damage is an unsigned byte, the hit type an unsigned inverted byte, and the current and maximum health being an unsigned byte and unsigned inverted byte, respectively.

After the client processes every single player in the update player list, it ends player updating.

Game Protocol

The game protocol is the in-game communication of player actions between the server and client.

Server -> Client Packets use Output Streams. The Server writes information using the Output Streams, and then the Client Receives packet information with input stream's...

In order for a Packet to be sent to the client, from the server, a frame is needed to be created first. After the frame frame has been created, the information from the Output Streams, are written, so this makes the information sent to the client for the certain packet. A method in java, for sending the packets information would be like:

	public void sendMessage(String message) {
		if (getOutStream() != null) {
			outStream().createFrameVarSize(253);
			outStream().writeString(s);
			outStream().endFrameVarSize();
		}
	}
The Client might will read it like:

if (packetType == 253) {
	String message = inputStream.readString();
	pushMessage("", 4, null);
	return true; // false to make the packet not work... true to make it work...
} 

 

Server -> Client Packets

Opcode	Type	Length (bytes)	Name	Description
1	FIXED	0	Animation reset	Resets all animations in the immediate area.
4	FIXED	6	Display Stationary Animation	Displays a stationary animation.
24	FIXED	1	Flash sidebar	Causes a sidebar icon to start flashing.
34	FIXED	2	Update Single Item	Updates a single item in a users inventory.
35	FIXED	4	Camera shake	Causes the camera to shake.
36	FIXED	3	Send Config	Sends a configuration (e.g duel interface rules)
44	FIXED	5	Display Ground Item	Display's a ground item at a specified coordinate.
50	FIXED	9	Send add friend	Sends a friend to the friend list.
53	VARIABLE_SHORT	N/A	Set stack size	Sets a stack size on inventory interface
60	FIXED	3	Send regional packet	Sends a regional packet
64	FIXED	2	Remove ground item	Removes a spawned ground item.
65	VARIABLE_SHORT	N/A	Npc Updating	Updates npcs
68	FIXED	0	Reset button state	Resets the button state for all buttons.
70	FIXED	6	Interface offset	Sets the offset for drawing of an interface.
71	FIXED	3	Send sidebar interface	Assigns an interface to one of the tabs in the game sidebar.
72	FIXED	2	Clear inventory	Clears an interface's inventory.
73	FIXED	4	Load map region	Loads a new map region.
74	FIXED	2	Send Song	Plays a song.
78	FIXED	0	Clear Minimap Flag	Clears the minimap flag from the minimap.
79	FIXED	4	Scroll position	Sets the scrollbar position of an interface.
81	VARIABLE_SHORT	N/A	Player Updating	Updates the local player
84	FIXED	7	UNKNOWN	Alternative ground item
85	FIXED	2	Update Local Player	Updates the players localX and localY
87	FIXED	6	Toggle Interface Button	Toggles an interface button (this can have multiple states, e.g dueling interface)
97	FIXED	2	Show interface	Displays a normal interface.
99	FIXED	1	Minimap State	Sets the mini map's state.
101	FIXED	2	Remove Object	Removes a regional object from the game world.
104	VARIABLE_BYTE	N/A	Display Player Option	Displays a player right click option.
105	FIXED	4	Play sound in location	Plays a sound effect in a certain location.
106	FIXED	1	Force tab	Force sets a players current sidebar interface.
107	FIXED	0	Reset camera	Resets the camera position.
109	FIXED	0	Logout	Disconnects the client from the server.
110	FIXED	1	Run energy	Sends the players run energy level.
114	FIXED	2	System update	Sends how many seconds until a 'System Update.'
117	FIXED	15	Display Projectile	Displays a projectile for the player
121	FIXED	4	Queue Song	Queues a song to be played next.
122	FIXED	4	Interface color	Changes the color of an interface.
126	VARIABLE_SHORT	N/A	Send text	Attaches text to an interface.
134	FIXED	6	Update skill	Updates a players skill of current lvl and experience
135	FIXED	6	Skill level	Sends a skill level to the client.
147	FIXED	10	Transform Player Into Game Object	Transforms a player into a game object
151	FIXED	4	Add Object	Adds a regional object to the game world
156	FIXED	3	Remove Ground Item	Removes an item on the ground.
160	FIXED	4	Animate Object	Animates a game object
164	FIXED	2	Chat interface	Shows an interface in the chat box.
166	FIXED	6	Spin Camera	Spins the users camera.
171	FIXED	3	Send Hidden Interface	Sets an interface to be hidden until hovered over.
174	FIXED	5	Send Sound	Plays a sound effect.
176	FIXED	10	Open welcome screen	Displays the welcome screen.
177	FIXED	6	Gradually turn camera	Turns the camera to a specified location
185	FIXED	2	Display player head model on interface	Displays a player's head model on an interface.
196	VARIABLE_BYTE	N/A	Send private message	Sends a private message to another player.
200	FIXED	4	Interface animation	Sets an interface's model animation.
206	FIXED	3	Chat settings	Sends the chat privacy settings.
208	FIXED	2	Walkable interface	Displays an interface in walkable mode.
214	VARIABLE_SHORT	N/A	Send add ignore	Sends a ignored player to the ignore list.
215	FIXED	7	UNKNOWN	Something to do with ground items.
219	FIXED	0	Clear screen	Clears the screen of all open interfaces.
221	FIXED	1	Friends list status	Friends list load status.
230	FIXED	8	Interface model rotation	Sets an interface's model rotation and zoom
240	FIXED	2	Weight	Sends the players weight amount.
241	VARIABLE_SHORT	N/A	Construct map region	Constructs a dynamic map region using a palette of 8*8 tiles.
254	FIXED	3	Display Mob Hint Icon	Displays a hint icon over a mob
246	FIXED	6	Interface item	Displays an item model inside an interface.
248	FIXED	4	Inventory overlay	Displays an interface over the sidebar area.
249	FIXED	3	Initialize player	Sends the player's membership status and their current index on the server's player list.
253	VARIABLE_BYTE	N/A	Send message	Sends a server message (e.g. 'Welcome to RuneScape') or trade/duel request.

Client -> Server Packets

Opcode	Type	Length (bytes)	Name	Description
0	FIXED	0	Idle	Sent when there are no actions being performed by the player for this cycle.
3	FIXED	1	Focus change	Sent when the game client window goes in and out of focus.
4	VARIABLE BYTE	N/A	Chat	Sent when the player enters a chat message.
14	FIXED	8	Item on player	Sent when a player uses an item on another player.
16	FIXED	1	Alternate item option 2	Sent when a player uses an item. This is an alternate item option.
17	FIXED	2	NPC action 2	Sent when a player clicks the second option of an NPC.
18	FIXED	2	NPC action 4	Sent when a player clicks the fourth option of an NPC.
21	FIXED	2	NPC action 3	Sent when a player clicks the third option of an NPC.
25	FIXED	10	Item on floor	Sent when a player uses an item on another item thats on the floor.
35	FIXED	4	Magic on object	Send when a player uses magic on an object.
36	FIXED	4	Anti-Cheat	Send to validate walking.
39	FIXED	2	Follow	Sent when a player clicks the follow option on another player.
40	FIXED	2	Dialogue	Send when a player continues a dialogue.
41	FIXED	6	Equip item	Sent when a player equips an item.
43	FIXED	6	Bank 10 items	Sent when a player banks 10 of a certain item.
45	FIXED	1	Flagged account	Sent when a players account is flagged.
53	FIXED	4	Item on item	Sent when a player uses an item with another item.
57	FIXED	4	Item on NPC	Sent when a player uses an item on an NPC.
60	FIXED	1	Typing onto interface	Sent while typing onto an interface
70	FIXED	6	Object action 3	Sent when the player clicks the third action available for an object.
72	FIXED	2	Attack (NPC)	Sent when a player attacks an NPC.
73	FIXED	2	Attack (Player)	Sent when a player selects the attack option on another player.
74	FIXED	8	Remove ignore	Sent when a player removes a player from their ignore list.
75	FIXED	6	Item Action 3	Send when a player clicks the third option of an item.
79	FIXED	6	Light item	Sent when a player attempts to light logs on fire.
85	FIXED	1	Anti-Cheat	Sent to validate npc option 4. (client action 478)
86	FIXED	4	Camera movement	Sent when the player moves the camera.
87	FIXED	6	Drop item	Sent when a player wants to drop an item onto the ground.
95	FIXED	3	Privacy options	Sent when a player changes their privacy options (i.e. public chat).
98	VARIABLE_BYTE	N/A	Walk on command	Sent when the player should walk somewhere according to a certain action performed, such as clicking an object.
101	FIXED	13	Design screen	Sent when a player is choosing their character design options.
103	VARIABLE_BYTE	N/A	Player command	Sent when the player enters a command in the chat box (e.g. "::command")
117	FIXED	6	Bank 5 items	Sent when a player banks 5 of a certain item.
121	FIXED	0	Loading finished	Sent when the client finishes loading a map region.
122	FIXED	6	Item action 1	Sent when the player clicks the first option of an item, such as "Bury" for bones.
126	VARIABLE BYTE	N/A	Private message	Sent when a player sends a private message to another player.
128	FIXED	2	Accept Challenge	Sent when a player accepts another players duel request.
129	FIXED	6	Bank all items	Sent when a player banks all of a certain item that they have in their inventory.
130	FIXED	0	Close window	Sent when a player presses the close, exit or cancel button on an interface.
131	FIXED	4	Magic On NPN	Sent when a player uses magic on an npc.
132	FIXED	6	Object action 1	Sent when the player clicks the first option of an object, such as "Cut" for trees.
133	FIXED	8	Add ignore	Sent when a player adds a player to their ignore list.
135	FIXED	6	Bank X items part-1	Sent when a player requests to bank an X amount of items.
136	FIXED	0	Anti-Cheat	Send with client action 561, 6 has to do with player option 1
139	FIXED	2	Trade Request	Sent when a player Requests a trade from another player. (e.g. "Sending Trade Request...")
145	FIXED	6	Unequip item	Sent when a player unequips an item.
152	FIXED	1	Anti-Cheat	Send to validate npc option 3 (client action 965)
153	FIXED	2	Player Option 2 (Report Abuse)	Sent when a moderator or administrator selects the second option of a player.
155	FIXED	2	NPC action 1	Sent when a player clicks first option of an NPC, such as "Talk."
164	VARIABLE_BYTE	N/A	Regular walk	Sent when the player walks regularly.
181	FIXED	8	Magic On Ground Item	Send when a player uses a spell on a ground item.
183	FIXED	4	Anti-Cheat	Validates clicking object option 4
185	FIXED	2	Button click	Sent when a player clicks an in-game button.
188	FIXED	8	Add friend	Sent when a player adds a friend to their friend list.
189	FIXED	1	Anti-Cheat	Validates player option 2
192	FIXED	12	Item on object	Sent when a a player uses an item on an object.
200	FIXED	2	Anti-Cheat	Validates banking options
202	FIXED	0	Idle logout	Sent when the player has become idle and should be logged out.
208	FIXED	4	Bank X items part-2	Sent when a player enters an X amount of items they want to bank.
210	FIXED	0	Region change	Sent when a player enters a new map region.
214	FIXED	7	Move item	Sent when a player moves an item from one slot to another.
215	FIXED	8	Remove friend	Sent when a player removes a friend from their friend list.
218	FIXED	8	Report player	Sent when a player reports another player.
228	FIXED	6	Object option 4	Sent when a player uses the 4th option of an object.
230	FIXED	1	Anti-Cheat	Validates NPC option 2
234	FIXED	6	Object option 2	Send when a player uses the 2nd option of an object.
236	FIXED	6	Pickup ground item	Sent when the player picks up an item from the ground.
237	FIXED	8	Magic on items	Sent when a player casts magic on the items in their inventory.
241	FIXED	4	Mouse click	Sent when the player clicks somewhere on the game screen.
246	FIXED	15	Anti-Cheat	Not sure
248	VARIABLE_BYTE	N/A	Map walk	Sent when the player walks using the map. Has 14 additional (assumed to be anticheat) bytes added to the end of it that are ignored.
249	FIXED	4	Magic on player	Sent when a player attempts to cast magic on another player.
252	FIXED	6	Object action 2	Sent when the player clicks the second option available for an object.
253	FIXED	6	Ground Item Action	Sent when the player clicks the first option for a ground item (I.E. 'Light Logs')

[dfsdh 0]

very good breakdown very informative

[bigbrainrando 0]

Should be helpful for me down the line once i take on the task of writing my own framework. Thank you!

[needaccountlike 0]

Thanks for this brother means a lot to me

[ryuesu 2]

thanks for the contribution

[Hostile 0]

Thanks Ace.
Not sure if I want to work with 317 stuff again or just start fresh with OSRS (Which is probably the better option) but this is valuable information.

thankyou for taking the time to share this.

[TheGoddd 1]

Good break down, thanks for this mate

[Flexed 0]

Thanks for sharing!

[Rangini 1]

Thanks for the post dude

[MemeManJoe 0]

thanks for the guide cx

[The Man Stan 8]

thanks

[Powerful 0]

Thank you so much!

[kkkttt 1]

awesome stuff, needed this!

[Intention 1]

copied and saved. thank you

[Andyhi 0]

thanks for the info