My plan for ShowEQ!

Alright folks, my current plan of activities for ShowEQ, in no particular order, are:

• Add version information to the XML based opcode files. Reasons:
  
  1. To make it easier to diagnose when people have the incorrect versions installed and being loaded from one directory or another.
  2. To support the possibility of automatic opcode file updates.
• Split packet capture front end into a seperate program that communicates with ShowEQ either via pipe (local packet capture) or TCP/SSL connection (to allow remote packet capture). Reasons:
  
  1. Make ShowEQ more flexible on the packet capture and network topology front.
  2. Possible support for having the seperate program be setuid root without ShowEQ being...
  3. Potential for supporting doing the package capture on a Windows box.
• Make XML configuration file based EQ Network packet structure handling.
  
  1. Eliminate the need to do a full new ShowEQ release every time SOE patches.
  2. To support the possibility of automatic structure file updates.
• Add the ability to automagically download updated opcode and structure configuration files. Do I really have to tell you the reason... ;)
• Organized packet capture display with the ability to filter in/out different packets. Potentially with support of live visual structure alignment and opcode map editing.
  
  1. Make it easier to adapt to patches on patch day. :)
  2. Make it easier to figure out what different opcodes/structures are used for/contain. Thus allowing developers to more readily add support for new features based on those findings.
• Try and fix/improve the window docking. It is unfortunate that Qt is not being more cooperative. It looks like that is part of what's being improved in Qt 4).
• More general packet system cleanup/optimization.
• Move all non-GUI related stuff out of EQInterface.
• Improved filtering system.
• Better support for map editing.
• Better support for map optimization.
• Seperate UI from data storage/handling in Combat Window and Experience Window to make them easier to maintain.
• Create new and improved item db support using sqlite/MySQL backends and the possibility to work with ksmith's eqitems database.
• Actually add a menu-item for Help if and when certain suckers, err, volunteers write some help files for ShowEQ. Current volunteers:
  1. mooman_fl
  2. horseshoecrab
  3. elf
• Work with tanner on adding unit tests using cppunit.
• Find a volunteer to write a new INSTALL.newbies.
• Include an up-to-date FAQ with the software where it belongs.
• Maintain Gentoo ebuilds for showeq and showeq-maps.
• Coordinate with different volunteers on policies for maintaining packages for other Linux distributions (debian, Fedora, etc.).

This is a living list of the things I plan to work on in ShowEQ. I'll try to keep this maintained. I'll create a seperate list for projects/ideas I'm looking for volunteers for.

The items in this plan are subject to change at my discretion and/or whim and they'll get done as I have time to finish them. If someone wants to volunteer to help with something or sponsor a feature, let me know.

Items On Approach to completion:

• Maintain Gentoo ebuilds for showeq and showeq-maps.
• Coordinate with different volunteers on policies for maintaining packages for other Linux distributions (debian, Fedora, etc.). Current maintainers:
  
  1. tanner - Debian .deb's
  2. pac1085 - Slackware
• Start using Doxygen to help document the project.

Items Recently completed (formerly appearing above):

• Split maps into their own CVS repository and tarballs. Reasons:
  
  1. They change at a predominantly independent, typically much lower, rate from the other files in ShowEQ.
  2. They make up the largest single component of the distribution, artificially increasing the size of both tarballs and the duration and bandwidth requirements of package wide cvs commands (checkout, update, diff, tag, etc...).
  3. Maps are pretty much ShowEQ major version independent, the same maps work in both ShowEQ 4.x, 5.x, as well as assorted non-ShowEQ tools.
• Cleanup Makefile.dist. Reasons:
  
  1. It offends my gentile sensibilities... :eek:
  2. The file currently should have a disclaimer at the top: "There be dragons here!"
  3. There is lots of crufty code that is no longer necessary and is a bitch to debug in there.
• Make the ShowEQ packaging be more in line with the GNU standards, this will require:
  
  1. Rename CHANGES to ChangeLog.
  2. Creating NEWS, and AUTHORS files.
• Update the INSTALL guide.
• Move to a tarball/package based distribution method.

Enjoy,
Zaphod (dohpaZ)

Sounds great!

Re: separate data storage and UI

