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


General data (split up in their indices):

Notes:

- grey colored structs didn’t occur in a packet yet (if you find one, report it)

- indented structures mean that they are included x times according to the last not indented struct (same applies if the last not indented struct is a bool, in that case, false -> 0 times included (not included), true -> 1 times included (included))

- “something?” structs mean there could be some data included at that point if a certain requirement is met but that was neither accessed nor visible at that point in the client code (it could also be that these parts were just client related in the code so they can be ignored until it turns out there is some missing data in such a section)

- the structures were obtained from the reverse engineered client code so their lengths should be correct (what’s unknown are the types since e.g int32 and float have the same bit length)

- for some reason, the data of some indices is not accessed in the code for some objects, therefore I was unable to investigate them (I also have no idea yet how the client knows which indices to read and which to skip)

- for investigations in captured replica packets, an advanced hex editor that can do bit operations on data is very much recommended since there tend to be a lot of bit shifts in one packet


Top Data: (seems to be included in every object)

[L:8] - objectID, s64

[L:4] - LOT, s32

[L:1] - wstring length (# of letters), u8

// following structure n times according to previous struct

[L:2] - name, wchar_t

[L:4] - ???

[L:BIT1] - flag for data, bool

[L:4] - size of following struct

[L:x] - compressed data, x bytes according to prev struct

contains LDF with the following keys and data formats:

blueprintid: 9

componentWhitelist: 1

modelBehaviors: 5

modelType: 1

propertyObjectID: 7

userModelID: 9

[L:BIT1] - ???

[L:BIT1] - flag for data, bool

[L:8] - SpawnerID (is the objectID of the spawner object?), s64

[L:BIT1] - flag for data, bool

[L:4] - ???

[L:BIT1] - flag for data, bool

[L:4] - ???

[L:BIT1] - flag for data, bool

[L:1] - ???

[L:BIT1] - flag for data, bool

[L:1] - ???

// following structures up to the next index are separated in the code from the above, are at a relative address and seem to be included from here in the serialization packets (todo: check more than one serialization packet for this and if relative address is always the same)

[L:BIT1] - flag for data, bool

[L:BIT1] - flag for data, bool

[L:8] - ???

[L:something?] - ???

[L:BIT1] - flag for data, bool

[L:2] - ??? (if > 0 read next block n times?)

[L:8] - ???

[L:something?] - ???



LOT = 1 (Generic Player, local):

// these index numbers are only valid for the object of the connecting player, not for this LOT in general, however the components (and their contents) should be the same


Index 0-19: missing, at least for the local player, identified by the objectID (thats right, it doesnt seem like the client reads index 0 despite the log msg)


Index 20: // component_type 1?

[L:BIT1] - flag for data, bool

[L:4] - ???

[L:BIT1] - ???

[L:BIT1] - ???

[L:BIT1] - flag for data, bool

7*[L:4] - ???

// there is a “jump if zero” from the start of the index to here before reading the above structs

// does this mean the above structures could be disabled as well (and if yes how)?

// this is actually the case for the first serialization packet, could this mean the above data is

// always skipped for serialization packets? (todo: check more than one packet)

[L:BIT1] - flag for data, bool

[L:4] - ???, could be a float

[L:4] - ???, could be a float

[L:BIT1] - flag for data, bool

[L:4] - ???

[L:something?] - ???

[L:BIT1] - ???

[L:BIT1] - flag for data, bool

[L:BIT1] - flag for data, bool

[L:4] - ???

[L:BIT1] - ???

[L:BIT1] - flag for data, bool

[L:4] - player pos x, float

[L:4] - player pos y, float

[L:4] - player pos z, float

[L:4] - player rotation x (or z), float

[L:4] - player rotation y, float

[L:4] - player rotation z (or x), float

[L:4] - player rotation w, float

[L:BIT1] - ???

[L:BIT1] - ???

[L:BIT1] - flag for data, bool

[L:4] - velocity x?, float

[L:4] - velocity y?, float

[L:4] - velocity z?, float

[L:BIT1] - flag for data, bool

[L:4] - acceleration x?, float

[L:4] - acceleration y?, float

[L:4] - acceleration z?, float

[L:BIT1] - flag for data, bool

[L:8] - ???

[L:4] - ???

[L:4] - ???

[L:4] - ???

[L:BIT1] - ???

[L:4] - ???

[L:4] - ???

[L:4] - ???

// it seems the following is serialization only?

[L:BIT1] - flag for data?

[L:something?] - ???


Index 21: missing // part of component_type 7?


Index 22: // part of component_type 7?

// there is a “jump if zero” from the start of the index to skip this index completely

// this is actually the case for the first serialization packet, could this mean this index

// always skipped for serialization packets? (todo: check more than one packet)

[L:BIT1] - flag for data, bool

[L:4] - count for following structs

[L:4] - ???

[L:BIT1] - flag for data, bool

[L:4] - ???

[L:BIT1] - ???

[L:BIT1] - ???

[L:BIT1] - ???

[L:BIT1] - ???

[L:BIT1] - ???

[L:BIT1] - ???

[L:BIT1] - ???

[L:BIT1] - ???

[L:BIT1] - ???, seems to toggle [L:8] below?

[L:BIT1] - ???

// next struct is included if a certain requirement is met?

[L:8] - ???

[L:4] - ???

[L:something?] - ???, strings like "BuffDefinitions", "Priority", "UIIcon", "LeftHand" and "BuffParameters" show up in subfunctions)

