PackedGUID

[/dev/not/null]

What data should be passed as packedGUID ?

[/dev/not/null]

I found this 

But not sure if I understand what does bit-mask for packed guid means. Any suggestions ?

 

[Olion]

You could find the method converting 64-bit (GUID) data to a packed GUID here. BTW, 1.12 client does not use this, which was/is a usual compatibility issue while backporting handlers to it.

A brief explanation. A GUID is 8-byte long; consider is as a byte array A where A[0] is the lowest GUID byte, ..., A[7] is the highest one. Create a side byte (the bitmask) this way: if

A[i]

is nonzero then i-th bit is 1, else the bit is 0. Then we can omit zero-valued elements of A from transfer (a packet), and transfer the bitmask following non-zero elements of A only. In the worst case (like items on a long-living realm) we get the 0xFF bitmask and will transfer 9 bytes instead of 8 (non-packed GUID). However in the best case (player GUID under 256), we get bitmask 0x01 and transfer only 2 bytes instead of 8. A packed GUID emerges by the protocol in packets that may contain a player GUID, saving bandwidth for several (zero-valued) bytes.

[/dev/not/null]

29 minutes ago, Olion said:

You could find the method converting 64-bit (GUID) data to a packed GUID here. BTW, 1.12 client does not use this, which was/is a usual compatibility issue while backporting handlers to it.

A brief explanation. A GUID is 8-byte long; consider is as a byte array A where A[0] is the lowest GUID byte, ..., A[7] is the highest one. Create a side byte (the bitmask) this way: if

A[i]

is nonzero then i-th bit is 1, else the bit is 0. Then we can omit zero-valued elements of A from transfer (a packet), and transfer the bitmask following non-zero elements of A only. In the worst case (like items on a long-living realm) we get the 0xFF bitmask and will transfer 9 bytes instead of 8 (non-packed GUID). However in the best case (player GUID under 256), we get bitmask 0x01 and transfer only 2 bytes instead of 8. A packed GUID emerges by the protocol in packets that may contain a player GUID, saving bandwidth for several (zero-valued) bytes.

Thanks for your answer. As I can see from World.log, when using packedGUID, the packet structure of SMSG_OBJECT_UPDATE (for 2.4.3) header should be next:

uint32 count 	# total number of update blocks
uint8  hasTransport
uint8  updateType
uint8  packedGUIDMask # for example, 0xFF
uint64 packedGUID

Am I right ?

[Olion]

I do not check top of the header (it can be done using the sources), but should note that a packed GUID has variative length. In your post, the whole structure

uint8  packedGUIDMask # for example, 0xFF
uint64 packedGUID

is termed as "packed GUID". It contains a number of bytes (1 to 8) for uint64. The number is equal to the number of non-zero bits in the bitmask packedGUIDMask, thus the length of the filed is well defined.