It would be great to be able to more tightly configure what gets logged (e.g. spawn paths for only certain mobs, spawn frequency, etc.). After scratching around a bit on this, it appears that the current log system already supports this for the most part, but sifting out the relevant data often requires some munging with perl to get at the part that you want.

More generally, increased modularity can only be a good thing. I have a sneaking suspicion that many MMORPGs are similar to EQ in that they broadcast much more information than the client strictly needs, because the computation for filtering unnecessary data out would be fairly expensive to do server-side.

So, more modularity would ultimately mean that ShowEQ would be easier to adapt to new games, like EQ2.

Quote:

---

Originally Posted by Zaphod

[*]The file currently should have a disclaimer at the top: "There be dragons here!"

---

I definately agree with the one above. I like dragons.

The one thing keeping me from using 5 is the window docking issues I have. I know several other people have the same problem.

Edit: wanted to make this problem clearer than I did (was early and was 1/2 asleep)

My problem is that it is very hard to control where the windows go. I like it displayed the way that the old SEQ was. Im a minimalist and only have the map and the (old) spawn list. When I try to do it with 5.x, I have a very hard time moving the windows exactly where I want them. I do tend to change the map window size quite frequently and it will end up undocking and then getting messed up. No matter what I try, I cant seem to get it back the way it was. Even if I had saved the thing when the windows were correct, if I reload SEQ, my windows are still messed up.

Other than that, wanted to thank you for making SEQ better than it ever has been.

Add version information to the XML based opcode files.

Hmmm. That seems like low hanging fruit. I've only stuck my arms in enough to fix structs and opcodes after patches so far. Zaphod, can you go into a little more detail about this? Just add an MD5 checksum and a version/date to each XML file and then on startup print out the version/date and whether the checksum passed? The checksum would help identify people who hand modified their XML and the version will at least allow people here to identify people using old config files quickly.

The big stuff on your list to me seem like packing the structs using XML config files instead of compile time structs. That's going to open the door for runtime adjustment of structs and better struct visualization in seq, which would be really sweet. I guess you'd just store name, offset, type, and size and write a class that would easily fetch by accessor or by name.

Quote:

---

Originally Posted by BlueAdept

I definately agree with the one above. I like dragons.

The one thing keeping me from using 5 is the window docking issues I have. I know several other people have the same problem.

Edit: wanted to make this problem clearer than I did (was early and was 1/2 asleep)

My problem is that it is very hard to control where the windows go. I like it displayed the way that the old SEQ was. Im a minimalist and only have the map and the (old) spawn list. When I try to do it with 5.x, I have a very hard time moving the windows exactly where I want them. I do tend to change the map window size quite frequently and it will end up undocking and then getting messed up. No matter what I try, I cant seem to get it back the way it was. Even if I had saved the thing when the windows were correct, if I reload SEQ, my windows are still messed up.

Other than that, wanted to thank you for making SEQ better than it ever has been.

---

What I've ended up doing is undocking all the windows and moving them where I want them that way, then just save preferences and leave them undocked.

Quote:

---

Split packet capture front end into a seperate program that communicates with ShowEQ either via pipe (local packet capture) or TCP/SSL connection (to allow remote packet capture). Reasons:
Make ShowEQ more flexible on the packet capture and network topology front.
Possible support for having the seperate program be setuid root without ShowEQ being...
Potential for supporting doing the package capture on a Windows box.

---

this would be nice, have the pcap part startup as a service and showeq able to run as user and just depend on that service running to get its info.

Zaphod,

This sounds like some really cool stuff. If only I had the knack for programming, but alas I do not.

I might however be able to find some time to make a contribution here and there towards the help files you alluded to. What exactly did you have in mind for the help? Would it be context-sensitive help the way newer Windows apps work with the "?" on the menu bar that illustrates a tool-tip in a window or a generic help file broken up into chapters? Either way, I think I could make a decent contribution where help is concerned with the pre-requisite that I understand the feature. :)

WOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOTT!!!

I'm just glad to see Zaphod back working, I don't care what he does :)

I'll be glad to help with help files, since my C skills are about the value of void {return;} *grins* Just tell me what ya want written, format rules, and the like, and I can finally feel like I'm giving something back.

