Server 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.

SC_[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 client version (otherwise client disconnects), latest one is 171022

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

[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), for auth this is 1, otherwise its 4

[L:4] - process id (I assume from the server?), u32

[L:2] - ???, is always 0xff?

[L:33] - local IP of the server? string, has the range of an internal IP (always?), it doesn’t seem to be important (perhaps try it with a server that is non-local?)

SC_[53-00-00-01] (disconnect notify)

[A:0x08,L:4] - disconnect id

Possible values:

0x00 -> unknown server error

0x04 -> duplicate login

0x05 -> server shutdown

0x06 -> server unable to load map

0x07 -> invalid session key

0x08 -> account was not in pending list

0x09 -> character not found

0x0a -> character corruption

0x0b -> kick

0x0d -> free trial expired

0x0e -> play schedule time done

[L:4] - ???

SC_[53-00-00-02] (general notify)

Artificial packet

[A:0x08,L:4] - notify id

Possible values:

0x00 -> logged off duplicate account

Sent by Auth:

SC_[53-05-00-00] (login info)

Size: dependent on user input (if its valid or not)

[A:0x08,L:1] - was submitted user information correct? (u8), values are

0x00, 0x03, 0x04, 0x0f-0xff -> General Failed (+error code), shows “We could not sign you in to LEGO Universe” message ingame

0x01 -> Success

0x02 -> Account is banned

0x05 -> Account permissions not high enough (if a custom message is included in the packet it will be displayed in frontend, otherwise the message for “General Failed” will be shown)

0x06 -> Invalid Username or Password

0x07 -> Account is currently locked (wrong password entered too many times)

0x08 -> same as 0x06, perhaps just “Invalid Username”? (since 0x06 appeared in the logged traffic due to an invalid password)

0x09 -> Account Activation Pending (shows the same ingame message as 0x06/0x08)

0x0a -> Account is disabled (shows the same message ingame as 0x06/0x08)

0x0b -> Game Time Expired

0x0c -> Free Trial Has Ended

0x0d -> Play schedule not allowing it

0x0e -> Account not activated

[L:33] - a string, seems to be always “Talk_Like_A_Pirate”, no idea what it is for and if the whole 33 length is reserved for it (or even more like the next structs up to the next u16)

[R:0x2a,L:33]*7 - ???, reserved for 7 other strings? or does it actually contain relevant data, it seems every 33rd byte is mostly != 0 but in between are always zeroes

(not relevant for current server but still interesting: [A:0x4b,L:66] and [A:0x8d,L:2] are IP and port for the beta client)

[R:0x111,L:2]*3 - client version number (at least I’m pretty sure, the numbers fit with 1.10.64), separated by 0x00 or each number is just u16? for some reason the client doesn’t care for this struct though (any number is accepted)

[L:66] - user key (wstring), newly generated with every login?

[L:33] - IP to redirect to a char instance (string)

[L:33] - “ChatIP” according to a debug message in the client (string)

[L:2] - port number of next instance (u16)

[L:2] - “ChatPort” according to a debug message in the client (u16)

[L:33] - ???, reserved for another IP (perhaps an alternative one)? was always 0 so far

[L:37] - ???, some kind of UUID? seems to be always “00000000-0000-0000-0000-000000000000” (has same format as a GUID, see Visual Studio->Tools->Create GUID)

[L:4] - ???, seems to be always 0? (u32)

[L:3] - localization (string), US and IT occurred so far, we probably have to guess other values (can they be 3 characters long or is that last byte reserved for 0?)

[L:1] - if set to 1 it shows a screen that indicates that its the first time the user logged in with a subscription (only shows up again after restarting client), u8

[L:1] - 0 if user is subscribed (u8), 1 if user doesn’t have subscription (free member?), displays the blue box at the top right, do any other values have a different effect?

[L:8] - ???, always 0?

[L:2] - length of custom error message (not actual byte length) (u16)

[L:V] - custom error message, only visible with login code 0x05 (wstring)

[L:4] - how much more bytes there are (u32) which are occupied by x stamp structures so its easily calculable, for some reason the 4 bytes from this structure seem to be included

[L:4] - id of stamp (u32), see client log for names or server source for enum, these stamps seem to be logs of what happened in the server, thats why the number of stamps isn’t always the same (in case of failed login, etc?)

[L:4] - number in brackets (s32), can be negative, see client log for structure of stamps

[L:4] - number after brackets, “ [number]”, this seems to be a timestamp in seconds (see client log), the same number for most stamps but sometimes +/-1 compared to the other stamp values (if thats the case then its also “start+1” or “last+1” in the client log?)

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

SC_[53-05-00-01] (logout response)

Theoretical packet

From what I understand from client code, this has no effect at all?

Sent by World:

SC_[53-05-00-02] (world info?)

Size: 38 bytes

[A:0x08,L:2] - zone ID (u16), see cdclient.xml

[L:2] - map instance (name from crash log)

[L:4] - map clone (name from crash log)

[L:4] - map checksum

[L:2] - ???

[L:4] - player position x (float32)

[L:4] - player position y (float32)

[L:4] - player position z (float32)

[L:4] - 00 00 00 00 unless it is a battle then it is 04 00 00 00 (so far)

(player position is probably for preloading content in the vicinity of the player)

SC_[53-05-00-03] (“create object”)

Theoretical packet

From what I understand from client code, this has no effect at all?

SC_[53-05-00-04] (detailed user info)

Size: dependent on user progress and his number of items

[A:0x08,L:4] - size of following data, u32

[L:1] - flag indicating if content is compressed, always 1 so far, u8

[L:4] - size of uncompressed data, u32

[L:4] - size of the following (compressed) data, u32

[L:V] - compressed data in LDF format, these are all keys (and datatypes) from this packet in the captured traffics:

accountID: 8

bbbAutosaveDirty: 7

chatmode: 1

editor_enabled: 7

editor_level: 1

freetrial: 7

gmlevel: 1

legoclub: 7

levelid: 8

matchTeam: 1

matching.droppedItem: 9

matching.matchKey: 8

matching.matchPlayers: 1

matching.matchStamp: 8

matching.matchTeam: 1

name: 0

objid: 9

position.x: 3

position.y: 3

position.z: 3

propertycloneid: 1

propertycloneid: 5

reputation: 8

requiresrename: 7

rotation.w: 3

rotation.x: 3

rotation.y: 3

rotation.z: 3

rspPosX: 3

rspPosY: 3

rspPosZ: 3

template: 1

transfer_use_pos: 7

transferspawnpoint: 0

txfring: 7

xmlData: 13

SC_[53-05-00-05] (“create character extended”)

Theoretical packet

From what I understand from client code, this has no effect at all?

SC_[53-05-00-06] (minifigure list of user)

Size: dependent on how many minifigures the user has

charactersLength=[A:0x08,L:1] - Number of characters (00 - 04), u8

[L:1] - Index of character in the front


[L:8] - Character ID (=ChildID from replica packets = objID in xml data from chardata)

[L:4] - ???

[L:66] - Name of character (wstring)

[L:66] - Name that shows up in parentheses in the client (probably for not yet approved custom names?) (wstring)

[L:1] - boolean whether custom name was rejected (0x01 if rejected)

[L:1] - boolean whether the character is FreeToPlay (0x01 if FreeToPlay), if this set but the account FreeToPlay flag in the login response packet isn’t, it asks whether you’d like to change your FreeToPlay name to a custom name

[L:10] - ???

[L:4] - Shirt color

[L:4] - ???

[L:4] - Pants color

[L:4] - Hair style

[L:4] - Hair color

[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

[L:4] - Eyes

[L:4] - Mouth

[L:4] - ???

[L:2] - last zone ID

[L:2] - (very likely) map instance

[L:4] - map clone (name from [53-05-00-02] structure)

[L:8] - last login or logout timestamp of character in seconds? (xml is “llog” so both could be possible)

[L:2] - number of items to follow

[L:V] - equipped item LOTs (order of items doesn’t matter? I think it reads them in order so if we accidentally put 2 shirts the second one will be the one shown.)

todo - investigate unknown

SC_[53-05-00-07] (minifigure creation response)

this should come with an updated character list packet

Size: 9 bytes (not sure about this, I only have one capture available)

[A:0x08,L:1] - creation response ID

Creation response IDs

0x00 - Success

0x01 - (this ID isn’t working)

0x02 - Name not allowed

0x03 - Predefined name already in use

0x04 - Custom name already in use

SC_[53-05-00-08] (character rename)

Artificial packet

[A:0x08,L:1] - character rename response ID

Rename response IDs

0x00 - Success

0x01 - Unknown error

0x02 - Name unavailable

0x03 - Name already in use

todo: investigate

SC_[53-05-00-09] (chat service response)

Artificial packet

[A:0x08,L:4] - Chat service response (0x00 -> success)

todo: further analyze

SC_[53-05-00-0a] (account stuff?)

Artificial packet

[A:0x08,L:1] - account creation return type, values:

0x00 -> Successfully created account

0x01 -> Failed to create account

0x02 -> Failed to create account. User login already exists

other -> Failed to create account. Unknown Response

todo: investigate

SC_[53-05-00-0b] (character delete response)

Size: 9 bytes

[A:0x08,L:1] - deletion return code? (in the one sample we have, this is 0x01 (=Success? ))

upon receival the client sends a character list request

todo: investigate

SC_[53-05-00-0c] (server game message)

Size: variable (depending on message)

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

[L:2] - Game message ID

[L:ID specific] - ID specific

07-02 (Survey URL)

[A:0x12,L:4] - length of following string (amount of characters excluding null character)

[L:80] - Survey URL

[L:5] - ??? may still be allocated to URL

0d-03 (game object message?)

[A:0x12,L:4] - length of following string (amount of characters excluding null character)

[L:V] - game message instruction? (wstring, variable but with terminating null character)

5a-03 (Chat message)

[A:0x12,L:4] - Length of Additional Parameters

[L:V] - Additional parameters (2-byte char)

[L:2] - 0 (this might be a null termination of the string above, but a null termination wouldn’t be necessary as the string is variable)

[L:4] - Length of message

[L:V] - Message

a0 04 (GUI Message)

[A:0x12,L:2] - ??? , this was always 0x0901 so far

[L:V] - Message arguments

The arguments are encoded in AMF3 (

( for shorter link))

Argument structure summary:

length of key*2+1 | key (1-byte char) | data type | (if string length of string*2+1) | data

[L:1] - 0x01

[L:4] - Length of message name

[L:V] - Message name (1-byte char)

GUI Message Announcement

Keeping this for the future, we can simply use the UI debugger to find the right messages

[A:0x14,L:1] - Length of following string * 2 + 1 (the 1 is probably for the 0x06)

[L:8] - Literal string “message” + 0x06

[L:1] - Length of announcement body * 2

[L:V] - Announcement body (1-byte char)

[L:1] - Length of following string * 2 + 1 (the 1 is probably for the 0x06)

[L:6] - Literal string “title” + 0x06

[L:1] - Length of announcement title * 2

[L:V] - Announcement title (1-byte char)

[L:1] - Length of following string * 2 + 1 (the 1 is probably for the 0x03)

[L:8] - Literal string “visible” + 0x03

[L:1] - 0x01 (changing this will crash the client)

[L:4] - Length of following string

[L:14] - Literal string “ToggleAnnounce”

e6 05 (News panel Top Properties)

[A:0x12,L:0x04] - Amount of properties

[L:8] - ID of owner ?

[L:8] - Another minifig ID?

[L:4] - Length of owner name in 1-byte char

[L:V] - Name of property owner (2-byte char)

[L:8] - Reputation

[L:4] - ???

[L:4] - Length of title in 1-byte char

[L:V] - Title (2-byte char)

[L:4] - Length of description in 1-byte char

[L:V] - Description (2-byte char, not null terminated (can’t test if it honors null termination since it is not displayed))

[L:4] - PC computing load index for property (not actual value displayed, also not sure if the first 2 bytes are part of it, but since changes to the last 2 bytes result in large displayed value changes, I think they are)

[L:12] - ???

SC_[53-05-00-0d] (“chat connect”)

Theoretical packet

From what I understand from client code, this has no effect at all?

SC_[53-05-00-0e] (redirection to new server)

Size: 44 bytes

[A:0x08,L:33] - IP of the next instance (string), again not sure if all 33 bytes are reserved for this but it would make sense

[L:2] - port number of next instance (u16)

[L:1] - boolean, if 1, an announcement “Mythran Dimensional Shift Succeeded” is displayed (the announcement displays succeeded regardless of whether the redirect worked or not) (u8)

SC_[53-05-00-0f] (map reload notification?)

Artificial packet

todo: investigate

SC_[53-05-00-10] (GMlevel change)

Artificial packet

[A:0x08,L:1] - Boolean whether change was successful

[L:2] - Highest GMlevel possible (printed when not successful)

[L:2] - Previous GMlevel

[L:2] - Current GMlevel

todo: further analyze

SC_[53-05-00-11] (“HTTP monitor info response”)

Artificial packet

[A:0x08,L:2] - Port number

[L:1] - boolean whether to open "sum" page in browser (0x01 opens in browser)

[L:1] - supported page “sum” flag (0x01 if supported)

[L:1] - supported page “detail” flag (0x01 if supported)

[L:1] - supported page “who” flag (0x01 if supported)

[L:1] - supported page “objects” flag (0x01 if supported)

SC_[53-05-00-12] (push map response (happy flower stuff)

Artificial packet

todo: investigate

SC_[53-05-00-13] (pull map response (happy flower stuff))

Artificial packet

todo: investigate

SC_[53-05-00-14] (lock map response (happy flower stuff))

Artificial packet

todo: investigate

SC_[53-05-00-15] (“blueprint save response”)

[A:0x08,L:8] - objectID of something (s64), not sure about that but it had the value range of a non-player objectID in the packet that I checked (8th byte was 0x4)

[L:4] - ???, was 0 in the packet that I checked

[L:4] - ???, was 1 in the packet that I checked

[L:8] - could be ID of object (similar, if not the same, to the one in 53-05-00-0c, the range would fit with the 8th byte being 0x10)

[L:4] - size of the following data (u32)

// the following 3 structs can actually be assumed as its own format (sd0, similar to ldf) since they are appearing exactly like that in compressed client files (excluding the prev struct)

[L:5] - sd0 header struct, seems to be always the same if you look at some compressed client files that have this header (“sd0” followed by 0x01 and 0xff)

[L:4] - size of the following data (u32), I assume the offset is variable due to the fact that client files also have this multiple times if they are large enough (> 1024*256 bytes)

[L:V] - compressed data (lxfml data in this case), I assume the offset is variable due to the fact that client files also have this multiple times if they are large enough (> 1024*256 bytes)

SC_[53-05-00-17] (“blueprint load response itemID”)

todo: investigate

SC_[53-05-00-1a] (debug output)

Artificial packet

[A:0x08,L:4] - Length of message

[L:V] - Message

todo: investigate

SC_[53-05-00-1b] (Friend/Best friend request)

[A:0x08,L:66] - Name of friend who requested

[L:1] - Best friend request flag (0x01 if best friend request, 0x00 if normal friend request)

SC_[53-05-00-1c] (friend request response)

Size: variable

[A:0x08,L:1] - response type

Response types:

0x00 - "<name> is now your Friend."

0x01 - "<name> is already your Friend."

0x02 - "<name> is not a valid player name."

0x03 - "Unable to add <name> to your Friends."

0x04 - "Sorry, your Friends List is already full."

0x05 - "<name>'s Friends List is full."

[L:1] - is player online, u8

[L:66] - player, wstring

[L:8] - minifig ID

[L:2] - World ID

[L:6] - World instance

[L:6] - World clone

[L:1] - is player best friend, u8

[L:1] - is player FTP. u8

SC_[53-05-00-1d] (remove friend response)

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

[L:66] - Name of friend to be removed

SC_[53-05-00-1e] (friends list)

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

[L:2] - Length of packet - 1

[L:2] - Amount of friends

[L:1] - is online, u8

[L:1] - is best friend, u8

[L:1] - is FTP, u8

[L:5] - ???

[L:2] - World ID, u16

[L:2] - World Instance, u16

[L:4] - World Instance, u32

[L:8] - Friend’s minifig ID, s64

[L:66] - Friend name, wstring

[L:6] - ???

might also contain map instance of friend to facilitate switching to friend functionality?

SC_[53-05-00-1f] (friend update)

Size: variable

[A:0x08,L:1] - update type, u8

Update types

0 - friend logged out

1 - friend logged in

2 - friend changed world/ updated

[L:66] - Name of friend (wstring)

[L:2] - if friend logged in, world ID of friend

[L:6] - ???

[L:1] - boolean, 1-> best friend, 0 -> normal friend, u8

[L:1] - ???

chat notification is displayed if log in/out and friend is updated in friends list

SC_[53-05-00-20] (add blocked)

Artificial packet

[A:0x08,L:?] - Name of player being added

todo: investigate

SC_[53-05-00-21] (remove blocked)

Artificial packet

[A:0x08,L:?] - Name of player being removed

SC_[53-05-00-22] (block list)

todo - analyze (comes together with [53-05-00-1e] during the first few packets of world join?)

seems to be similar to friends list but with less information

SC_[53-05-00-23] (team invite)

Size: 82 bytes

[A:0x08,L:66] - Name of player who sent the invite

[L:8] - ID of player who sent the invite

SC_[53-05-00-24] (team invitation response?)

Artificial packet

todo: investigate

SC_[53-05-00-25] (guild creation response?)

Artificial packet

displayed “guild could not be created” in testing

todo: investigate

SC_[53-05-00-27] (guild invitation?)

Artificial packet


todo: investigate

SC_[53-05-00-28] (guild invitation response?)

Artificial packet

displayed “Could not invite <player>” (replace <player> of course) in testing

todo: investigate

SC_[53-05-00-29] (guild invitation response again?)

Artificial packet

displayed “CLIENTMSG_COULD_NOT_INVITE_NAME” in testing

todo: investigate

SC_[53-05-00-31] (world - Mail stuff)

[A:0x08,L:0x08] - ID

[L:ID specific] - ID specific

Mail system IDs

0x02 - Mail notification

0x04 - Mail data

0x06 - Mail attachment remove confirm

0x08 - Mail delete confirm

0x0a - Mail read confirm

Mail notification

[A:0x10,L:32] - does nothing / unknown

[L:4] - Amount of new mails

[L:4] - does nothing / unknown

Mail data

mailsLength=[A:0x10,L.1? might be 2] - Amount of mails

[A:0x12,L:2] - ???


[L:8] - Mail ID

[L:100] - Mail subject (wstring)

[L:800] - Mail body (wstring)

[L:56?] - Mail sender (wstring)

[L:28] - Still allocated to sender?

[L:4] - Attachment (if no attachment then ff ff ff ff (-1)), s32

[L:28] - ???

[L:8] - Send time (in seconds since 1970)

[L:1] - Read flag (0x01 if read)

[L:7] - ???

Mail attachment remove confirm

[A:0x10,L:8] - ID of mail from which the attachment is removed

Mail delete confirm

[A:0x10,L:8] - ID of deleted mail

Mail read confirm

[A:0x10,L:8] - ID of read mail

SC_[53-05-00-33] (overview of online players?)

Artificial packet

[A:0x08,L:1] - ??? some kind of boolean (u8)

if previous byte is set to 0:

[A:0x09,L:2] - Total players (u16)

[A:0x0b,L:?] - anything in here lags out the client

if the byte is set to 1:

[A:0x09,L:4] - Real online players (s32)

[A:0x0d,L:4] - Simulated online players (s32)

prints amount of online players in chat

todo: investigate

SC_[53-05-00-34] (player location command response ?)

Artificial packet

[A:0x08,L:1] - boolean, 1-> player online, 0-> player not online (u8)

[L:2] - Zone

[L:2] - I (Instance?)

[A:0x11,L:?] - Player name (wstring)

displays “Player:<x> Zone:<y> (I:<z>)” (replace variables in angle brackets) chat notification

SC_[53-05-00-35] (chat message send failure response?)

Artificial packet

[A:0x08,L:1?] - response type

Response types:

0x00 - "Chat is currently disabled."

0x01 - "Upgrade to a full LEGO Universe Membership to chat with other players."

SC_[53-05-00-38] (???)

Artificial packet

displayed “Sorry, that phrase isn’t acceptable in LEGO Universe” in testing

todo: investigate

SC_[53-05-00-39] (minimum chat mode response)

Size: 10 bytes

[A:0x08,L:2] - ??? (was always 00-08 so far and only occurred in instances (survival etc) )

SC_[53-05-00-3a] (minimum chat mode response private)

todo: investigate

SC_[53-05-00-3b] (chat moderation response)

[A:0x08,L:1] - if 0x01 whole request was accepted?

[L:2] - ???

[L:1] - moderation request ID

[L:1] - ???

[L:66?] - if private chat, name of recipient

[A:0x61,L:1] - start index of string that was not accepted

[L:1] - length of string that was not accepted

following this are more start/length structures, haven’t found out the total count yet

todo: investigate

SC_[53-05-00-3e] (server state/status?)

Size: 9 bytes

[A:0x08,L:1] - ???, always 1?

SC_[53-05-00-3f] (GM ended private chat)

Artificial packet

displayed “The Mythran has ended your private chat session” in testing

todo: investigate