[L:BIT1] - flag for data, bool

[L:4] - count for following structs

[L:4] - ???

[L:BIT1] - flag for data, bool

[L:4] - ???

[L:BIT1] - ???

[L:BIT1] - ???

[L:BIT1] - ???

[L:BIT1] - ???

[L:BIT1] - ???

[L:BIT1] - ???

[L:BIT1] - ???

[L:BIT1] - ???

[L:BIT1] - ???, seems to toggle [L:8] below?

[L:BIT1] - ???

// next struct is included if a certain requirement is met?

[L:8] - ???

[L:4] - ???

[L:something?] - ???, strings like "BuffDefinitions", "Priority", "UIIcon", "LeftHand" and "BuffParameters" show up in subfunctions)


Index 23: // part of component_type 7?

[L:something?] - ???

[L:BIT1] - flag for data, bool

[L:4] - ???

[L:4] - ???

[L:4] - ???

[L:4] - ???

[L:4] - ???

[L:4] - ???

[L:4] - ???

[L:4] - ???

[L:4] - ???

// there is a “jump if zero” from the start of the index to here before reading the above structs

// does this mean the above structures could be disabled as well (and if yes how)?

// todo: check if this happens in serialization packets (if possible more than one)

[L:BIT1] - flag for data, bool

[L:4] - current health, u32 (why not float?)

[L:4] - ???, float (same number as max health but changing it had no effect)

[L:4] - current armor, u32 (why not float?)

[L:4] - ???, float (same number as max armor but changing it had no effect)

[L:4] - current imagination, u32 (untested since it first needs to be activated ingame)

[L:4] - ???, float (same number as max imagination but changing it had no effect)

[L:4] - ???

[L:BIT1] - ???

[L:BIT1] - ???

[L:BIT1] - ???

[L:4] - max health, float

[L:4] - max armor, float

[L:4] - max imagination, float

[L:4] - ??? (count for next struct?)

[L:4] - faction id of the player? (at least something with factions)

[L:something?] - ???

[L:something?] - ???

[L:BIT1] - flag for data?

[L:something?] - ???

// starting here is skipped in serialization

[L:BIT1] - flag for data?

[L:BIT1] - flag for data?

[L:something?] - ???

// another check for data to include here

[L:BIT1] - ???

[L:BIT1] - flag for data, bool

