Sniff forum part write only

[StormByte]

I agree that Sniff forum part should be read only, as it contains private data on the sniffs over the character and account, but this also exposes one big problem: lack of feedback:

I explain myself, the fact that you can't even read your own posts makes any developer unable to get even more feedback, like questions that may arise about the sniff, extending the sniff and so.

I think it would be great if you could enable it to read only your own posts in that subforum, to be able to answer questions, and even more (like for example, a developer stating that the sniff is being used currently,so you can follow close the development about it, and many many other).

What about that, is it possible/wanted?

[Carbenium]

I'm not familiar with the forum software we use but currently we try to answer questions which are in the sniff posts through PMs.

Kind regards,
Carbenium

[Nay]

Soon enough we'll have a platform to upload sniffs that is not a forums. I'll try to add those features you talked about to it.

[StormByte]

Ok then, I have more ideas to that (and also I take ideas of one of TC dev, don't remember who, I read somewhere about sniffs).

This I implemented in my own server for my friends to report bugs to me (and I forward to you), like this:

1. Have a copy of latest world DB in the target server we are using for uploading sniffs (to enable better support for later points)
2. First of all, it is IMPORTANT, to have, in the upload part, a drowdown list, with the sniff area, also stored in database, this way, we can filter sniffs WAY better, and not only in the filename. All the data here can be grabAn example:
   1. Drop down 1 SNIFF TYPE: Dungeon, Exploration Zone, Questing, Item/Area trigger, NPC, OTHER<etc>
      1. DUNGEON selected
         1. Drop down 2: DUNGEON NAME
         2. Drop down 3: DUNGEON DIFFICULTY
      2. EXPLORATION selected
         1. Drop down 2: CONTINENT
         2. Drop down 3 (depending on 1): ZONE
      3. QUESTING selected
         1. (the 2 drop downs from 2)
         2. Min level, max level, race and class
         3. OPTIONAL but useful, A multi select combo box, to select the quests present in sniff (it would be a little work for uploading users, but the benefit of recording the quests is GREAT for later finding)
      4. OTHER selected
         1. A text box to put a description is added (but we need to try to avoid this, or warn the uploaders that this is the least helping option as the filtering is useless in this case)
      5. ITEM/AREA TRIGGER selected
         1. Then, display a list of items to select which item was tested, you know, there are some items which don't work as they need scripting.
      6. NPC
         1. NPC information only, for vendors, rares, and missing loots (for example, the misterious camel figourine is missing the loot currently in TC 6.x)
         2. Then, display a list (or a text to find the NPC) so it can be selected.
   2. With this, we are able to completelly filter, catalog and index the sniffs to be more usable for later, instead of blindly looking, if one dev is implementing dungeon X, he can find better the data. (Way better than a forum search, or forcing the dev to index the files with good names in his own hdd)
3. Are we talking about a dedicated hosting platform to host the sniff files?
   1. In this case, is the sniffer packet software opensource? (the one which handles the sniffs to see the data)
      1. In this case, we could make the uploads in zip file, read it, and replace sensitive data, like char name, account name, guild name, whispers, and the like to be like UUID numbers (to keep consistency, as this data is irrelevant for development), so <char_name> can be replaced to charname1, <guildname> to guildname1 and all messages/whispers to XXXXXXX automatically once upload is finished (by calling a cgi-bin, being it implemented in PHP, or something else)
      2. With this method, no read protection is needed, as no sentisitive data is stored, FURTHERMORE: We can also implement something like VIEW SNIFF, which will use the wow packet software to display a list of CMSG or SMSG sent/received in a web fashion (only a summary)
   2. If not, or it is too hard to do this, then just store the files with a record in database containing the points before.
4. If we can't store them as of lack of money for a hosting or something else, then, just a basic info stored in database (the points from main 2), with the link, but this is the last prefered option, as they may get deleted later, or the hosting may fail eventually (sometimes mega for example, makes the files unavailable temporarily)

I hope some of this ideas render useful for this purpose.

EDIT: I am sorry I can't help with opcodes as I don't have experience on them, but if you need PHP development help, or with database design, I can help with that. (HINT, if you go this way, I strongly suggest postgreSQL, as with table inheritance is way better and faster to implement the different types of sniffs)

Edited August 9, 2015 by StormByte
Added more info

[Nay]

We actually already have most of that implemented...

The name of the "sniffer packet software" is WowPacketParser

With SniffData we can filter by all these fields: https://github.com/TrinityCore/WowPacketParser/blob/master/WowPacketParser/Enums/StoreNameType.cs#L8-L28

 

However this doesn't allow for users to easily upload sniffs to the platform.

 

About anonymizing  sniffs see https://github.com/TrinityCore/WowPacketParser/issues/171

[StormByte]

 

However this doesn't allow for users to easily upload sniffs to the platform.

​That is why I asked what's the plan, to have a hosting, or just another software instead of a forum manager. If a hosting can be kept, then it should be as easy as a form with upload file support (it could also enable auto-anonymization I suggested, once the upload is finished)

EDIT: As I see in your image, it can be somehow imported to database! Even greater than I thought  

Edited August 9, 2015 by StormByte