Thread: [OSRS] Deciphering CS2 for Sliding Puzzles

This post is more a brain dump but I wanted to document how I reverse engineered the Sliding Puzzle interface in OSRS (rev 181). This tutorial will assume you are using RSMod but the concepts should be generic enough for any OSRS base.

I have written this tutorial in the same way that I discovered and solved each task required to get the puzzle properly drawing, you will notice that step 1 is left incomplete because step 6 comes full circle to complete it.

The Result
https://i.gyazo.com/cf2312cbd1584ab0...e2bd9632d6.mp4


Step 0 - Finding the interfaceId

Spoiler for Step 0:

Luckily this hero shared a named dump of all interface IDs in osrs https://www.rune-server.ee/runescape...rface-ids.html. An alternative may be to load it in Runelite developer tools but my Oldschool account did not have any puzzle boxes.

The interface ID turns out to be 306.

Step 1 - Sending pieces to the client

Spoiler for Step 1:

When you load the interface in game, you will be greeted with a blank grid. This is because the interface actually contains an inventory container - similar to items kept on death, looting bag, bank.


The first task is to figure out how to tell the client which items to display. I stumbled upon the UpdateInvFullMessage server packet which has the following packet structure:

Code:

  - message: gg.rsmod.game.message.impl.UpdateInvFullMessage
    type: VARIABLE_SHORT
    opcode: 70
    structure:
      - name: component_hash
        type: INT
      - name: container_key
        type: SHORT
      - name: item_count
        type: SHORT
      - name: items
        type: BYTES

component_hash is packed as ParentId << 16 | ChildId & 65535 however it is not used in this case.

The real challenge lies in finding the container_key. Container keys are the way for the server to send the client different groups of items and easily swap between them, rather than having to always send the array of items again (say switching from inv to looting bag - the client can just cache both in a map).

To find the correct container key, I received a helpful tip from the r-s Discord to look at the decompiled cs2 scripts: https://github.com/RuneStar/cs2-scripts. A quick search for the terms "slide" and "puzzle" lands you on the [clientscript,trail_slidepuzzle_init] script, the important line is:

Code:

if_setoninvtransmit("trail_slidepuzzle_synch(false, $component0, $int5, $int6, $int3, $int4, $component1, $component2){inv_140, inv_221, inv_222}", $component0);

With some visually scanning and assumptions, we can see inv_140, inv_221, and inv_222 may be what we're after. Let's jot down 3 container keys 140, 221, and 222.

Finally, RSMod has a nice helper function called sendItemContainer(key, container) which we will help us send this packet.

Step 2 - Understanding the CS2 script

Spoiler for Step 2:

The full trail_slidepuzzle_init script looks like so:

Code:

// 688
[clientscript,trail_slidepuzzle_init](component $component0, component $component1, component $component2)
def_int $int3 = calc(37 + ((if_getwidth($component0) - (5 * 37)) / (5 - 1)));
def_int $int4 = calc(37 + ((if_getheight($component0) - (5 * 37)) / (5 - 1)));
def_int $int5 = pow(5, 2);
def_int $int6 = calc($int5 - 1);
cc_deleteall($component0);
def_int $int7 = 0;
while ($int7 < $int5) {
	cc_create($component0, ^iftype_text, $int7);
	cc_setsize(37, 37, ^setsize_abs, ^setsize_abs);
	cc_setposition(calc(($int7 % 5) * $int3), calc(($int7 / 5) * $int4), ^setpos_abs_left, ^setpos_abs_top);
	cc_setopbase("<col=ff9040>Sliding piece</col>");
	$int7 = calc($int7 + 1);
}
$int7 = 0;
while ($int7 < $int6) {
	cc_create($component0, ^iftype_model, calc($int7 + $int5));
	cc_setsize(37, 37, ^setsize_abs, ^setsize_abs);
	cc_setmodelangle(0, 0, 513, 0, 0, 1800);
	$int7 = calc($int7 + 1);
}
~trail_slidepuzzle_synch($component0, $int5, $int6, $int3, $int4, $component1, $component2);
if_setoninvtransmit("trail_slidepuzzle_synch(false, $component0, $int5, $int6, $int3, $int4, $component1, $component2){inv_140, inv_221, inv_222}", $component0);
if_setonvartransmit("trail_slidepuzzle_synch(true, $component0, $int5, $int6, $int3, $int4, $component1, $component2){var261}", $component0);

With some refactoring, we can build the following pseudo code:

Code:

trail_slidepuzzle_init (component container, component border1, component border2)
    pieceWidth = 37 + ((containerWidth - (5 * 37)) / (5 - 1));
    pieceHeight = 37 + ((containerHeight - (5 * 37)) / (5 - 1));
    pieceCount = 25
    modelCount = 24 // pieces - 1

    loop (0 to pieceCount) {
        create new text component with absolute size 37x37 
        set text component position offset in the puzzle based on it's index
        add left-click OP with text "<col=ff9040>Sliding piece</col>"
    }

    loop (0 to modelCount) {
        create new model component with abs size 37x37
        rotate and scale the model so it aligns with screen
    }

    trail_slidepuzzle_synch(container, pieceCount, modelCount, pieceWidth, pieceHeight, component1, component2)
    
    bindObserver -> if inv_140, inv_221, or inv_222 change, call trail_slidepuzzle_synch()
    bindObserver -> if var261 changes, call trail_slidepuzzle_synch()

border1 and border2 we will discover are the clue scroll border and the monkey madness border.
As we can see the interface in the cache is empty and this client script actually fills in the slots for the pieces - gives each piece a click option and a model to display an item.

Step 3 - More CS2 Deciphering & Varp

Spoiler for Step 3:

The slidepuzzle_init func ends with a call to trail_slidepuzzle_synch, let's take a look at it:

Code:

// 690
[proc,trail_slidepuzzle_synch](component $component0, int $int1, int $int2, int $int3, int $int4, component $component5, component $component6)
def_inv $inv7 = inv_140;
if (%var261 = 8) {
	$inv7 = inv_222;
} else if (%var261 = 7) {
	$inv7 = inv_221;
}
def_enum $enum8 = null;
def_enum $enum9 = null;
$enum8, $enum9 = enum(int, enum, enum_1864, %var261), enum(int, enum, enum_1865, %var261);
if ((%var261 = 7) | (%var261 = 8)) {
	if_sethide(true, $component5);
	if_sethide(false, $component6);
} else {
	if_sethide(false, $component5);
	if_sethide(true, $component6);
}
def_obj $obj10 = null;
def_int $int11 = 0;
while ($int11 < $int1) {
	if (($enum8 ! null) & ($enum9 ! null)) {
		$obj10 = inv_getobj($inv7, $int11);
		~trail_slidepuzzle_setint($int11, enum(obj, int, $enum9, $obj10));
		if (cc_find($component0, $int11) = ^true) {
			if (%var261 = 8) {
				cc_clearops;
				cc_setonop(null);
			} else {
				cc_setop(1, "Move");
				cc_setonop("trail_slidepuzzle_op(event_opindex, event_com, event_comid, $int1, $int2, $int3, $int4)");
			}
		}
		if (($int11 < $int2) & (cc_find($component0, calc($int1 + $int11)) = ^true)) {
			$obj10 = enum(int, namedobj, $enum8, $int11);
			if ($obj10 ! null) {
				cc_setmodel(oc_param($obj10, param_186));
			} else {
				cc_setmodel(null);
			}
		}
	} else {
		~trail_slidepuzzle_setint($int11, -1);
		if (($int11 < $int2) & (cc_find($component0, calc($int1 + $int11)) = ^true)) {
			cc_setmodel(null);
		}
	}
	$int11 = calc($int11 + 1);
}
~trail_slidepuzzle_position($component0, $int1, $int2, $int3, $int4);

We quickly notice a reference to %var261 and with some more assumptions, we can guess that this is a varp. A varp is the way for the server to set variables on the client by sending the following packet:

Code:

  - message: gg.rsmod.game.message.impl.VarpSmallMessage
    type: FIXED
    opcode: 63
    structure:
      - name: value
        type: BYTE
        trans: ADD
      - name: id
        type: SHORT
        trans: ADD

In our case, the cs2 script is trying to check the varp 261 for value 7 or 8. We will eventually realize that 7 and 8 are the special cases for Monkey Madness (7 = solving the puzzle, 8 = reviewing the completed puzzle/locked).

Simply put, the sync script checks if the varp is 7 or 8 and then changes the border of the interface by hiding and unhiding border1 and border2 respectively

Step 4 - CS2 Enums

Spoiler for Step 4:

The line

Code:

$enum8, $enum9 = enum(int, enum, enum_1864, varp_261), enum(int, enum, enum_1865, varp_261);

can be roughly refactored to

Code:

    
pieceSet = PIECE_COLLECTIONS[varp_261] // enum stored in cache - what picture is drawn - elvarg, gnome glider, zulrah
solvedPositions = PIECE_POSITIONS[varp_261] // enum stored in cache - map of piece itemId -> correct index/position

Basically, enums are hashmaps packed in to the cache. Using OpenOSRS cache we can dump all the enums in to json format. See enum_1864:

Code:

{
  "id": 1864,
  "intVals": [
    1354,
    1355,
    1356,
    1357,
    1358,
    1359,
    1872,
    1874
  ],
  "keyType": "INTEGER",
  "valType": "ENUM",
  "defaultString": "null",
  "defaultInt": -1,
  "size": 8,
  "keys": [
    1,
    2,
    3,
    4,
    5,
    6,
    7,
    8
  ]
}

The CS2 script is referencing keys[var261] from the enum, which returns the corresponding intVals (or stringVals) value.

The synch script is made even more confusing by the fact that it uses an enum inside of an enum. Observe the following lines

Code:

~trail_slidepuzzle_setint($int11, enum(obj, int, $enum9, $obj10));
can become
~trail_slidepuzzle_setint(i, solvedPositions[piece]);

and 


$obj10 = enum(int, namedobj, $enum8, $int11);
can become
piece = pieceSet[i];

Step 5 - Actually configuring the interface

Spoiler for Step 5:

So we know we need to init the puzzle script, which requires the parameters: container component and 2 border components. The component values must be a componentHash. Finding the correct component hashes is (as far as I know) going to take some guessing and trial and error.

I accomplished this by inspecting the slide puzzle interface hierarchy via OpenOSRS dumper. The layers of the interface are:

Code:

idx 0 - id 20054016, type 0, rawWidth 0, rawHeight 0, modelId 0
idx 1 - id 20054017, type 6, rawWidth 32, rawHeight 32, modelId 3437
idx 2 - id 20054018, type 6, rawWidth 32, rawHeight 32, modelId 3438
idx 3 - id 20054019, type 6, rawWidth 32, rawHeight 32, modelId 4695
idx 4 - id 20054020, type 0, rawWidth 193, rawHeight 193, modelId 0
idx 5 - id 20054021, type 5, rawWidth 26, rawHeight 23, modelId 0

Type 0 is a container type, type 6 is a model widget, and type 5 is a text widget. Knowing we need a container, we will try 20054016 and 20054020 as our first parameter to the init script. The borders are possibly 20054017, 20054018, or 20054019.

After some trial and error, I discovered that the following set of server packets:

Code:

    
player.setVarp(261, 7)
    player.openInterface(SLIDING_PUZZLE_INTERFACE_ID, InterfaceDestination.MAIN_SCREEN)
    player.runClientScript(688, 20054016, 20054018, 20054019)

produced this result:


Clearly 20054016 is the incorrect container because a piece is floating outside of the interface. This leaves 20054020 which results in the following:


Secondly, we must discover what the 2 border component IDs should be. With 3 options I opened my Map Editor and harcoded the object picker to spit out modelIds.

Widget 20054017 - modelId 3437 looks like:

Hmm, maybe the background?

Widget 20054018 - modelId 3438 looks like:

Looks like the default puzzle border

Widget 20054019 - modelId 4695 looks like:

The fancy Monkey Madness border!

Great, so it looks like we found our 2 border component IDs - 20054018 and 20054019.

Step 6 - Filling with Pieces

Spoiler for Step 6:

We have all the pieces we need, now we just need to send them down to the client. Going to https://everythingrs.com/tools/osrs/itemlist/ and searching for "Sliding" results in 100s of pieces. We could also get the piece ids from the PIECE_COLLECTIONS enum dump if we wanted to.

The code to fill our puzzle with piece items is very simple:

Code:

    val puzzContainer = ItemContainer(world.definitions, capacity = 25, stackType = ContainerStackType.NO_STACK)
    for (i in 2749..2772) {
        puzzContainer.add(i)
    }
    player.sendItemContainer(key = 140, container = puzzContainer)

    val mmContainer = ItemContainer(world.definitions, capacity = 25, stackType = ContainerStackType.NO_STACK)
    for (i in 3904..3998 step 2) {
        mmContainer.add(i)
    }
    player.sendItemContainer(key = 221, container = mmContainer)
    player.sendItemContainer(key = 222, container = mmContainer)

Recall from step 1 when we found that the item container keys were 140, 221, and 222.

Note that the pieces you fill container 140 with MUST correspond to the cache enum keys at var261 or the puzzle will not be interactable.

Finally, to tell the client to send button click packets, we must tell it which interface to bind. This can be done via:

Code:

player.setInterfaceEvents(interfaceId = 306, component = 4, range = 0..25, setting = 1086)

Each piece of the puzzle is a button which when clicked sends the client packet IfButtonMessage so you can see which slot was clicked. The server must follow the same rules as the client in order to stay in sync. Puzzle solving is left as an exercise for the reader.

I hope someone can find parts of this tutorial useful! Let me know if there are any errors or inconsistencies as I have only spent a day on this stuff.