This file will contain new/changed packet details that have been found in UOKR.

========================
0xFF  (client -> server)
LOGIN REQUEST
========================

byte[4]                 login request

-> This is sent immediately after the client connects to the game server.
-> Always contains 0xffffffff



========================
0xE0  (client -> server)
BUG REPORT
========================

byte[1]                 packet cmd
byte[2]                 packet len
byte[4]                 language
byte[2]                 bug type
byte[packet len - 9]    report body     (unicode text)

-> Sent from the client when player fills in a bug report on the ESC menu.
-> Language is 3 character (null terminated) ascii string as found in chat packets.
-> Types:
        0x01    -       World Environment
        0x02    -       Wearables
        0x03    -       Combat
        0x04    -       UI
        0x05    -       Crash
        0x06    -       Stuck
        0x07    -       Animations
        0x08    -       Performance
        0x09    -       NPCs
        0x0A    -       Creatures
        0x0B    -       Pets
        0x0C    -       Housing
        0x0D    -       Lost Item
        0x0E    -       Exploit
        0x0F    -       Other


========================
0xE1  (client -> server)
UNKNOWN
========================

byte[1]                 packet cmd      (0xe1)
byte[unk]

-> Sometimes sent by the client on the character selection screen, but have not
   reproduced it with packet logging enabled.
-> Seemed to be related to the max char count somehow (lack of reply grays out the
   create button).


========================
0xE3  (server -> client)
ENCRYPTION SET
========================

byte[1]                 packet cmd      (0xe3)
byte[2]                 packet length
byte[4]                 length unkA     (0x00000003)
byte[length unkA]       unkA            (0x020103)
byte[4]                 length unkB     (0x00000013)
byte[length unkB]       unkB
byte[4]                 length unkC     (0x00000010)
byte[length unkC]       unkC
byte[4]                 unkD            (0x00000020)
byte[4]                 length iv       (0x00000010)
byte[length unkE]       iv

-> This is sent by the server after the login request, and may contain some kind of
   data related to the encryption (ie. encryption keys).
-> Length is always 0x4D or the client will crash.
-> unkA[0] must be 0x02 or the client will crash.
-> Setting unkA[1] to 0x00 will cause the client to send 0s in the 0xE4 response
   (see below).
-> Setting too many 0s in the unkX can cause the client to fail connection.
-> unkB always begins with 0x021100. unkB may break down further.


========================
0xE4  (client -> server)
ENCRYPTION REPLY
========================

byte[1]                 packet cmd      (0xe4)
byte[2]                 packet length   (0x17)
byte[4]                 length unkA     (0x00000010)
byte[length unkA]       unkA

-> This is a reply to the 0xE3 packet and possibly contains the 3rd key to use with
   encryption.
-> The response is almost always different, regardless of the contents of the 0xE3
   packet.
-> In 0xE3, if unkA[1]=0x00, then unkA in this packet will always be filled with 0s,
   but this does not appear to remove encryption.


========================
0xEC  (client -> server)
Equip Item Macro
========================

byte[1]                 packet cmd
byte[2]                 packet length
byte[1]                 item count
byte[length-4]          item serials

-> Sent when an equip item macro is played.
-> Item serials is simply a list of item UIDs that the client wants to equip.


========================
0xED  (client -> server)
Unequip Item Macro
========================

byte[1]                 packet cmd
byte[2]                 packet length
byte[1]                 layer count
byte[length-4]          layers

-> Sent when an unequip item macro is played.
-> layers is a list of layers that the client wants to unequip.


========================
0x8D  (client -> server)
CHAR CREATION
========================

byte[1]                 packet cmd
byte[2]                 packet length
byte[4]                 pattern 1
byte[4]                 pattern 2
byte[30]                character name
byte[30]                "Unknown"
byte[1]                 profession
byte[1]                 unkA
byte[1]                 gender
byte[1]                 race
byte[1]                 strength
byte[1]                 dexterity
byte[1]                 intelligence
byte[2]                 skin hue
byte[8]                 unkB
byte[1]                 skill 1 id
byte[1]                 skill 1 value
byte[1]                 skill 2 id
byte[1]                 skill 2 value
byte[1]                 skill 4 id
byte[1]                 skill 4 value
byte[1]                 skill 3 id
byte[1]                 skill 3 value
byte[26]                unkC
byte[2]                 hair hue
byte[2]                 hair id
byte[11]                unkD
byte[2]                 skin hue
byte[1]                 unkE
byte[1]                 portrait
byte[1]                 unkF
byte[2]                 beard hue
byte[2]                 beard id

-> "Unknown" actually contains the string "Unknown".
-> Profession is the ID of the selected profession, or 0 for custom.
-> Gender values are 0=male, 1=female.
-> Race values are 0=human, 1=elf.
-> UOKR clients can choose 4 starting skills. Skills 4 and 3 are sent in reverse
   for some reason.
-> The skill ids and values should only be used when profession is custom (0). If
   a profession is selected then the skills will contain 'junk'.