[L:4] - ???

// end of skip in serialization

[L:something?] - ???

[L:BIT1] - flag for data, bool

[L:BIT1] - ???

[L:something?] - ???


Index 24: // part of component_type 4?

[L:BIT1] - flag for data, bool

[L:BIT1] - flag for data, bool

[L:8] - ???

[L:1] - ???

[L:something?] - ???


Index 25-26: missing


Index 27: // part of component_type 4?

[L:BIT1] - flag for data, bool

[L:4] - level

[L:something?] - ???


Index 28: // part of component_type 4?

[L:BIT1] - flag for data, bool

[L:BIT1] - ???

[L:BIT1] - ???

[L:something?] - ???


Index 29: // part of component_type 4?

[L:BIT1] - flag for data, bool

[L:8] - ???, could be “co” from xml data

[L:BIT1] - flag for data, bool

[L:8] - ???

[L:BIT1] - flag for data, bool

[L:8] - ???

[L:BIT1] - flag for data, bool

[L:8] - ???

[L:4] - hair color (“hc” from xml data), u32

[L:4] - hair style (“hs” from xml data), u32

[L:4] - ???, could be “hd” or “hdc” from xml data, u32

[L:4] - shirt color (“t” from xml data), u32

[L:4] - pants color (“l” from xml data), u32

[L:4] - ???, could be “cd” from xml data, u32

[L:4] - ???, could be “hdc” or “hd” from xml data, u32

[L:4] - eyebrows style (“es” from xml data), u32

[L:4] - eyes style (“ess” from xml data), u32

[L:4] - mouth style (“ms” from xml data), u32

[L:8] - accountID (in xml data and chardata packet), u64

[L:8] - “llog” from xml data, u64

[L:8] - ???, could be a couple of things from the xml data (since its 0 in the packet), u64

[L:8] - lego score (from xml data), u64

[L:BIT1] - flag that sets free2play mode for player (1 means player is free2play)

The following 27 structs are stats table values (“stt” from xml data)

[L:8] - Total Amount of Currency Collected, u64

[L:8] - Number of Bricks Collected, u64

[L:8] - Number of smashables smashed, u64

[L:8] - Number of Quick Builds Completed, u64

[L:8] - Number of enemies smashed, u64

[L:8] - Number of Rockets used, u64

[L:8] - Number of missions completed, u64

[L:8] - Number of Pets tamed, u64

[L:8] - Number of Imagination power-ups collected, u64

[L:8] - Number of Life Power-Ups Collected, u64

[L:8] - Number of Armor power-ups collected, u64

[L:8] - Total Distance Traveled (in meters), u64

[L:8] - Number of times smashed, u64

[L:8] - Total damage taken, u64

[L:8] - Total damage Healed, u64

[L:8] - Total Armor Repaired, u64

[L:8] - Total Imagination Restored, u64

[L:8] - Total Imagination used, u64

[L:8] - Total Distance Driven (in meters), u64

[L:8] - Total Time Airborne in a Race Car (in seconds), u64

[L:8] - Number of Racing Imagination power-ups collected, u64

[L:8] - Number of Racing Imagination Crates Smashed, u64

[L:8] - Number of Times Race Car Boost Activated, u64

[L:8] - Number of Wrecks in a Race Car, u64

[L:8] - Number of Racing Smashables smashed, u64

[L:8] - Number of Races finished, u64

[L:8] - Number of 1st Place Race Finishes, u64

[L:BIT2] - ???, flag(s) for data?

// if previous struct == 1

[L:2] - count of characters

[L:2] - ???, seems to be a string in text lego data format, sample: “1:9746;1:9747;1:9748;”, wchar_t

// there is a “jump if zero” from the start of the index to here before reading the above structs

// does this mean the above structures could be disabled as well (and if yes how)?

// todo: check if this happens in serialization packets (if possible more than one)

[L:BIT1] - flag for data, bool

