LEGO Universe Packet Structure Documentation

Introduction:

The purpose of this documentation is to list and protocol all the information about the network
packets of the game LEGO Universe.
The documentation is organized into separate sub-documents:

Client Packets
Server Packets
Chardata Packet XML Structure
Replica Packets

Game Messages
Game Mechanics

File Structures

The format used to describe binary structures is documented in the doc Structure Definition
Format.

If any of these documents helped you in some way or another for one of your projects then
please credit us and/or include a direct link to this document.

Disclaimer:
LEGO is in no way affiliated with the content of this and the aforementioned documents.
Furthermore the creators of the just mentioned documents are not associated or involved with
LEGO.

Contact Info:
Most developer activity happens on the LEGO Universe Community Hub (LUCH) discord
nowadays. If you join there and ask a question, it’s quite likely someone will be able to help you
out. Devs from all major server projects are active in LUCH.
If you want to contact lcdr, you can also do so via twitter, the lcdr Universe forums, and the lcdr
Universe discord.

by lcdr and humanoid24 | licensed as CC BY-NC-SA 4.0

Contributions by Alanzote, Avery, jon002, Knightoffaith, pwjones, Raine, Simon Nitzsche, Xiphoseer and others
Contact us if we forgot to list your name
Contact
Quick Notes to get started:
Client:
- This documentation is targeted towards the latest publicly released client (1.10.64)
- To redirect the client to a different server simply change the “AUTHSERVERIP” host info in
the boot.cfg file to a new host
- The client stores an additional config and a log file from the last session in the
“%LOCALAPPDATA%\LEGO Software\LEGO Universe\” folder