-> Skin hue is repeated twice for some reason.
-> Portrait may be a byte[2].


========================
0x29  (server -> client)
Confirm drop on ground/on container
========================

byte[1]                 packet cmd      (0x29)

-> To send after 0x25 and 0x1A

========================
0xA9  (server -> client)
Char List
========================

-> The flags have been updated. We have now also 0x200 and 0x400 (unknown effects)

========================
0xDE  (server -> client)
Unknown purpose
========================

byte[1]                 packet cmd      (0xDE)
byte[2]                 packet length
byte[4]                 char serial
byte[1]			unk1		(0x00)

--> Seen on OSI (unknown purpose)

========================
0xDD  (server -> client)
Compressed Gump
========================

-> The packet has now an indirect effect, GumpID is read and used to find an xml
   in Interface.uop that contains the kr-compatible layout, then the dynamic parts
   are extracted to complete the layout. Additional LUA scripts are used to define
   a client-side behaviour.
   If the GumpID is not found a bug report windows is shown.

========================
0xBF sub 0x14  (server -> client)
KR Context Menu Display
========================

byte[2]                 unk1  	        (always 0x0002)
byte[4]                 char serial
byte[1]                 entry count
     - foreach entry
       byte[4]          cliloc id (LocalizedStrings.uop)
       byte[2]		entry id
       byte[2]		flags


--> Seen on OSI (unknown purpose)


========================
0x08  (client -> server)
ITEM DROP REQUEST
========================

byte[1]                 packet cmd
byte[4]                 item serial
byte[2]                 position X
byte[2]                 position Y
byte[1]                 position Z
byte[1]                 grid number
byte[4]                 container serial

--> Same as old 0x08, except for the inserted 'grid number' byte, which represents
    the grid that the item is being dropped into.


========================
0x25  (server -> client)
CONTAINER ADD ITEM
========================

byte[1]                 packet cmd
byte[4]                 item serial
byte[2]                 item art id
byte[1]                 unknown
byte[2]                 item amount
byte[2]                 position X
byte[2]                 position Y
byte[1]                 grid number
byte[4]                 container serial
byte[2]                 item hue

--> Same as old 0x25, except for the inserted 'grid number' byte, which represents
    the grid where the item is located.


========================
0x3C  (server -> client)
CONTAINER CONTENTS
========================

byte[1]                 packet cmd
byte[2]                 packet length
byte[2]                 item count
     - foreach item
       byte[4]          item serial
       byte[2]          item art id
       byte[1]          unknown
       byte[2]          item amount
       byte[2]          position X
       byte[2]          position Y
       byte[1]          grid number
       byte[4]          container serial
       byte[2]          item hue

--> Same as old 0x3c, except for the inserted 'grid number' byte, which represents
    the grid where the item is located.


========================
0xF0  (client -> server)
MOVEMENT REQUEST
========================

byte[1]                 packet cmd
byte[2]                 packet length
byte[1]                 unk1
byte[4]                 unk2 (0x00000122)
byte[4]                 unk3
byte[4]                 unk4 (0x00000122)
byte[4]                 unk5
byte[1]                 move counter
byte[1]                 new direction
byte[4]                 movement mode (1=walk, 2=run)
byte[4]                 new x position
byte[4]                 new y position
byte[4]                 new z position

--> Activated by [as of yet undetermined] feature flag.


========================
0xF1  (client -> server)
MOVEMENT SYNC (maybe)
========================

byte[1]                 packet cmd
byte[4]                 unk1 (0x00000122)
byte[4]                 unk2

--> Activated by [as of yet undetermined] feature flag.
--> Client automatically sends once per minute.


========================
0xF2  (server -> client)
MOVEMENT SYNC (maybe)
========================

byte[1]                 packet cmd
byte[4]                 unk1 (always 0x00000116)
byte[2]                 unkA
byte[2]                 unkB
byte[4]                 unk2 (always 0x00000116)
byte[2]                 unkA
byte[2]                 unkC
byte[4]                 unk3 (always 0x00000116)
byte[2]                 unkA
byte[2]                 unkC

--> Client always responds with 0xF1 packet (data doesn't appear to relate)


========================
0xF4  (client -> server)
CRASH REPORT
========================

byte[1]                 packet cmd
byte[2]                 packet length
byte[1]                 file version (major)
byte[1]                 file version (minor)
byte[1]                 file version (revision)
byte[1]                 file version (patch)
byte[2]                 position x
byte[2]                 position y
byte[1]                 position z
byte[1]                 position map
byte[32]                account name
byte[32]                character name
byte[4]                 error code
byte[100]               executable name
byte[100]               error description
byte[10]                unknown [00 6D 34 28 E1 01 00 58 9F 14]

--> Client sends this as they crash


========================
0x17  (server -> client)
HEALTH BAR UPDATE
========================

byte[1]                 packet cmd
byte[2]                 packet length
byte[4]                 character serial
byte[2]                 color count
     - foreach color
       byte[2]          color (1=green, 2=yellow)
       byte[1]          color state (0=off, 1=on)
