Quote:
|
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.
|
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. |
1.8 is available
Code:
Permalocked onto stream using C->S OP_ZoneEntry to reduce chance of multi-boxing messing the collect up. 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 |
Quote:
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. |
Quote:
|
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.
|
Quote:
|
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.
|
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. |
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.
|
Wow, now that is a good catch! Makes sense, heh.
|
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. |
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. |
It would appear that this tool still functions after the patch!
|
All times are GMT -4. The time now is 08:07 AM. |
Powered by vBulletin®, Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.