01e9 -- OP_ClientCmdMsg::OP_EqUpdateGhostCmd --

[skandragon]

Anyone have a clue about the format of this command? It seems the data is mostly random... which sucks for analysis purposes.

Code: Select all

A5 66 43 A0 00 0F 0F 1A 83 07 80 E0 E2 E1 C5 7B 0A 09 82 36 30 00
40 68 43 A0 00 1C 36 F0 01 EA FE EE 2C E7 03 A5 74 0C 87 04 03 FF E0 18 C8 DD 4B 0F 33 34 3B 81 1D 30 00
AD 68 43 A0 00 16 0F FF 09 E2 E1 35 39 77 5B A2 7B 0A 81 36 FE 07 80 C9 DD C9 DD 4A 00
3A 69 43 A0 00 1D 2D FF 7A 50 04 24 DB 3B C8 EE 39 69 11 66 B7 0E 81 04 B8 08 A0 9A B7 15 6E 3E 66 68 35 00
70 6A 43 A0 00 2A 29 F0 34 F4 F1 EE 3B 8C B9 91 B7 C5 60 23 18 9E 06 1B 06 1B 0A FF E8 86 6D 03 BC F1 91 E8 F1 91 1E F1 9A 7F 80 06 83 03 99 24 00
24 6B 43 A0 00 2C 36 F0 3D 17 B8 EE F3 0F 0C DC 4A C0 03 FE 03 FF 03 D2 03 D2 81 04 B8 05 8E 45 BF 06 68 7F E1 05 40 EE A5 3A 06 19 D1 8D 10 E7 0B 27 00
B0 6B 43 A0 00 26 36 F0 01 91 FB FE 12 DE 7F E6 96 BF C0 01 8A BD BD 0A F7 EE 36 74 06 96 8D E7 A9 67 1E 78 7F DD B2 0F 33 33 0F 2B 00
3C 6C 43 A0 00 25 2D F0 06 77 40 EE 13 13 24 9E 31 C0 FF 8B 10 10 FF 81 04 B8 0F E0 85 B7 0D FA 4B F9 15 8E 0B 19 59 8C F4 E5 27 00
82 6C 43 A0 00 10 4B 1A 83 07 80 E0 C2 A7 C5 99 02 06 83 8B 2A 30 00
0D 6D 43 A0 00 1E 2D F0 03 8D 43 EE 06 32 51 88 F6 C0 FF 8B 0F 0F FF 81 04 B8 0A 15 8B B7 F5 60 4B F9 15 35 00
EA 6D 43 A0 00 2F 4B F0 06 C2 A7 E2 2A 99 02 81 8B FE 07 80 2F 5B 2F 5B 4A 36 F0 02 C9 C9 EE 02 2C 1A DD A0 0C 87 04 03 FF E0 20 F5 DD 95 0F 33 33 0D 81 0A 30 00

[CrabClaw]

Code: Select all

[A5 66] [43 A0 00] [0F 0F] [1A] [83 07] [80 E0] E2 E1 C5 7B 0A 09 82 36 30 00
[40 68] [43 A0 00] [1C 36] [F0] [01 EA FE EE] 2C E7 03 A5 74 0C 87 04 03 FF E0 18 C8 DD 4B 0F 33 34 3B 81 1D 30 00
[AD 68] [43 A0 00] [16 0F] [FF] 09 E2 E1 35 39 77 5B A2 7B 0A 81 36 FE 07 80 C9 DD C9 DD 4A 00
[3A 69] [43 A0 00] [1D 2D] [FF] 7A 50 04 24 DB 3B C8 EE 39 69 11 66 B7 0E 81 04 B8 08 A0 9A B7 15 6E 3E 66 68 35 00
[70 6A] [43 A0 00] [2A 29] [F0] [34 F4 F1 EE] 3B 8C B9 91 B7 C5 60 23 18 9E 06 1B 06 1B 0A FF E8 86 6D 03 BC F1 91 E8 F1 91 1E F1 9A 7F 80 06 83 03 99 24 00
[24 6B] [43 A0 00] [2C 36] [F0] [3D 17 B8 EE] F3 0F 0C DC 4A C0 03 FE 03 FF 03 D2 03 D2 81 04 B8 05 8E 45 BF 06 68 7F E1 05 40 EE A5 3A 06 19 D1 8D 10 E7 0B 27 00
[B0 6B] [43 A0 00] [26 36] [F0] [01 91 FB FE] 12 DE 7F E6 96 BF C0 01 8A BD BD 0A F7 EE 36 74 06 96 8D E7 A9 67 1E 78 7F DD B2 0F 33 33 0F 2B 00
[3C 6C] [43 A0 00] [25 2D] [F0] [06 77 40 EE] 13 13 24 9E 31 C0 FF 8B 10 10 FF 81 04 B8 0F E0 85 B7 0D FA 4B F9 15 8E 0B 19 59 8C F4 E5 27 00
[82 6C] [43 A0 00] [10 4B] [1A] [83 07] [80 E0] C2 A7 C5 99 02 06 83 8B 2A 30 00
[0D 6D] [43 A0 00] [1E 2D] [F0] [03 8D 43 EE] 06 32 51 88 F6 C0 FF 8B 0F 0F FF 81 04 B8 0A 15 8B B7 F5 60 4B F9 15 35 00
[EA 6D] [43 A0 00] [2F 4B] [F0] [06 C2 A7 E2] 2A 99 02 81 8B FE 07 80 2F 5B 2F 5B 4A 36 F0 02 C9 C9 EE 02 2C 1A DD A0 0C 87 04 03 FF E0 20 F5 DD 95 0F 33 33 0D 81 0A 30 00 

