Tool for Scripters/DB devs

I think we need a tool to allow scripters and db devs to research sniffs in a better and easier way.

The tool needs to be multiplatform and license must be AGPL.

The idea is you load the parsed sniff into the tool, (it needs to open huge txt files, over 1 GB on size) then:

  • 1st dropdown will allow the dev to select what he wants to research (for example: creature, gameobject, vehicle, npc_text, poi, waypoints…)

  • 2nd dropdown will list the IDs of the creatures/gameobjects/vehicles you have selected (allows multiple selections).

  • 3rd dropdown will list the GUIDs of the creatures/gameobjects of the ID(s) you have selected (allows multiple selections).

When you select the GUID(s) under the dropdowns, you will get the coords for a creature/gameobject or creature using the npc_text or the quest of a poi.

And under that, on the left, you will have the timing(s) where sniffer found the selected object.
When selecting it on the right, we will see the actions performed by the object at that time.

In case of waypoints allow to load maps and draw the route of the creature.

Looks like a good idea, maybe providing a documentation regarding the format of the files that need to be parsed can help a lot whoever is going to implement this

The waypoint creater I made does this for waypoints. It’s hard to write a program to do everything.

@Shin: It is probably advantageous to implement a new machine readable output in WPP since the produced txt files aren’t really consitent. That should be the first development step.

Quite interesting. Any idea on the language that should be used?


Why C#? I mean. You are asking for someone to do it. Can’t it be Java? Or maybe the developer’s choice? What’s more multiplatform?

As for the multiple-selection dropdowns… don’t think that’s posible without making your own component. I don’t really think that part is actually needed. Anyways. I could do this, but I am new to the project and stuff. Any help on how to read the sniffed data would be much appreciated.

Thanks. (surprise! it’s written in C#)

If I understood it right, this tool @Aokromes is asking is a separate tool. The only thing in common between the two tools is that one has to process the processed txt file from the other. So, as I said, why the second tool has to be writen in C#? Why can’t I do it in e.g. Java? Just want to know. I can do it in C# but I’m just curious.

It can be done in any language. It just needs to work and be useful :slight_smile:

maybe the SQL output of WPP can help this part since it comes down to MySQL performance. After all this tool does not much more than a MySQL SELECT, it just needs data being stored in a more query-friendly way (waypoints drawing is a separated topic than sniff filtering).

For quite some time now, I have been working on a tool called SniffExplorer that does exactly you were looking for:

It’s written in Java and it is very flexible. The downside is that I didn’t wrote any GUI so the only way to use the app is by code. On the other hand, the app allows so much flexibility. Some of that flexibility would be hard to expose through any GUI.

A good starting point is here:

Also, here is a few more examples of use:

Contributions are welcome. The documentation is pretty much inexistent however I would be happy to answer to questions.

PS: the main target of the app is wotlk sniffs (3.3.5 12340)

– chaodhib

Oh noes, parsing arbitrary text :o

That is going to break at any minor change to current WPP output format…

Yes, it’s parsing the text output of WPP. Sadly, I didn’t have any alternative when I started to wrote the app. And as far as I know, WPP still does not support the serialization of structured data. By focusing on wotlk sniffs, I didn’t have too much issues regarding changes of the output format. Obviously though, this is clearly a big weakness of the app. And the only way solution is to extend the capabilities of WPP.

Nonetheless, my app has provided with an invaluable source of information. The ability to filter packets by expressing the set of conditions that determined if a packet is relevant to me or not and then getting the result in matter of seconds (as opposed to manual search that can take hours/days) has been incredibly fruitful to me. It also allowed me to test certain assertions (1) quite easily: I just wrote my condition and I let the application go through the entire database of wotlk sniffs that I have at my disposal. Then I let the app do its work while I do something else and I had the result after an hour. Doing the same thing by hand would have taken me days…

(1) for example that some packets such as MSG_MOVE_ROOT, MSG_MOVE_WATER_WALK, MSG_MOVE_HOVER, etc… are only packets transferred from Server To Client cf

I didn’t mean to say that it didn’t provide value, au contraire, tools like this are absolutely needed.

However, imo, relying on the fragile text output format of WPP is insane; it will change and it does not matter the client version.

The time spent implementing the text parsers could be used to change WPP so that it can output in a better format.

@Polaretto is working on changing this so let’s help him :slight_smile:

We briefly discussed about this on github (link for reference). I’m trying to refactor the output part. Btw I’m assuming that the txt output doesn’t have to be exactly the same as before… Am I right? Or changing it would break something?

The “new” text output won’t have to be the same and it will break stuff (but that’s on the people that assumed that non-formatted text is safe to be consumed).

Can’t you just port the WowPacketParser data model to separate project, and use protobuf to serialize and then deserialize the data in whatever program needs to use it.

If I’m not mistaken, this is what we want to achieve:

step 1) WPP should instantiate and fill one object per packet. The class of the object should depend on the opcode of the packet. This class should model the packet and each class’s instance should be able to store every information that could potentially be included in that type of packet.

step 2) serialize each “Packet object” into text format (json, xml, …).

If JSON is chosen, the step 2 is fairly simple in Java once the right library is plugged into the app. I assume it’s the same for C#. So step 1 would be most of the work. ( could be used as a starting point).

@KrudorI don’t think ProtoBuff would be suited for the job regarding the serialization. If I’m not mistaken, with ProtoBuff, one Packet would have to be stored in a seperate file. What would be more suitable for the user would be to serialize every packets contained in the sniff in one single file (otherwise, there would be hundreds of thousands of files).

@Nay Indeed.

WPP does not have a “data model” for packets atm.

That’s more or less what needs to be done… except that the same packet can have different representations across client versions.