Took a quick look at the new data on the test server.
@willcrutchley you’d probably be interested in this too. Managed to figure out a bit more of how the high level payload data works because of the small frames. (See number of records in frame, record length, API ID).
//== request frame
82 // FIN: true - opcode: 2
B4 // mask: true - payload len: 52
FC 41 29 7B // masking key (rest of data has unmask already applied)
02 00 // number of records in frame
08 00 // record length
4E // API ID
30 26 // item code
00 00 // ???
30 26 // item code again?
00 // null terminator
// Other records in frame
26 00 // record length
38 FE BB 2D 07 00 FF FF FF 00 00 00 00 E6 7A 94
3E 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 C0 40 00
//== response frame
82 // FIN: true - opcode: 2
7E // mask: false - payload len: 126
00 C3 // payload length: 195
05 00 // number of records in frame
37 00 // record length
4E // API ID
30 26 // item code
00 00 // spacer?
01 00 // probably sub-record count? (number of prices for this item)
43 40 // ???
00 00 // probably patrons?
10 // settlement name length
03 // guild name length
57 65 20 64 69 64 20 69 74 20 61 67 61 69 6E 21 // settlement
52 41 54 //guild
64 00 00 00 00 00 00 00 // quantity (need to verify length but makes sense this would need to be longer than just 1 stack like the shop records)
64 2B CB 95 00 00 00 00 // price
93 FF BC FF D5 41 // most if not all of this is the location. probably the same bit-packed location data as the shop records.
00 // null terminator
// Other records in the frame
06 00 // record length
21 E7 09 2D 07 00
17 00 // record length
0A 00 10 00 80 00 00 00 00 00 00 00 00 00 00 00
00 00 01 00 80 01 00
39 00 // record length
06 32 14 7A 04 01 75 DD C8 C4 35 FE 87 42 9A DA
7D C4 36 77 1B 40 1C 05 C5 02 60 3F E0 F1 9B BF
04 0A 0D E8 6F 3F 8C 4A B0 3E 3B 00 00 01 00 00
00 00 00 00 00 00 00 03 00
2A 00 // record length
06 2F 14 7A 03 01 87 C6 C8 C4 35 FE 81 42 30 46
84 C4 45 D8 96 3F 1C 05 E3 E9 2A 40 BB 24 5A BF
04 0A D9 5A 0E 3F 56 3F 55 3F