[L:BIT1] - flag for data?

[L:something?] - ???

[L:BIT1] - ???

[L:1] - ???

[L:BIT1] - ???

[L:1] - ???

[L:BIT1] - flag for data, bool

[L:4] - ???

[L:something?] - ???

[L:BIT1] - flag for data, bool (this and below was in a separate function in the code)

[L:8] - ???

[L:1] - ??? (count for next struct?)

[L:something?] - ??? (perhaps a string?)

[L:BIT1] - ???

[L:4] - ???


Index 30: // component_type 17?

[L:BIT1] - flag for data, bool

[L:4] - # of items the player has equipped, u32

// following structures n times according to previous struct

[L:8] - objectID of item, s64

[L:4] - LOT of item, s32

[L:BIT1] - flag for data, bool

[L:8] - ???

[L:BIT1] - flag for data, bool

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

[L:BIT1] - flag for data, bool

[L:2] - slot in inventory

[L:BIT1] - flag for data, bool

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

[L:something?] - ???

[L:BIT1] - flag for data, bool

[L:4] - size of following struct

[L:x] - compressed data, x bytes according to prev struct

contains LDF with the following keys and data formats:

_Metric_Currency_Delta_Int: 1

_Metric_Mail_ID_Int64: 8

_Metric_Mission_ID_Int: 1

_Metric_Souce_LOT_Int: 1

_Metric_Transaction_ID_Int64: 9

assemblyPartLOTs: 0

[L:BIT1] - ??? (perhaps a flag that specifies if the item gets loaded or if data needs to be retrieved from the cdclient database?)

[L:BIT1] - flag for data, bool

[L:4] - ??? (count for next struct?)

[L:something?] - ???, called multiple times if a requirement is met? the amount of bits being read here is really weird though, its starts with a 64bit struct, then goes on with a 96bit and a 128bit structure (+ some additional data?)


Index 31: // component_type 9?

// Seems to be related to BehaviorTemplate.

// there is a “jump if zero” from the start of the index to skip this index completely

// todo: check if this happens in serialization packets (if possible more than one)

[L:BIT1] - flag for data, bool

[L:4] - count for following structs

[L:4] - ???

[L:4] - ???

[L:4] - ???

[L:4] - ???

[L:4] - count for following structs

[L:4] - ???

[L:4] - ???, seems to be something in BehaviorTemplate?

[L:4] - ???

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

[L:8] - ???, always the objectID of the minifig so far?

[L:8] - ???, always the objectID of the minifig so far?

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

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

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

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

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


Index 32: // part of component_type 2?

// Seems to be related to BehaviorEffects.

// there is a “jump if zero” from the start of the index to skip this index completely

// also the code where the data below was protocolled from is at another relative address

// todo: check if this component gets skipped by the jump or if the relative address of the data remains the same in serialization packets (if possible more than one) or other creation packets

[L:4] - number of BehaviorEffects? (see BehaviorEffect table in cdclient)