Quote:

---

Originally Posted by horseshoecrab

Zaphod,

This sounds like some really cool stuff. If only I had the knack for programming, but alas I do not.

I might however be able to find some time to make a contribution here and there towards the help files you alluded to. What exactly did you have in mind for the help? Would it be context-sensitive help the way newer Windows apps work with the "?" on the menu bar that illustrates a tool-tip in a window or a generic help file broken up into chapters? Either way, I think I could make a decent contribution where help is concerned with the pre-requisite that I understand the feature. :)

---

Quote:

---

Originally Posted by elf

I'll be glad to help with help files, since my C skills are about the value of void {return;} *grins* Just tell me what ya want written, format rules, and the like, and I can finally feel like I'm giving something back.

---

Thanks for the offers of help. Right now I have mooman_fl starting some stuff, but we're still working on the details. Maybe we can divide up the load considering how little documentation exist for ShowEQ. Right now most of the discussions about help have been occurring on my IRC server irc.doomed.to port 6667 #ShowEQ. Or we can start a new thread here to hash out the details.

So here's the current list of documentation volunteers as I see it:

1. mooman_fl
2. horseshoecrab
3. elf

Thanks and Enjoy,
Zaphod (dohpaZ)

Quote:

---

Originally Posted by purple

Add version information to the XML based opcode files.
Hmmm. That seems like low hanging fruit. I've only stuck my arms in enough to fix structs and opcodes after patches so far. Zaphod, can you go into a little more detail about this? Just add an MD5 checksum and a version/date to each XML file and then on startup print out the version/date and whether the checksum passed? The checksum would help identify people who hand modified their XML and the version will at least allow people here to identify people using old config files quickly.

The big stuff on your list to me seem like packing the structs using XML config files instead of compile time structs. That's going to open the door for runtime adjustment of structs and better struct visualization in seq, which would be really sweet. I guess you'd just store name, offset, type, and size and write a class that would easily fetch by accessor or by name.

---

They are all related to my effort to support downloadable updates and making it so that we can hopefully decouple ShowEQ's code release schedule from the EQLive patch schedule. And to provide the tools to make it easier for us all on patch day. I'm still hashing out the details of how I'm going to implement these features. Working through the different benefits and costs of different implementation strategies. Feel free to join me on irc.doomed.to port 6667 #ShowEQ. Currently I suspect they'll be a transition period as different aspects of it get phased in.

Thanks and Enjoy,
Zaphod (dohpaZ)

Hey Z, life has been hectic with work due to end of the quarter fiscal stuff typical in a large company. I'll try to catch up with you after I get this nonsense behind me.

I would like a class setup that would store status of things like current zone info (name, exp multiplier, etc) and maybe currently targeted mob. That sort of thing. It would get updated when this data changes. And would be globally readable for queries. I was thinking of spawning a class for this but if you are going to do a big re-write I don't want to write something that will be obsolete right away.
Whats the time frame for all this cool stuff? Has someone been working (instead of sleeping) for months already on it? Or is it not yet started? Oh, it sounds great! :)

L1A

Stuff is in-process and being worked on as time permits. I'm hoping to get another thing or two finished in the next few days.

I'm not sure exactly what you are looking to accomplish with your storage? i.e. what are you going to use it for?

Enjoy,
Zaphod (dohpaZ)

L1A wrote a right click context menu item for the spawn list that will exec a command to lookup the selected spawn in a web search. They had problems getting the current zone to pass to the script from the spawn list class I think, just because it wasn't readily available from that context.

See this thread

First, the current zone name is always available from the ZoneMgr::shortZoneName() which is available in EQInterface as EQInterface::m_zoneMgr. The point is, the information is currently stored, available, and accessed from elsewhere in the code. I'll address further thoughts on his patch in that thread though.

Thanks for the pointer to his message Purple, a little context helps.

Thanks and Enjoy,
Zaphod (dohpaZ)

Sorry been away for a few days. I had a vague idea that a single class you could go to and retrieve current statistics would be useful. But I guess it is not that big a deal. You can get the information elsewhere and it just adds overhead.
Thanks all.
L1A