Understanding packet structure
 

Okay I thought I had this, but maybe I do not.

I am guessing this is the packet that got sent from me sellling a single malachite to a vendor using Underfoot

This is 16 bytes if I am right, and have the right packet.

So this would be the structure correct ? It is me selling to the vendor a malachite. The sell struct seems to be larger so it does not looking like a likely candidate.

So this would be the struct.

I can make out the slot and the amount, which was one malachite. But the NPCid does not match me or the vendor, no matter if I read it from right to left or left to right, converted it to decimal. I am thinking I am missing something simple here.

I posted this in a separate thread because this has nothing to really do with the VoA development.

That packet has the following values:
I'd need to see the OP_ZoneEntry packet for the merchant to tell if the NPCID was correct or not.

I see the 01 93 in the packet when he was picked up during zone in. I am guessing this in no way reflects his ID of 202081 - Merabo_Sotath (Brewing Supplies)

Yes, that is correct.

I see the 01 93 in the packet when he was picked up during zone in. I am guessing this in no way reflects his ID of 202081 - Merabo_Sotath (Brewing Supplies). Sorry I am trying to wrap my head around all of this.

I forgot to tell provocating take your current voa.conf rename it to patch_Mar15-2012.conf then put with eqextractor2 directory replace the older file with current opcodes

202081 is just his id in the PEQ npc_types table, which is never sent to the client and has no meaning to it.

0x0193 is the entity_id.

Entity_ids are assigned sequentially, starting from 1, to each NPC that is spawned in a zone, so the first NPC to be spawned gets EntityID 1, the next one gets 2, etc, etc. These are what are sent in the OP_ZoneEntry and various other packets and are what tie things together in the packets.

The EntityID an NPC get assigned could change depending on the order things get spawned, so you need to look at the OP_ZoneEntry packet in the particular collect your are looking at to see what it has been assgined.

The EntityID of an NPC is the 32 bit value following the null terminated name string at the start of the OP_ZoneEntry packet.

I have the Extractor files from just recently, and they do seem to be able to parse the VoA client, are you saying I still need to do this ?

that is what i have been doing just replacing patch_Mar15-2012.conf file with newer opcode so it will show up correctly.

I actually just copied the voa.conf into the directory without replacing anything, it appears to work fine like that ?

EQExtractor2 is looking for a file called patch_Mar15-2012.conf in it's working directory to decode packets collected from the current Live client.

What Noport is saying is that as Trevius updates the patch_VoA.conf in the utils directory with newly found OpCodes, if you want EQExtractor2 to show these OpCodes with their correct name, rather than OP_Unknown, you should copy patch_VoA.conf to the location of your EQExtractor2.exe and rename it to patch_Mar15-2012.conf

I figured it just parsed the directory for *.conf files and used them. This is good to know !

In fact a packet that was not getting parsed right, now appears to be. Thanks !

copy voa.conf to desktop rename patch_Mar15-2012.conf replace older patch_Mar15-2012.conf.. in the program extractor2 you should see patch_mar15 in green correct? if you see voa.conf in green then you ok. i'll let Derision exlpain it to you. i want you to be using current opcode not the older opcode.

Well it is definitely a learning curve. I noticed that selling is not working, which Trevius is probably already working on. Selling the exact same item to the exact same vendor yeilds different results.

UNDERFOOT

VOA

One more byte to the packet and obviously some info padded in there.

That's likely due to the merchant window revamp. In fact since you're referring to SELLING an item my guess would be that extra information is to handle the new "buy back" tab. Where apparently items you sell default to if the merchant's inventory is full. So you can buy back items sold by mistake.

More than likely above my pay grade right now. I have to crawl before I can walk.

Yeah I know those feels. I'm right there with you. Trying to see if I can get off the ground with this stuff. I've made it my new goal to get that Extended Target window working and I'm determined >.<

At least thanks to Derision I can freaking open it now...lol

Well I have a second server vm setup as a test ground, it is a start.

I'm sorry provocating for leaving out detailed information i wasn't trying to mislead you in no way i wanted you to understand about updating and using the current opcode it was a learning experience for me too.

Do not apologize for something like that.

I am just glad we are all working toward a common goal. Like I said, I am learning so I have no idea how much I will be able to help. With my current project at work my brain is mush when I get home. Weekends are going to be the only time I get a substantial amount of hours to devote to this. Maybe when my project is done I will not be as exhausted when I get home.

Live did some major changes to how item slots are handled. Part of the problem is that it doesn't seem to be used exactly the same way in all cases. So, for stuff like selling and I am sure plenty of other spots, we will need to figure out exactly how they number slots and such. For stuff like item moves, it is 12 bytes used for identifying slots. For inventory/items, I think it is 5 bytes. For selling items, it looks like 8 bytes.


Also, a very useful tool for figuring out struct info is HexVis, which you can find here:

http://www.eqemulator.net/wiki/wikka.php?wakka=HexVis