EQExtractor2

[Derision]

Originally Posted by steve

Are you guys camping out to character select after getting to each zone? Just wanted to make sure I wasn't doing something unneeded. And will multiboxing confuse the capture?

Multiboxing can confuse the extractor and appears to be the cause of blackdragonsdg's crash.

What happens is the extractor reads each packet in the .pcap file looking for an SOE 'Session Request' packet (that the client send to the server).
When it sees a session request, it 'tentatively locks on' to that session and waits until it sees a particular packet (which was OP_NewZone and is
the packet in which the server sends various details about the zone) before deciding this is a valid EQ connection and permanently locking onto
this stream and ignoring all others.

What can happen, is if you zone in a second character before the server has sent the OP_NewZone to the first one, the extractor get's confused
by the crossed streams (oblig. Ghostbusters reference).

I've altered the extractor locally to 'permalock' to a stream when it sees an OP_ZoneEntry packet from the client to the server. This is the second
packet sent and so it is much less likely that multi-boxing will cause an issue, although of course, only the packets to/from the first client to
zone-in will be processed, but that shouldn't be an issue.

I'll push this version out later today when I've looked at another issue.

EDIT: Oh, and you don't need to camp out when you have finished. Just stop the capture and save it.

[steve]

Originally Posted by Derision

Oh, and you don't need to camp out when you have finished. Just stop the capture and save it.

Gotcha. But if I want to start a new one, simply zoning isn't enough, correct? I need to start from the character select each and every time for a new capture?

[Derision]

I've not tested it (I will later), but in theory, if you start a new capture while you are already in a zone, the next time you zone, the extractor should recognise the new zone and generate the SQL for that one.

[trevius]

Another option may be to start the capture before you zone, and as you zone, watch the capture and find a packet you are sure is the new zone communicating with your client and then right click that packet and select Conversation Filter > UDP. That will cause it to filter out everything accept for that zone's communication to you. You can normally tell fairly easily which packets are the zone communicating to you when you zone by watching for a ton of packets coming in at the same time from the same IP to you. Also, it is good to note that if you scroll up a bit while collecting, it will remain at that part of the collect, so you can select your packet to filter easier. You can scroll back to the bottom after if you wish to continue watching them come in real time again.

Then, when you stop the capture and save it, be SURE that you select the option for "Displayed" in the "Packet Range" section of the Save As window. That will cause it to save only the packets you filtered to see. Otherwise, if you don't save it with that option, it still saves the unfiltered collect.

By doing this, it should mean you can start a collect, then zone, then collect and save it. Then start another collect and zone again and so on.

I haven't really tested this yet, but I am pretty sure it would work fine.

[Derision]

1.8 is available

Permalocked onto stream using C->S OP_ZoneEntry to reduce chance of multi-boxing messing the collect up.
Version clause is appended to query when updating existing npc_types.
Selecting the update existing npc types option will automatically uncheck all other options.
Reworked texture/helm parsing, so hopefully NPCs should look as close as possible to live now (as close as we can without having textures for each armor slot in npc_types).
Added 'experimental option to add texture colors to npc_types_tint so that different armor slots can have different colors.

This should address blackdragonsdg's crashes.

The last change (npc_types_tint) generates a row in the npc_types_tint table for each armor slot, so NPCs with different colored items in each slot would look a bit more correct
(although I don't think there are many like that). I wouldn't recommend you select this option unless you know there is a specific NPC with multi-colored armor that you want to setup right.

I don't believe there are any existing NPCs in the standard PEQ database that use the npc_types_tint table, so it may not have been extensively tested.

There is more info about this table here: http://www.eqemulator.org/forums/showthread.php?t=28647

[Derision]

Originally Posted by Derision

I've not tested it (I will later), but in theory, if you start a new capture while you are already in a zone, the next time you zone, the extractor should
recognise the new zone and generate the SQL for that one.

OK, now I've tested it and it doesn't work so well on the current version, so I don't recommend starting a capture unless you are at character select,
unless, as Trevius suggests, you are comfortable with using Wireshark filters to just save the packets relating to the zone you are interested in.

As it stands now, starting a capture while you are already in a zone and then zoning will either cause the extractor to miss data when entering the new zone
(including crucial packets which make the collect unusable), or if a mob happens to spawn in the zone you are in, after you start the capture, but before you
zone, then that mob in the previous zone will be included in the data for the zone you are going to.