Server:
- The client uses the RakNet network library (v3.25) to communicate with the server,
therefore it is recommended to use it in the server if you want to work on one and are
new to this project.
You can download it here (documentation and sample projects are included), note that
later versions of the library won’t work due to changes in the network protocol.
Alternatively lcdr wrote a python version with the minimum features needed to run a
server for the game implemented, available here (no documentation yet so not
recommended for inexperienced users)
- The listening port for the Authentication Server is hardcoded to 1001 (UDP), the ports for
the following instances (char, world) depend on what the Authentication Server sends to
the client but the port range used for the original servers was 2001-2200 (UDP)
- In order for the server to establish a working connection with the client it is required to
set up a pre-set password in RakNet by calling “SetIncomingPassword("3.25 ND1", 8);”
for the RakPeerInterface instance before listening for packets
- It seems that the server used the “SYSTEM_PRIORITY” and “RELIABLE_ORDERED” options for
all outgoing packets to the client (though that's probably not a requirement)
- The template for the ZoneControl object is located at the ZoneTable table. If NULL, the
default template is 2365. It’s objectID seems to be a spawnerID and is (2^46 - 2).
- The game had 3 different performance configurations for the physic engine on each
world declared at the ZoneTable. (high = ???, medium = ???, low = ???, default:
medium)
- According to activities, LU Servers used Microsoft ActiveX Data Objects.
- If an object’s collision type is set to HKX, but no path is given, it will use a 2x2x2 cube.

Packet Captures:
Thanks to pwjones we have access to quite a lot of (partial) traffic sessions of the original server
which serve as a basis for this documentation, if you want to dig into them yourself, here is a
download link. The captures are contained within the .rar files, make sure to extract them (as
well as the .zip containing them if you downloaded the folder as a .zip).

Since the original captures (*.pcap files) were encrypted by RakNet it was required to decrypt
them again (*.bin files stored in *.zip archives where each archive represents a session) which
was only possible using a piece of information that RakNet exchanges at the beginning of a
traffic.

by lcdr and humanoid24 | licensed as CC BY-NC-SA 4.0

Contributions by Alanzote, Avery, jon002, Knightoffaith, pwjones, Raine, Simon Nitzsche, Xiphoseer and others
Contact us if we forgot to list your name
Contact
However since more than half of the captured traffic sessions only consist of a fraction of the
entire session this information is missing for those captures (marked as *_unresolved.pcap),
making them undecryptable at this point (they’re still included in the archives though, so all
available captures are in one place).
There are a few exceptions where it was possible to decrypt them using the same information
from other traffic sessions but the remaining ones can’t be decrypted with this method so they’ll
remain unreadable for the time being.

The naming format used is:

[packet number]_[source port]-[destination port]_[packet header]_[optional].bin
where [optional] is used to display game message ids or network ids and LOTs in round
brackets for the according packet types.

Extracting the entire .zip capture(s) is not recommended, since this many files (several ten
thousand) will have a huge overhead on the file system (because of things like last modified
info, which isn’t applicable here anyways), resulting in a much larger file space consumption and
slower access times when trying to list the files in the explorer.
If you want to search multiple captures for specific files, use this script:
https://github.com/lcdr/utils/ find_packets.py
(The script also yields the binary content of the packets, which can be useful for further filtering
or logging)
If you want to look at the raw data of a packet yourself (not recommended for inexperienced
users) you can of course extract single files from the .zip archive using an archive extractor of
your choice (I recommend 7-Zip).
Then you can open the extracted *.bin file(s) using a hex editor of your choice (for some packet
types it might be useful to have an editor that can shift the bits in the data, no recommendation
here).
Alternatively a graphical viewer for capture files is available at https://github.com/lcdr/utils/
captureviewer.py (takes the entire .zip archive of a traffic as input, no need to extract anything)

Packet Documentation:
We can’t guarantee that all the packet structures listed here are correct, the only way to do that
would be to have access to the original source code that created them. In fact, there are a
number of packets and structures where we can only guess, or don’t know their purpose at all.
(Typically structures with an unknown purpose will be marked as “???”).

If you notice that information in these docs is incorrect, please edit it, and leave a comment with
your sources. We may not be able to confirm your edits right away, and they might stay marked
as suggestions for a while. This does not mean that we don’t approve of your edit, just that we
haven’t gotten around to confirming it yet. We appreciate every edit you submit, and we’re
always happy to improve the accuracy or the wording of this documentation. However to make
sure that the information stated here is actually correct we can’t merge edits immediately.

by lcdr and humanoid24 | licensed as CC BY-NC-SA 4.0

Contributions by Alanzote, Avery, jon002, Knightoffaith, pwjones, Raine, Simon Nitzsche, Xiphoseer and others
Contact us if we forgot to list your name
Contact
All strings that have a reserved space are null terminated, if the string doesn’t occupy the whole
space, the bytes after the null terminator can be random.
Variable strings are not null terminated but honor null termination if a null character is inserted.
If any single hex numbers are used they should be marked as such (preceding 0x), for
consecutive numbers that are taken directly from the data (like packet headers) this doesn’t
have to be the case.
All integers and floating point numbers are in little endian meaning that you have to read the
occupied space in reverse to get the number, if you think there are some numbers that are in big
endian, mark them as such.

Reference:
[xx-xx-xx-xx]: first 4 bytes of the header (this matches the decrypted packet file names in the
captures)
Artificial packet: Packet was not captured in traffic logs, but tests with the ID show that it is
recognized by the client.
Theoretical packet: Packet was not captured in traffic logs, but there is evidence in the client
executable that the packet has this purpose. For server packets, once tests with the ID show
that the client reacts to the packet, this should be changed to Artificial packet. For client
packets, once we manage to get the client to send a packet of this type, this should be changed
to normal packet.
u8: unsigned char (1 byte)
u16: unsigned short (2 bytes)
u32: unsigned long (4 bytes)
u64: unsigned long long (8 bytes)
s32: signed long (4 bytes)
s64: signed long long (8 bytes)
bool: boolean, can either be 1 or 0 (1 byte)
bit: “true” boolean, can either be 0 or 1, if there is a “flag” specifier then this defines whether a
part of a packet (all structures that are indented one additional level) is included or not (1 bit)
string: char sequence (x bytes, null terminated (zero at the end)), 33 bytes long
wstring: wide char sequence (2*x bytes, null terminated (double zero at the end)), 66 bytes
long
(there are variants of these string types that are variable-length, they should be explicitly stated
as variable length or somehow else be distinguished from the types above)
LDF: Lego data format, our unofficial name for the data format used in packets and
configuration files (so far in binary, xml and config variations), see Appendix for definition
LOT: ”Lego Object Template”?, determines the kind of object (whether it’s a player, an NPC, a
tree, etc) and which components the object has (4 bytes)
Object ID: ID to distinguish each object in the game (e.g. player characters) (8 bytes)
Network ID: Temporary ID added by Raknet’s ReplicaManager, this is handled automatically
and usually not important. Used to internally address objects for updates/destruction

???: this is unknown and should be investigated if possible

by lcdr and humanoid24 | licensed as CC BY-NC-SA 4.0

Contributions by Alanzote, Avery, jon002, Knightoffaith, pwjones, Raine, Simon Nitzsche, Xiphoseer and others
Contact us if we forgot to list your name
Contact
L:n.: length specifier for n amounts of bytes, usually only temporarily used in the documentation
to specify an unknown chunk of data (and replaced once the structure of that chunk is better
known), in some instances the amount V is used to specify a variable amount of bytes

Packet Header:
[u8] - RakNet packet ID, typically 0x53 for packets that are not being handled by RakNet (which
are practically all packets that will be listed here)
if packet id is 0x53:
[u16] - type of the remote connection, is exchanged in the first two packets of the real traffic,
should be one of these values: 0 (general), 1 (auth), 2 (chat), 4 (server), 5 (client)
[u32] - packet ID, to be able to identify what the packet contains (which will also be done in this
document), could be that the latter 2 bytes are another u16 struct but they have always been 0
so far
[u8] - ???, is always 0? could be padded data

Packet List:
Format:
[header] - according enum name taken from the client executable ( - more descriptive name)

Packet Colors:
green: is available in the captured traffics (or could be reproduced to be sent from the client)
yellow: is not available but self-created ones were effectively tested (Artificial packet)
red: is not available and no testing was done yet or it had no effect (Theoretical packet)
grey: has been proven to be unused in the client through reverse engineering

All Servers: (prefix = “MSG_SERVER_”)

53-00-00-00 - VERSION_CONFIRM - Handshake (both client and server)
53-00-00-01 - DISCONNECT_NOTIFY - Disconnect notify
53-00-00-02 - GENERAL_NOTIFY - General notify

Chat: (prefix = “MSG_CHAT_”)

53-02-00-00 - LOGIN_SESSION_NOTIFY
53-02-00-01 - GENERAL_CHAT_MESSAGE - Public chat message
53-02-00-02 - PRIVATE_CHAT_MESSAGE - Private chat message
53-02-00-03 - USER_CHANNEL_CHAT_MESSAGE
53-02-00-04 - WORLD_DISCONNECT_REQUEST
53-02-00-05 - WORLD_PROXIMITY_RESPONSE
53-02-00-06 - WORLD_PARCEL_RESPONSE
53-02-00-07 - ADD_FRIEND_REQUEST
53-02-00-08 - ADD_FRIEND_RESPONSE
53-02-00-09 - REMOVE_FRIEND
53-02-00-0a - GET_FRIENDS_LIST
53-02-00-0b - ADD_IGNORE
53-02-00-0c - REMOVE_IGNORE

by lcdr and humanoid24 | licensed as CC BY-NC-SA 4.0

Contributions by Alanzote, Avery, jon002, Knightoffaith, pwjones, Raine, Simon Nitzsche, Xiphoseer and others
Contact us if we forgot to list your name
Contact
53-02-00-0d - GET_IGNORE_LIST
53-02-00-0e - TEAM_MISSED_INVITE_CHECK
53-02-00-0f - TEAM_INVITE
53-02-00-10 - TEAM_INVITE_RESPONSE
53-02-00-11 - TEAM_KICK
53-02-00-12 - TEAM_LEAVE
53-02-00-13 - TEAM_SET_LOOT
53-02-00-14 - TEAM_SET_LEADER
53-02-00-15 - TEAM_GET_STATUS
53-02-00-16 - GUILD_CREATE
53-02-00-17 - GUILD_INVITE
53-02-00-18 - GUILD_INVITE_RESPONSE
53-02-00-19 - GUILD_LEAVE
53-02-00-1a - GUILD_KICK
53-02-00-1b - GUILD_GET_STATUS
53-02-00-1c - GUILD_GET_ALL
53-02-00-1d - SHOW_ALL
53-02-00-1e - BLUEPRINT_MODERATED
53-02-00-1f - BLUEPRINT_MODEL_READY
53-02-00-20 - PROPERTY_READY_FOR_APPROVAL
53-02-00-21 - PROPERTY_MODERATION_CHANGED
53-02-00-22 - PROPERTY_BUILDMODE_CHANGED
53-02-00-23 - PROPERTY_BUILDMODE_CHANGED_REPORT
53-02-00-24 - MAIL
53-02-00-25 - WORLD_INSTANCE_LOCATION_REQUEST
53-02-00-26 - REPUTATION_UPDATE
53-02-00-27 - SEND_CANNED_TEXT
53-02-00-28 - GMLEVEL_UPDATE
53-02-00-29 - CHARACTER_NAME_CHANGE_REQUEST
53-02-00-2a - CSR_REQUEST
53-02-00-2b - CSR_REPLY
53-02-00-2c - GM_KICK
53-02-00-2d - GM_ANNOUNCE
53-02-00-2e - GM_MUTE
53-02-00-2f - ACTIVITY_UPDATE
53-02-00-30 - WORLD_ROUTE_PACKET
53-02-00-31 - GET_ZONE_POPULATIONS
53-02-00-32 - REQUEST_MINIMUM_CHAT_MODE
53-02-00-33 - REQUEST_MINIMUM_CHAT_MODE_PRIVATE
53-02-00-34 - MATCH_REQUEST
53-02-00-35 - UGCMANIFEST_REPORT_MISSING_FILE
53-02-00-36 - UGCMANIFEST_REPORT_DONE_FILE
53-02-00-37 - UGCMANIFEST_REPORT_DONE_BLUEPRINT
53-02-00-38 - UGCC_REQUEST
53-02-00-39 - WHO

by lcdr and humanoid24 | licensed as CC BY-NC-SA 4.0

Contributions by Alanzote, Avery, jon002, Knightoffaith, pwjones, Raine, Simon Nitzsche, Xiphoseer and others
Contact us if we forgot to list your name
Contact
53-02-00-3a - WORLD_PLAYERS_PET_MODERATED_ACKNOWLEDGE
53-02-00-3b - ACHIEVEMENT_NOTIFY - Chat Achievement notify
53-02-00-3c - GM_CLOSE_PRIVATE_CHAT_WINDOW
53-02-00-3d - UNEXPECTED_DISCONNECT
53-02-00-3e - PLAYER_READY
53-02-00-3f - GET_DONATION_TOTAL
53-02-00-40 - UPDATE_DONATION
53-02-00-41 - PRG_CSR_COMMAND
53-02-00-42 - HEARTBEAT_REQUEST_FROM_WORLD
53-02-00-43 - UPDATE_FREE_TRIAL_STATUS

Client Auth: (prefix = “MSG_AUTH_”)

53-01-00-00 - LOGIN_REQUEST - Login info
53-01-00-01 - LOGOUT_REQUEST
53-01-00-02 - CREATE_NEW_ACCOUNT_REQUEST
53-01-00-03 - LEGOINTERFACE_AUTH_RESPONSE
53-01-00-04 - SESSIONKEY_RECEIVED_CONFIRM
53-01-00-05 - RUNTIME_CONFIG

Client World: (prefix = “MSG_WORLD_”)

id 00
53-04-00-01 - CLIENT_VALIDATION - Session info
53-04-00-02 - CLIENT_CHARACTER_LIST_REQUEST
53-04-00-03 - CLIENT_CHARACTER_CREATE_REQUEST
53-04-00-04 - CLIENT_LOGIN_REQUEST - Character selected
53-04-00-05 - CLIENT_GAME_MSG
53-04-00-06 - CLIENT_CHARACTER_DELETE_REQUEST
53-04-00-07 - CLIENT_CHARACTER_RENAME_REQUEST
53-04-00-08 - CLIENT_HAPPY_FLOWER_MODE_NOTIFY
53-04-00-09 - CLIENT_SLASH_RELOAD_MAP - Reload map cmd
53-04-00-0a - CLIENT_SLASH_PUSH_MAP_REQUEST - Push map req cmd
53-04-00-0b - CLIENT_SLASH_PUSH_MAP - Push map cmd
53-04-00-0c - CLIENT_SLASH_PULL_MAP - Pull map cmd
53-04-00-0d - CLIENT_LOCK_MAP_REQUEST
53-04-00-0e - CLIENT_GENERAL_CHAT_MESSAGE - General chat message
53-04-00-0f - CLIENT_HTTP_MONITOR_INFO_REQUEST
53-04-00-10 - CLIENT_SLASH_DEBUG_SCRIPTS - Debug scripts cmd
53-04-00-11 - CLIENT_MODELS_CLEAR
53-04-00-12 - CLIENT_EXHIBIT_INSERT_MODEL
53-04-00-13 - CLIENT_LEVEL_LOAD_COMPLETE - Character data request
53-04-00-14 - CLIENT_TMP_GUILD_CREATE
53-04-00-15 - CLIENT_ROUTE_PACKET - Social?
53-04-00-16 - CLIENT_POSITION_UPDATE - Position update
53-04-00-17 - CLIENT_MAIL
53-04-00-18 - CLIENT_WORD_CHECK - Whitelist word check

by lcdr and humanoid24 | licensed as CC BY-NC-SA 4.0

Contributions by Alanzote, Avery, jon002, Knightoffaith, pwjones, Raine, Simon Nitzsche, Xiphoseer and others
Contact us if we forgot to list your name
Contact
53-04-00-19 - CLIENT_STRING_CHECK - Whitelist string check
53-04-00-1a - CLIENT_GET_PLAYERS_IN_ZONE
53-04-00-1b - CLIENT_REQUEST_UGC_MANIFEST_INFO
53-04-00-1c - CLIENT_BLUEPRINT_GET_ALL_DATA_REQUEST
53-04-00-1d - CLIENT_CANCEL_MAP_QUEUE
53-04-00-1e - CLIENT_HANDLE_FUNNESS - Performance issue?
53-04-00-1f - CLIENT_FAKE_PRG_CSR_MESSAGE
53-04-00-20 - CLIENT_REQUEST_FREE_TRIAL_REFRESH
53-04-00-21 - CLIENT_GM_SET_FREE_TRIAL_STATUS
53-04-00-5b - Top 5 issues request
53-04-00-78 - UGC download failed

World Server: (prefix = “MSG_CLIENT_”)

53-05-00-00 - LOGIN_RESPONSE
53-05-00-01 - LOGOUT_RESPONSE
53-05-00-02 - LOAD_STATIC_ZONE - World info
53-05-00-03 - CREATE_OBJECT
53-05-00-04 - CREATE_CHARACTER - Character data
53-05-00-05 - CREATE_CHARACTER_EXTENDED
53-05-00-06 - CHARACTER_LIST_RESPONSE - Character list
53-05-00-07 - CHARACTER_CREATE_RESPONSE
53-05-00-08 - CHARACTER_RENAME_RESPONSE - Character rename
53-05-00-09 - CHAT_CONNECT_RESPONSE - Chat service response
53-05-00-0a - AUTH_ACCOUNT_CREATE_RESPONSE
53-05-00-0b - DELETE_CHARACTER_RESPONSE
53-05-00-0c - GAME_MSG - Server Update
53-05-00-0d - CONNECT_CHAT
53-05-00-0e - TRANSFER_TO_WORLD - Redirection
53-05-00-0f - IMPENDING_RELOAD_NOTIFY
53-05-00-10 - MAKE_GM_RESPONSE - GMlevel change
53-05-00-11 - HTTP_MONITOR_INFO_RESPONSE
53-05-00-12 - SLASH_PUSH_MAP_RESPONSE - Push map
53-05-00-13 - SLASH_PULL_MAP_RESPONSE - Pull map
53-05-00-14 - SLASH_LOCK_MAP_RESPONSE - Lock map
53-05-00-15 - BLUEPRINT_SAVE_RESPONSE
53-05-00-16 - BLUEPRINT_LUP_SAVE_RESPONSE
53-05-00-17 - BLUEPRINT_LOAD_RESPONSE_ITEMID
53-05-00-18 - BLUEPRINT_GET_ALL_DATA_RESPONSE
53-05-00-19 - MODEL_INSTANTIATE_RESPONSE
53-05-00-1a - DEBUG_OUTPUT
53-05-00-1b - ADD_FRIEND_REQUEST - Friend request
53-05-00-1c - ADD_FRIEND_RESPONSE - Friend request response
53-05-00-1d - REMOVE_FRIEND_RESPONSE Remove friend response
53-05-00-1e - GET_FRIENDS_LIST_RESPONSE - Friends list
53-05-00-1f - UPDATE_FRIEND_NOTIFY - Friend update

by lcdr and humanoid24 | licensed as CC BY-NC-SA 4.0

Contributions by Alanzote, Avery, jon002, Knightoffaith, pwjones, Raine, Simon Nitzsche, Xiphoseer and others
Contact us if we forgot to list your name
Contact
53-05-00-20 - ADD_IGNORE_RESPONSE - Add blocked
53-05-00-21 - REMOVE_IGNORE_RESPONSE - Remove blocked
53-05-00-22 - GET_IGNORE_LIST_RESPONSE - Blocked list
53-05-00-23 - TEAM_INVITE
53-05-00-24 - TEAM_INVITE_INITIAL_RESPONSE
53-05-00-25 - GUILD_CREATE_RESPONSE
53-05-00-26 - GUILD_GET_STATUS_RESPONSE - Guild get status
53-05-00-27 - GUILD_INVITE
53-05-00-28 - GUILD_INVITE_INITIAL_RESPONSE
53-05-00-29 - GUILD_INVITE_FINAL_RESPONSE
53-05-00-2a - GUILD_INVITE_CONFIRM
53-05-00-2b - GUILD_ADD_PLAYER
53-05-00-2c - GUILD_REMOVE_PLAYER
53-05-00-2d - GUILD_LOGIN_LOGOUT - Guild login/logout
53-05-00-2e - GUILD_RANK_CHANGE
53-05-00-2f - GUILD_DATA
53-05-00-30 - GUILD_STATUS
53-05-00-31 - MAIL
53-05-00-32 - DB_PROXY_RESULT
53-05-00-33 - SHOW_ALL_RESPONSE - Online player list
53-05-00-34 - WHO_RESPONSE - Player location response
53-05-00-35 - SEND_CANNED_TEXT - Chat message send failure response
53-05-00-36 - UPDATE_CHARACTER_NAME
53-05-00-37 - SET_NETWORK_SIMULATOR
53-05-00-38 - INVALID_CHAT_MESSAGE
53-05-00-39 - MINIMUM_CHAT_MODE_RESPONSE
53-05-00-3a - MINIMUM_CHAT_MODE_RESPONSE_PRIVATE
53-05-00-3b - CHAT_MODERATION_STRING
53-05-00-3c - UGC_MANIFEST_RESPONSE
53-05-00-3d - IN_LOGIN_QUEUE
53-05-00-3e - SERVER_STATES - Server states/status
53-05-00-3f - GM_CLOSE_TARGET_CHAT_WINDOW - GM quit private chat
53-05-00-40 - GENERAL_TEXT_FOR_LOCALIZATION
53-05-00-41 - UPDATE_FREE_TRIAL_STATUS

by lcdr and humanoid24 | licensed as CC BY-NC-SA 4.0

Contributions by Alanzote, Avery, jon002, Knightoffaith, pwjones, Raine, Simon Nitzsche, Xiphoseer and others
Contact us if we forgot to list your name
Contact
Chat packets:

Server-to-Client:

[53-02-00-01] (chat message)

[u64] - ???
[u8] - chat channel, always 0x04 for public-chat so far.
[u8] - this seems to be chat message length (including null terminator, so bytelength is this * 2) ,
but the chat message is a wstring, why would it need a length specifier? also it seems not to
have any effect if you change this (probably due to the way the client wstring parser works)
[L:3] - ???, still message length ?
[wstring] - Sender name, empty string is treated as System message
[u64] - Sender objectID
[u16] - ???
[bool] - is sender a mythran, if true, chat shows “Mythran” instead of real name
[wstring variable length] - Chat message

[53-02-00-02] (private chat message)

[u64] - ???, always 0?, skipped in code?
[u8] - chat channel
Values:
4 - public
5 - ???
6 - ???
8 - ???
9 - same as 8?
12 - ???
[u32] - this seems to be chat message length (including null terminator, so bytelength is this * 2)
, but the chat message is a wstring, why would it need a length specifier? also it seems not to
have any effect if you change this (probably due to the way the client wstring parser works)
[wstring] - Sender name
[s64] - Sender objectID
[u16] - ???
[bool] - is sender a mythran, if true, chat shows “Mythran” instead of real name
[wstring] - Recipient name
[bool] - is recipient a mythran, if true, chat shows “Mythran” instead of real name
[u8] - return code
values:
0 - Success
1 - Not online
2 - Error/Failure
3 - Occurred in packets but i have no idea what it does (seems like success), seems like
this always is in incoming packets (not sent from local char)
4 - Requires Friend

by lcdr and humanoid24 | licensed as CC BY-NC-SA 4.0

Contributions by Alanzote, Avery, jon002, Knightoffaith, pwjones, Raine, Simon Nitzsche, Xiphoseer and others
Contact us if we forgot to list your name
Contact
 5 - Sender is free trial
6 - Recipient is free trial
default: 2
[wstring variable length] - Chat message

[53-02-00-03] (unused)
Left in the game but has empty function body

[53-02-00-21] (???)
???

[53-02-00-3b] (something related to missions and chat?)

???

Client-to-Server:

[53-02-00-07] (add friend request)

[u64] - ???, always 0?
[wstring] - Name of person to be added as friend
[bool] - is request best friend request

[53-02-00-08] (add friend response)

[u64] - ???, always 0?
[u8] - return code, values:
0 -> Accepted
1 - > Declined
3 -> Invite window closed
[wstring] - Name of person to be added as friend

[53-02-00-09] (remove friend)

[u64] - ???, always 0?
[wstring] - name of friend to be removed

[53-02-00-0a] (get friends list)

[u64] - ???, always 0? (was always 0 in the captures)
respond to this with 53-05-00-1e Friends list

[53-02-00-0f] (team invite)

[u64] - ???, always 0?
[wstring] - Invited person's name

[53-02-00-10] (team invite response)

[u64] - ???, always 0?
[bool] - is invite denied
[s64] - Inviter's object ID

by lcdr and humanoid24 | licensed as CC BY-NC-SA 4.0

Contributions by Alanzote, Avery, jon002, Knightoffaith, pwjones, Raine, Simon Nitzsche, Xiphoseer and others
Contact us if we forgot to list your name
Contact
 by lcdr and humanoid24 | licensed as CC BY-NC-SA 4.0
Contributions by Alanzote, Avery, jon002, Knightoffaith, pwjones, Raine, Simon Nitzsche, Xiphoseer and others
Contact us if we forgot to list your name
Contact
Appendix A: LEGO data format and data type IDs

In a few places, like boot.cfg, client xml settings, inside .luz and .lvl files, and the chardata
packet, a custom name-value storage format is used. We’ve termed this “LEGO data format” or
LDF for short, although this is not the official name. The official name was likely
“LWONameValue” (but that’s hard to abbreviate).

There are two versions of this format, one is text-based, while the other is binary.

The binary data format is used in various packets, for example the chardata packet.
The structure is as follows:

[u32] - number of keys

[u8] - key length in bytes (Important: this is the length in bytes, not as usual in
characters, so you need to write 2 * number of characters)
[wchar] - key
[u8] - data type (see below)
[according to data type] - data

The text format is used in boot.cfg and in .luz & .lvl files.
The text format has the format:
key name=type:value

The used data type IDs are the same for both text and binary. These are the types we’ve been
able to match so far:

0 : String (variable wstring?)

1 : s32
2: same as type 1? (haven’t found an occurrence of this type so far)
3 : float
4: double
5 : u32
6: same as type 5? (haven’t found an occurrence of this type so far)
7 : Boolean (8bit, 0 or 1)
8 : s64
9 : s64, Used only for (object?) IDs?
10: ??? (haven’t found an occurrence of this type so far)
11: ??? (haven’t found an occurrence of this type so far)
12: ??? (haven’t found an occurrence of this type so far)
13 : likely used for bytestrings (in chardata this was XML data, in client settings checksum, in lvl
files strings/GUIDs)
14: ??? (haven’t found an occurrence of this type so far)

by lcdr and humanoid24 | licensed as CC BY-NC-SA 4.0

Contributions by Alanzote, Avery, jon002, Knightoffaith, pwjones, Raine, Simon Nitzsche, Xiphoseer and others
Contact us if we forgot to list your name
Contact