Client Packets

Credit: A large portion of this section was written by humanoid24, lcdr, and pwjones. Go back to packets page>
The purpose of this document is to list and protocol all the information about the network packets of the game LEGO Universe. For general details refer to the main packets document; the data and info listed here builds upon knowledge and structures listed there.

Disclaimer: The LEGO® Group has not endorsed or authorized the operation of this game and is not liable for any safety issues in relation to the operation of this game. All files are under the General Public License, version 3, and are only for use on a non-commercial basis.

CS_[53-00-00-00] (global - connection init, handshake)

Size: 59 bytes

[A:0x08,L:4] - Game/Network version (u32), this has to match with the server version, latest one is 171022

[L:4] - ???, is always 0?

[L:4] - remote connection type (this is for some reason a u32, although the packet header only has space for a u16, so 2 bytes are wasted), tells the client what number he has to put in the header for his next packets (after the init sequence), this is always 5?

[L:4] - process id of the client, u32

[L:2] - ???, is always different?

[L:33] - unused for client? (string), this would normally be a local ip, is this only used for server?

To Auth:

CS_[53-01-00-00] (login info)

Size: 959 bytes

[A:0x08,L:66] - Username (wstring), max length would be 32 but you can only enter up to 30 chars in the login screen (I doubt the 4 remaining bytes mean anything, it would also fit for later)

[L:82] - Password (wstring)

[L:2] - ???, is always 09 04? (string COMLANG and argument 0x409 appears just before it seems to be written in the client code so I guess its safe to assume as constant and unimportant?)

[L:1] - ???, could be a count for something (maybe the following info)? it could also be an identifier for the platform (I encountered something like that in the code for values 2 and 1: “mac” or “pc”), seems to be always 1

[L:512] - process memory info of the client, wstring (see GetProcessMemoryInfo() on MSDN for more info, the values get constructed to a wstring in the client code)

[L:256] - client graphics card (driver) info, wstring

[L:4] - SYSTEM_INFO.dwNumberOfProcessors, u32

[L:4] - SYSTEM_INFO.dwProcessorType, u32

[L:2] - SYSTEM_INFO.dwProcessorLevel, u16

[L:2] - SYSTEM_INFO.dwProcessorRevision, u16

[L:4] - ???, doesn’t seem to be part of the above/below struct (but is apparently written as constant (0x114) in the packet?)

(the following structures can be skipped or does the client abort packet creation if that happens?)

[L:4] - OSVERSIONINFO.dwMajorVersion, u32

[L:4] - OSVERSIONINFO.dwMinorVersion, u32

[L:4] - OSVERSIONINFO.dwBuildNumber, u32

[L:4] - OSVERSIONINFO.dwPlatformId, u32

To World:

CS_[53-04-00-01] (user session info)

Size: 173 bytes

[A:0x08,L:66] - username (wstring)

[L:66] - user key from auth (wstring)

[L:32] - some hashed string? (string)

[L:1] - ???, is either 0 or 1 (so we can’t assume this the final null from prev string?)

CS_[53-04-00-02] (minifigure list request)

automatically sent from the client when it connects from auth, also sent whenever the client needs the character list

Size: 8 bytes

CS_[53-04-00-03] (minifigure create request)

[A:0x08,L:66] - Name of new minifigure, wstring (since you can only enter up to 24 characters in the client the last 16 bytes will be always unallocated?)

[L:4] - First part of predef name, taken from minifigname_first.txt (line number-1), u32

[L:4] - Second part of predef name, taken from minifigname_middle.txt, u32

[L:4] - Third part of predef name, taken from minifigname_last.txt, u32

[L:9] - ???

[L:4] - Shirt color, u32

[L:4] - Shirt style, u32

[L:4] - Pants color, u32

[L:4] - Hair style, u32

[L:4] - Hair color, u32

[L:4] - “lh”, see “<mf />” row in the xml data from chardata packet (no idea what it is)

[L:4] - “rh”, see “<mf />” row in the xml data from chardata packet (no idea what it is)

[L:4] - Eyebrows, u32

[L:4] - Eyes, u32

[L:4] - Mouth, u32

[L:1] - ???

CS_[53-04-00-04] (user wants to join world)

