Item Info Packet

07/19/2011 16:12 Cyanogen#1
Hi

I'm having problems finding all the item attributes in the item info packet. So far this is what I've managed to find.
Code:
class ItemInfoPacket : public Packet
{
	public:
	ItemInfoPacket()
	{
		Define(PKT_LENGTH,INT_16);
		Define(PKT_TYPE,INT_16);
		Define(PKT_ID,INT_32);
		Define(PKT_TYPEID,INT_32);
		Define(PKT_DURA,INT_16);
		Define(PKT_MAXDURA,INT_16);
		Define(PKT_SOURCE,INT_16);
		Define(PKT_SLOT,INT_8);
		Define(PKT_UNKNOWN1,5);
		Define(PKT_SOC1,INT_8);
		Define(PKT_SOC2,INT_8);
		Define(PKT_UNKNOWN2,7);
		Define(PKT_COMP,INT_8);
		Define(PKT_BLESS,INT_8);
		Define(PKT_BOUND,INT_8);
		Define(PKT_ENCHANT,INT_8);
		Define(PKT_UNKNOWN3,7);
		Define(PKT_SUSPECT,INT_16);
		Define(PKT_LOCKED,INT_16);
		Define(PKT_COLOR,INT_16);
		Define(PKT_UNKNOWN4,INT_16);
		Define(PKT_CPROGRESS,INT_32);
		Define(PKT_INSCRIBE_GID,INT_32);
		Define(PKT_TIMELEFT,INT_32);
		Define(PKT_AMOUNT,INT_32);
		Define(PKT_TAG,8);
		SetInt(PKT_TYPE,0x3f0);
	}
};
I am assuming the unknown areas are to do with the temporary attributes from refinery packs etc.. But no matter what I do, when I spoof the packets, I cannot make anything appear on the item when I change them. Any information would be greatly appreciated.

Cheers
Cy'
07/19/2011 16:23 Korvacs#2
Alot of the unknown fields just arnt used, possibly due to old fields being replaced by new ones or just TQ's bad networking design.
07/19/2011 16:38 Cyanogen#3
I figured there would be a few unused ones, there seems to be a lot of unneeded padding in a lot of packets. Also, I know your packet wiki is a little out of date, but it's been an enormous help to me recently, none the less. +1
07/19/2011 16:43 Lateralus#4
word @ offset 0x00. (size)
word @ offset 0x02. (type)
dword @ offset 0x04.
dword @ offset 0x08.
word @ offset 0x0C.
word @ offset 0x0E.
byte @ offset 0x10.
byte @ offset 0x11.
byte @ offset 0x12.
dword @ offset 0x14.
byte @ offset 0x18.
byte @ offset 0x19.
dword @ offset 0x1C.
byte @ offset 0x20.
byte @ offset 0x21.
byte @ offset 0x22.
byte @ offset 0x23.
byte @ offset 0x24.
dword @ offset 0x28.
word @ offset 0x2C.
word @ offset 0x2E.
word @ offset 0x30.
dword @ offset 0x34.
dword @ offset 0x38.
dword @ offset 0x3C.
word @ offset 0x40.

This is every field processed by the client. Got this information with a debugger.
07/19/2011 16:53 Korvacs#5
Im sure almost every field is processed, but alot of the data just isnt used.
07/19/2011 17:02 Lateralus#6
Quote:
Originally Posted by Korvacs View Post
Im sure almost every field is processed, but alot of the data just isnt used.
No, seriously. Take a look in the client yourself. No other fields are processed.
07/19/2011 17:07 Cyanogen#7
I'm pretty sure there is a dword in there that determine the steed type, and another dword that deals with steed breeding. (the three color bars in the game) "Genes" for want of a better word. I don't have a steed in CO yet so I can't test that.
07/19/2011 17:10 Korvacs#8
Quote:
Originally Posted by Lateralus View Post
No, seriously. Take a look in the client yourself. No other fields are processed.
Sorry, miss understood your post, i thought you were implying that there was more than had been listed earlier :p
07/19/2011 17:10 Lateralus#9
Look at the routine starting at address 0x76322A. Maybe I missed something, but I'm pretty sure I got it all. :D
07/19/2011 18:16 IAmHawtness#10
Quote:
Originally Posted by Cyanogen View Post
I'm pretty sure there is a dword in there that determine the steed type, and another dword that deals with steed breeding. (the three color bars in the game) "Genes" for want of a better word. I don't have a steed in CO yet so I can't test that.
The steed type is determined by the three colors only
07/19/2011 18:24 phize#11
Why don't you create a more generic method to build packets? That just looks tedious imo.
07/19/2011 18:34 Cyanogen#12
I needed something to deal with the occasional repeated blocks such as in Chat packets. The tedium only really occurs when defining the packet itself, when in use, it simplifies the process enormously as it allows me to just take a block of raw data and dump it into the class which then extracts it into the correct elements for me. I could use structs to do this on most packets but variable length packets and repeated parameters are an issue with that.
07/19/2011 19:15 phize#13
Ah I see, makes more sense then. I'd still say to get rid of them nasty defines though, you're coding C++, not C for gods sake - use consts :p
07/19/2011 20:54 Cyanogen#14
Old C habits die hard. :)
07/21/2011 20:47 pro4never#15
Quote:
Originally Posted by Cyanogen View Post
I'm pretty sure there is a dword in there that determine the steed type, and another dword that deals with steed breeding. (the three color bars in the game) "Genes" for want of a better word. I don't have a steed in CO yet so I can't test that.
Quote:
Originally Posted by IAmHawtness View Post
The steed type is determined by the three colors only
These colors are combined into 1 uint which doubles as 'socket progress' for talis