Hehe, reminds me of when I used to hack DOS game *.exe's to mod the game stats like X-Com, Transport Tycoon and such.
This is a pattern I see it looks like the fourth column has three types: A1, FF, and F0, then maybe some compression (compressed text? wild guess).

[skandragon]

More interesting to me is that the 3rd byte seems to increase, but not every time and not in conjunction with any other variable I can see there.
At first, I thought perhaps it was a <offset, new_value> tuple, but that doesn't work. Then I thought perhaps it was a <skip_bytes, new_value> but that also seems unlikely now.

[LethalEncounter]

Yah I know the format, kinda hard to explain though.

Code: Select all

A5 66 43 A0 00 0F 0F 1A 83 07 80 E0 E2 E1 C5 7B 0A 09 82 36 30 00 

A5 66 43 A0 -> sequence, live uses a time stamp here to ensure that all packets are processed in a specific order.
00 -> size of SpawnInfoStruct updates, in this case it isnt used.
0F -> size of SpawnPositionStruct updates, the most common one, this tells use that the next 15 bytes are for SpawnPositionStruct. Note that the first byte after the size is the spawn index that the update applies to. In this case index 15.
00 -> size of SpawnVisualizationInfoStruct updates, in this case unused.
As you can see from the position update that is included in this packet, the data is xor'd with the last update and then Packed before it is sent out.
Note that SpawnInfoStruct and SpawnVisualizationInfoStruct packets work exactly the same if they are included. So the finished packet is:
int32 sequence;
int8 info_struct_size (possibly overloaded to int16)
int8 ghost index, (can be overloaded to int16)
info_struct_size-1, data for info struct
int8 pos_info_size (possibly overloaded to int16)
int8 ghost index, (can be overloaded to int16)
pos_info_size-1, data for pos struct
int8 vis_info_size (possibly overloaded to int16)
int8 ghost index, (can be overloaded to int16)
vis_info_size-1, data for vis struct
The packet could contain updates for 3 different mobs.

[LethalEncounter]

Oh, and to throw some more into the mix: for the position update, if the index refers to a human player the 4 bytes after index will be the sequence number.

[oghog]

My head hurts now.
Thanks guys!

[skandragon]

As you can see from the position update that is included in this packet, the data is xor'd with the last update and then Packed before it is sent out.
...
The packet could contain updates for 3 different mobs.

I don't quite understand this yet.
Taking the last comment first, do you mean the id + 3 sections can be repeated in the same packet?
As for the XOR part, do you mean they take the Unpacked data from the original ghost create command, take the new data, XOR it, and Pack the result for the update? So to apply this (as if I were a client) I'd Unpack this update (which will have a LOT of zeros in it) and XOR it into the appropriate section of the Spawn Create packet (or the Unpacked portion of it)?

[LethalEncounter]

As you can see from the position update that is included in this packet, the data is xor'd with the last update and then Packed before it is sent out.
...
The packet could contain updates for 3 different mobs.

I don't quite understand this yet.
Taking the last comment first, do you mean the id + 3 sections can be repeated in the same packet?
As for the XOR part, do you mean they take the Unpacked data from the original ghost create command, take the new data, XOR it, and Pack the result for the update? So to apply this (as if I were a client) I'd Unpack this update (which will have a LOT of zeros in it) and XOR it into the appropriate section of the Spawn Create packet (or the Unpacked portion of it)?

huh? what id+3?
Yes, although each ghost section is handled (and xor'd) differently. Just because one changes doesn't mean the others change, which is why each update packet could contain info from up to 3 mobs, one update for each type.

[skandragon]

Ahh, I get what you mean now. You mean each of the three sections could (in theory) update different spawns.
So, the method is:
(1) When a ghost is created, store the uncompressed data.
(2) When a ghost is updated, unpack that section and xor it into the correct original unpacked block.
(3) re-parse the unpacked section that changed.
It seems that a lot of the "client commands" are really just a way to marshal an in-memory data structure into the client's address space. Sort of like a shared database. I wonder if the client ever modifes any of this data without the server's direct command to do so, or if it always sends a request and gets the update as a reply.
I suspect some of these can be easily mapped directly into data structures, so the client does not need to re-parse the data. This also means the server needs to keep track of what the client last saw, and what the current value is. Considering the unpacked size of each spawn in a zone is about 850 bytes, and I've seen up to 1000 of them in view of my client, and perhaps 70 clients in a zone... that's a bit of memory. Using other overhead, I'd not be surprised that each zone in memory consists of around 64MB just for spawn tracking.