Size: 16 bytes

[A:0x08,L:8] - object ID of selected Minifig

CS_[53-04-00-05] (client game message)

[A:0x08,L:8] - ID of object

[L:2] - Game message ID

[L:ID specific] - Game message payload

Chat Command

[A:0x12,L:4] - all 0s

[L:4] - Length of command

[L:V] - Command (including slash, this may indicate that the same ID is used for normal chat, but since we haven’t found out how to respond to the “whitelist request” packet yet we can’t confirm this)

CS_[53-04-00-06] (character delete request)

[A:0x08,L:8] - ID of minifig to delete

CS_[53-04-00-07] (character rename request)

[A:0x08,L:8] - ID of minifig to rename

[L:66] - New name

CS_[53-04-00-0e] (chat message)

Size: variable

[A:0x08,L:3] - ???, probably something like chat channel

[L:4?] - length of message (including null terminator, as characters (meaning this * 2 = actual binary length)

[A:0x0f,L:V] - chat message

CS_[53-04-00-13] (clientside load complete)

Size: 16 bytes (always?)

[A:0x08,L:2] - zone ID (u16)

[L:2] - map instance (u16)

[L:2] - map clone (u16)

CS_[53-04-00-15] (some kind of indicator that this packet should be routed)

Size: variable

[A:0x08,L:4] - length of following

[L:1] - normal packet but without the first (0x53) byte

CS_[53-04-00-16] (position/rotation updates)

Size: 56 bytes without moving, 68 bytes when changing rotation, 80 bytes when changing position

[A:0x08,L:4] - Position X, float

[L:4] - Position Y, float

[L:4] - Position Z, float

[L:4] - Rotation X, float

[L:4] - Rotation Y, float

[L:4] - Rotation Z, float

[L:4] - Rotation W, float

there’s a bunch of (probably important) other stuff after this (part of which also seems to depend on what the player did, see packet size above)


position: Vector3D, floats

rotation: Quaternion, floats

todo - analyze (gets sent every time the player moves/turns, if he doesn’t it gets sent after a few seconds)

CS_[53-04-00-17] (Mail stuff)

Size: variable

[A:0x08,L:4] - Mail stuff ID

[L:ID specific] - ID specific

todo: investigate [A:0x0c,L:4]

Mail stuff IDs

0x03 - Mail data request

0x05 - Mail attachment remove

0x07 - Mail delete

0x09 - Mail read

0x0b - mail notification request?

Mail data request

Always 53 04 00 17 00 00 00 00 03 00 00 00

Mail attachment remove

[A:0x0c,L:4] - ???

[L:8] - ID of mail from which the attachment is to be removed

[L:8] - ID of minifig

respond to this with attachment remove confirm

Mail delete

[A:0x0c,L:4] - ???

[L:8] - ID of mail to be deleted

[L:8] - ID of minifig

respond to this with delete confirm

Mail read

[A.0x0c,L:4] - ???

[L:8] - ID of read mail

respond to this with read confirm

CS_[53-04-00-19] (whitelist request)

[A:0x08,L:1] - Super chat level (u8)

[L:1] - Request ID (incremented per request)

[L:84] - If private chat, name of receiver (wstring)

[A:0x5e,L:2] - Length of string (u16)

[L:V] - String to be checked against the whitelist (e.g chat input, mail input) (2-byte char)

CS_[53-04-00-1b] (model preview request?)

This gets sent when you set “UGCUSE3DSERVICES” in boot.cfg to 0 and open the models tab of the backpack.

Size: 17 bytes (always?)

[A:0x08,L:8] - Model ID?

[A:0x11,L:1] - ??? Request type?

CS_[53-04-00-1e] (“handle funness” in client enum)

Seems to be sent when client is laggy? (Easier reproducible when launching via debugger)

Size: 16 bytes

[A:0x08,L:8] - ???

CS_[53-04-00-20] (“request free trial refresh”)

Size: 8 bytes (always?)

todo - reproduce (this gets sent one times at the end of the first world traffic of the newly created minifigure traffic (didn’t see it in other traffics…)

CS_[53-04-00-78] (???)

todo - analyze/reproduce (this gets sent multiple times at the end of one world traffic (didn’t see it in other traffics…)