[L:1] - string length (# of letters), u8

// following structure n times according to previous struct

[L:1] - effectID (string representation), char

[L:4] - effectID (numerical representation), u32

[L:1] - wstring length (# of letters), u8

// following structure n times according to previous struct

[L:2] - effectType, wchar_t

[L:4] - ???

[L:8] - ???

[L:something?] - ??? (if prev struct is > 0?)


Index 33,34: // part of component_type 2?


Index 35: missing

Index 36: // component_type 107??

[L:BIT1] - flag for data, bool

[L:8] - ???

Index 37: missing


LOT = 11212:

[A:0x14BIT4,L:8] - Spawner ID (s64)



LOT = 3315 (UGG - Property Plaque):


Index 0: // component_type 3?

[L:BIT1] - flag for data, bool

[L:4] - ???

// there is a “jump if zero” from the start of the index to here before reading the above structs

// does this mean the above structures could be disabled as well (and if yes how)?

// todo: check if this happens in serialization packets (if possible more than one)

[L:BIT1] - flag for data, bool

[L:4] - ???

[L:4] - ???

[L:4] - ???

[L:4] - ???

[L:4] - ???

[L:4] - ???

[L:something?] - ???

[L:BIT1] - flag for data, bool

[L:4] - ???

[L:BIT1] - flag for data, bool

[L:4] - object pos x, float

[L:4] - object pos y, float

[L:4] - object pos z, float

[L:4] - object rotation x (or z), float

[L:4] - object rotation y, float

[L:4] - object rotation z (or x), float

[L:4] - object rotation w, float


Index 1-3: missing // component_types 36, 45 and 113?


Index 4: see Index 32 of LOT 1 // part of component_type 2?

Index 5,6: // part of component_type 2?


LOT = 2365 (ZoneControl Object) / 13006 (Deep Freeze zone control object):


Index 0: // could be component_type 5, not sure though

// there is a “jump if zero” from the start of the index to skip this index completely

// todo: check if this happens in serialization packets (if possible more than one)

[L:BIT1] - flag for data, bool

[L:4] - size of following struct

[L:x] - compressed data, x bytes according to prev struct

[L:something?] - ???


Index 1:

[L:BIT1] - flag for data, bool

[L:something?] - ???

[L:4] - ??? (count for next structs?)

[L:8] - ???

[L:something?] - ???

[L:4] - ???

[L:something?] - ???


Index 2: missing



todo - figure out how the client knows which components the according LOT has and (fully) investigate the remaining components



[0x27] - Replica Manager Serialization

[A:0x01,L:2] - NetworkID (you can use this to identify which object it is by finding the creation packet and looking up the LOT)

[A:0x03,L:Rest] - object dependent (what components they have), the components are mostly fully included though only the relevant (updated?) data is enabled using the according flags/counts (for how long is it broadcasted?). also it seems some parts that are included in the creation packet are (always?) skipped in the replica packets (apparently the parts that I commented as skippable due to jmps)


todo: check if there are some packets that include some data that wasn’t included in the creation packet



[0x25] - Replica Manager Destruction

[A:0x01,L:2] - NetworkID, didn’t come across a packet that contained more data than this



Component Data:

component at address 2C470 is "invalid" (points to some short code that doesn’t seem to do anything relevant)


these components seem to match so far, at least there weren't any objects yet that showed different ((number) of addresses:

<components>

<row component_type="1"/>

00B9974A INT3: EAX = 845770 Entry point

<row component_type="2"/>

00B9974A INT3: EAX = 840310 Entry point

00B9974A INT3: EAX = 2C470 Entry point

00B9974A INT3: EAX = 2C470 Entry point

<row component_type="3"/>

00B9974A INT3: EAX = 7E4B00 Entry point

<row component_type="7"/>

00B9974A INT3: EAX = 2C470 Entry point

00B9974A INT3: EAX = 939820 Entry point

00B9974A INT3: EAX = 92BBD0 Entry point

<row component_type="9"/>

00B9974A INT3: EAX = 806270 Entry point

<row omponent_type="11"/>

00B9974A INT3: EAX = 81B2D0 Entry point

<row component_type="17"/>

00B9974A INT3: EAX = 952860 Entry point

<row component_type="40"/>

00B9974A INT3: EAX = 834DB0 Entry point

<row component_type="108"/>

00B9974A INT3: EAX = 7DC1F0 Entry point

</components>


these components could be correct? cant say for sure:

<components_unsure>

<row component_type="35"/>

<row component_type="36"/>

<row component_type="45"/>

<row component_type="65"/>

<row component_type="113"/>

00B9974A INT3: EAX = 2C470 Entry point

<row component_type="5"/>

00B9974A INT3: EAX = 87CDF0 Entry point

<row component_type="107"/>

00B9974A INT3: EAX = 7D6690 Entry point

</components_unsure>