BNETDocs
S>C 0x11 MCP_REQUESTLADDERDATA
Message Id:0x11
Message Name:MCP_REQUESTLADDERDATA
Direction:Server to Client
Used By:Diablo II, Diablo II Lord of Destruction
Format:

 (UINT8) Ladder type
 (UINT16) Total response size
 (UINT16) Current message size
 (UINT16) Total size of unreceived messages
 (UINT16) Rank of first entry
 (UINT16) Unknown (0)
 (VOID) Message data

Message data:
(UINT32) Number of entries
(UINT32) Unknown (0x10)
For each entry:
    (UINT64)     Character experience
     (UINT8)     Character flags
     (UINT8)     Character title
     (UINT16)     Character level
     (UINT8)[16] Character name

Remarks

Received when requesting ladder data.

Multiple packets are received until all of the Message data is entirely received.

Total response size: The size of the entire batch of SID_REQUESTLADDERDATA messages, excluding their headers.

Current message size: The size of the current message, excluding its header.

Total size of unreceived messages: The total size of all the unreceived messages in the batch, excluding their headers and first bytes. In the last packet, this value is 0, since there are no unreceived messages.

Rank of first entry: Always zero, except in the last message. In the last message, this specifies the zero-based rank of the first entry. (For example if this is 17 in the last packet, then ladder entries 18-33 were retrieved.)

The server may respond with one or more of these messages. The client must not handle the data until the last packet in the batch is received.

The Message data should be concatenated backwards. For example, if 3 packets were received, then the data buffer should contain the data of the 3rd packet, followed by the data of the 2nd packet, followed by the data of the 1st packet. Only after the last packet was received, the data buffer should be parsed.

Important note: If the entry is the last entry in the packet, the character name might be smaller than 16 bytes. In this case, the client MUST add null bytes to the end of the packet, BEFORE adding it to the data buffer.

Ladder packets are NOT SENT IN ANY ORDER - They are often sent completely out of order and must be placed back into the proper order. You have to infer the sequencing based on the 'how big' fields in the 10 byte header.

The Message data, after reconstruction, contains:

Character flags

  • AND 0x07 to get character:
    • 0x00: Amazon
    • 0x01: Sorceress
    • 0x02: Necromancer
    • 0x03: Paladin
    • 0x04: Barbarian
    • 0x05: Druid
    • 0x06: Assassin
  • 0x08: Highlight this (if response to C > S [0x16] MCP_CHARRANK)
  • 0x10: Dead character (hardcore only)
  • 0x20: Hardcore character
  • 0x40: Expansion character

Character name: The character name is always 16 bytes. If the name is shorter than 16 bytes, the string is padded with nulls. The last byte is always null, since character names are limited to 15 chars.

| Edited:
Comments

no one has commented yet.