Hmm there is something weird going on with this.
Just tested it on my KT client.
The numbers coming back have absolutely no relationship to the actual item id at all.
What seems to be happening is that the client has assigned an arbitrary value to every item and skill that you own and when you drag an item or skill into the quick bar it is that unique ID number that is sent.
The server doesn't use these numbers for any reason whatsoever. It simply echoes it back to the client.
I gave my character 3 wooden swords then put them into positions 24, 25 and 26 on my hot bar (the 4th bar)
the packets I got back for each one were...
07aa: 18 81 04
07aa: 19 21 04
07aa: 1a a1 01
Lava Burst skill into slot 0b (11) gave this
07aa: 0b a3 05
(Lava Burst skill is 1176 in the STB)
All 3 were identical wooden swords. item 8001 in conventional numbering.
As you can see, these numbers bear no resemblance to that at all.
I even tried putting the swords in different inventory slots first but they always come back with the same id numbers no matter where they were in inventory.
Conclusion: The numbers returned here have zero relevance to the server and zero meaning other than being an index number used by the client.
Looked in the client code and found this after a bit of digging. m_wHotICON is the value that we receive as a WORD in the packet eventually.
It seems that it might actually contain a type and a slot number but in a very weird way. Split into 5 bytes and 11 bytes.
-
- union tagHotICON {
- struct {
- unsigned short m_cType : 5; // 0~31
- unsigned short m_nSlotNo : 11; // 0~2047
- } ;
- WORD m_wHotICON;
- } ;
let's try breaking up my packets in this way to see if they make any sense
07aa: 18 81 04
0x0481 = 1000000100000001 in binary.
first 5 bytes are 10000 which is 16 in decimal
next 11 bytes are 00100000001 which is 257 in decimal
07aa: 19 21 04
0x0421 = 0010000100000001 in binary
first 5 bytes are 00100 which is 4 in decimal
next 11 bytes are 00100000001 which is 257 in decimal
07aa: 1a a1 01
0x011a = 1010000100000001 in binary
first 5 bytes are 10100 which is 20 in decimal
next 11 bytes are 00100000001 which is 257 in decimal
(NOTE: All 3 were placed into different slots in the hotbar)
A bit of further digging in the client code came up with this
- hotICON.m_cType = INV_ICON;
- hotICON.m_nSlotNo = pItemIcon->GetIndex();
-
- if( hotICON.m_nSlotNo < INVENTORY_ITEM_INDEX_0 || hotICON.m_nSlotNo > INVENTORY_ITEM_INDEX_LAST )
- {
- assert( 0 && "Invalid Inventory Index @CTCmdDragInven2QuickBar::Exec" );
- return true;
- }
so it would appear that m_cType is the ICON number and m_nSlotNo is some kind of index number.
I've been unable to trace this index number back to where it originates so far. Tracing stuff in this code is a little like diving into Alice's magic rabbit hole. It just leads into a series of nested function calls that appear to go around in circles without ever reaching the bottom.
Either way, there isn't a damn thing we can do about it unfortunately other than rewrite the client.