EQExtractor2

[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.

[blackdragonsdg]

Originally Posted by joligario

Derision: There's something very important I forgot to tell you.
Blackdragonsdg: What?
Derision: Don't cross the streams.
Blackdragonsdg: Why?
Derision: It would be bad.
Blackdragonsdg: I'm fuzzy on the whole good/bad thing. What do you mean, "bad"?
Derision: Try to imagine all life as you know it stopping instantaneously and every molecule in your body exploding at the speed of light.
Trevius: Total protonic reversal.
Blackdragonsdg: Right. That's bad. Okay. All right. Important safety tip. Thanks, Derision.

Haha, that sounds like the conversations in the Monk chat channel during a raid. Apparently monkey math is different from what everyone else learned.

[cavedude]

Derision, you seriously rock. I did fib a little bit and found one more thing... Do doors still send teleport data? I know they used to, because that's how PEQ got most of its ports. I wasn't too concerned about it at first until I remembered about intrazone portals. I would make my life 100% easier if we could grab dest_zone, dest_x, dest_y, dest_z, and dest_heading.

[Akkadius]

Originally Posted by cavedude

Derision, you seriously rock. I did fib a little bit and found one more thing... Do doors still send teleport data? I know they used to, because that's how PEQ got most of its ports. I wasn't too concerned about it at first until I remembered about intrazone portals. I would make my life 100% easier if we could grab dest_zone, dest_x, dest_y, dest_z, and dest_heading.

I second this motion.

[trevius]

No, they don't send that info unfortunately, but, it may be possible to get it by waiting for clickdoor and then check where it sends them. Though, I imagine that would take a bit of work to figure out fully and also mean you would have to click every door and have it port you to get them.

[Derision]

Looking at a couple of examples (a teleport disc in the bazaar and one of the PoK stones in ... PoK), the door param is a reference to one of the zone_points,
so by cross referencing the data, I may be able to populate the relevant fields in the doors table for ports.

[KLS]

Yeah Cavedude mentioned it to me, and I was gonna post that the door data does appear to be sent as a zone in. I easily got port working with the nek book that way, I could of without but it saved me 2 minutes.

[trevius]

Wow, now that is a good catch! Makes sense, heh.

[Derision]

It doesn't appear to be the case in all zone, e.g. a couple of zone have a door_param of -1 for the PoK book with no matching zone_point.

Also the Arcane Disks in freeportwest have an open_type of 57 which is not handled as a teleport type door by the server,
but it is easy enough to go in and change the open_type afterwards, to 58.

[Derision]

In 1.9, for doors with opentype 57 & 58, if there is a zone point with an id that matches with door_param, then the destination zone and co-ordinates from the zone point
are used to populate the door fields.

[cavedude]

It would appear that this tool still functions after the patch!