ShowEQ -> Qt4

[brainiac]

I've started working on porting ShowEQ to Qt4.

I'm intending to do it just for fun because I'm bored and need something to do when I get home from work. So far, I've ported the code using the Qt3-Support compatibility layer, but as the Qt4 docs say, a lot of the interface is just broken because of the heavy use of docking windows (which changed significantly in Qt4).

It isn't really useable in Qt4 in its current state so I'm rewriting all the Qt stuff to adhere to Qt4 style and standards.

I'm also developing this on my hackintosh (OSx86 leopard 10.5) since it is the closest thing I have to a linux machine at the moment. ShowEQ works great on it too.

I was also thinking about implementing some sort of MacroQuest 2 integration support. Haven't thought more about that much so more on that later maybe.

Is there any kind of outside interest in this project? I know this is a major change so I don't expect to dump it on somebody else, but I'm mainly curious what kind of reception this would get.

[Carpathian]

I was thinking about converting ShowEQ to Qt4 myself actually a couple days ago. I think its a great idea personally, and opens up a lot of options for ShowEQ.

[brainiac]

My primary goals are to fix everything that broke in porting to Qt4, and upgrade all old Qt3 references to use the new classes available to Qt4.

My secondary goal is to clean up the interface and improve performance and map drawing.

Other changes I'm considering:
* OpenGL approach to the map. It would open all sorts of possibilities for high performance animation, etc.
* MacroQuest2 plugin to forward packets to ShowEQ. This would enable ShowEQ on switching networks where packet sniffing isn't practical.
* Streamline appearance, fonts, etc
* Item inspection, spell icons, spell descriptions, fluff.

[Carpathian]

I'd recommend taking a look at the graphics view framework in Qt4 for map drawing. It's capable achieving high performance results by itself, plus you can also change the rendering engine it uses to an OpenGL core with a few lines of code.

[brainiac]

I was able to spend some time on this over the weekend. My goal for the weekend was to convert to the new docking window system.

I wasn't quite sure the best way to achieve this. The approach I took was to subclass SEQWindow from QDockWidget. I also took it upon myself to order a book on Qt4 as something like that might be useful!

Screenshot of showeq running on my osx86 development machine, as well as a fedora 10 x86-64 vm:

http://www.vexislogic.com/files/showeq-qt4.png
http://www.vexislogic.com/files/fedora10-showeq.png

(I'd attach the screenshots but forum attachment limits are so small...)

Because of the changes in qt4, window setting persistence doesn't work quite yet, I'm working on that next. Also, Qt4 docking has changed and doesn't perform docking the same way Qt3 did. To avoid having awkward window arrangement, I've decided to make the main map window the central widget and stay glued there.

[Fatal]

Not to derail your thread, but how did you get it working on OSx? I'm using a 10 year old laptop and have a nice g4 sitting next to it but as of yet haven't been able to get it going.

[Carpathian]

To run ShowEQ on a G* mac you'll have to convert all the data in the packets from little-endian to big-endian. With the new intel macs you don't have to worry about that since they're both little-endian. So you'll run into a problem there, but it can be worked around with some extra effort...

[brainiac]

I've only had experience with OSx86. As carpathian said, it would be theoretically possible to get it working on the PPC platform, but it would require some work due to endianness issues.

You could try it, there is some code in showeq that makes an attempt at supporting big endian, but I have no idea if it actually works or not.

[Carpathian]

When you get to a point where you comfortable sharing the source for some stress testing, let me know. Plus, I'd be more than willing to help with porting over various piece of ShowEQ to Qt4. Again, just let me know.

[brainiac]

I had an old 10-BaseT hub that I had used for ShowEQ that had to have been ten years old die on me last week, and I didn't really feel like arp spoofing my router like I did when I was in college... :eek: Not having a solution for my switched network I came up with a solution...

I wrote a new feature for ShowEQ that I can best describe as a "remote packet server". Basically, instead of listening to the local machine's packet stream, it will go into listening mode waiting for a connection from an external packet source. It uses a fairly simple protocol to receive packets that are sent to/from an everquest client. The packets come in an already processed form, so there is no decoding necessary.

On the other end is a MacroQuest 2 plugin that intercepts calls to the send/receive message routines, and forwards the data to the connected ShowEQ server at the other end.

I wrote it for my Qt4 port of ShowEQ, but I support I could easily backport it to the qt3 svn as well if there is any interest.

The client could just as easily decode the packet stream as ShowEQ does, but I took a shortcut and used code I already had available to me to intercept the packets after they had been decoded from within EverQuests's process.

[Carpathian]

Nice, really good work. But bah I say to porting back to Qt3, need to move forward! ;-)

[purple]

If you expect the packet forwarding thing to get merged into the central codebase, be sure:
1) You post a diff that isn't cluttered with other stuff in it. Please just changes for one thing in a diff. This change has nothing to do with QT4.
2) It is optional. There are many shades of cheating in EQ. People have different levels of comfort. Not every showeq user would be willing to run MQ2 or even anything on the EQ client computer that may be detectable, but are willing to passively sniff packets from a separate computer.

[Razzle]

So basically, you need to run MQ2 to forward packets to SEQ? I am not seeing the point of turning SEQ into a client/server setup that reads memory from the EQ process. SEQ's biggest benefit is the fact that it is entirely passive. I do understand that SEQ is much more robust as compared to MySEQ, but if those additional features are what is needed, knock yourself out.

Razzle

[Carpathian]

You could also just write the program stand alone and have it packet sniff on the windows box and forward the EQ packets to the SEQ machine. Either way...

[brainiac]

If you expect the packet forwarding thing to get merged into the central codebase, be sure:
1) You post a diff that isn't cluttered with other stuff in it. Please just changes for one thing in a diff. This change has nothing to do with QT4.
2) It is optional. There are many shades of cheating in EQ. People have different levels of comfort. Not every showeq user would be willing to run MQ2 or even anything on the EQ client computer that may be detectable, but are willing to passively sniff packets from a separate computer.

No problem. I'm looking into porting it back to the svn release (no other extraneous stuff). I've implemented it as a command line option. Launching showeq with --remote will put it into remote listening mode and will not use a pcap thread.


So basically, you need to run MQ2 to forward packets to SEQ? I am not seeing the point of turning SEQ into a client/server setup that reads memory from the EQ process. SEQ's biggest benefit is the fact that it is entirely passive. I do understand that SEQ is much more robust as compared to MySEQ, but if those additional features are what is needed, knock yourself out.

Basically. The way I see it, I always use MQ2 anyways, and I love ShowEQ so it was a win-win for me. It is certainly optional and doesn't present any added risk to somebody that would otherwise be using MQ2.

Of course, I'd have to write up an MQ2 plugin that I could distribute safely, and I think that's going to be the biggest problem for me.

[purple]

Like I said, I have no problems with it conceptually as long as it is optional.

For the mq2 plugin, Just post the cpp file for it on the forums here (and/or on the mq2 forums). If people want it, they can figure it out.

[brainiac]

Some things came up so this is on the back burner for a few but I'm still working on it.

As for the remote server thing, I used some Qt4 specific stuff that makes it a bit difficult to backport to Qt3, so I'm just going to hang onto it until I finish up the rest of the Qt4 stuff.

[brainiac]

Ok, as you know, I've been working (slowly) over the past couple weeks converting portions of the ShowEQ codebase over to use new Qt4 paradigms.

I've been doing my development using a local subversion repository to keep track of my changes (there are tons), but I'll go ahead and say this now, there wont be any merging this back. This is a new branch of development, and I've thought of some interesting directions I can take this to make showeq more useful again.

I want to make the source as I have it so far available for testing, but had a couple questions: Should I find public version controlled hosting, or can I add this to the sourceforge showeq svn as a branch? I can release tarballs willy nilly but I just find that to be inefficient for testing purposes.

Also, since I'm largely relying on Qt4 development practices, I've done away with the preexisting automake/autoconf support files and am going exclusively with qmake. I intend to take full advantage of the features provided by Qt4.

[BlueAdept]

I have the ability to make you a dev, the problem is that I have not spent the time on figuring out how to make specific branches.

I do not see a problem keeping it here as a separate branch.

Am leaving now but will be back on Sunday. If there are any objections to giving brainiac dev access let me know.

[purple]

I don't think he should get dev access personally. I've not seen anything that shows me the kind of work he does. Realize I'm not saying he should never get it. I'm just saying right now, he's just some posts on a message board to me.

Are you trying to replace the current showeq then? You need to be talking to ieatacid (as the only active developer right now as far as I know) about this. I don't want to see multiple versions of splintered projects. We're lucky enough to have one person willing to maintain live compatibility in a consistent and speedy way. I don't want to split the pool of potential people to pick up that mantle between two different projects.

I'd personally prefer you suck it up and submit a patch anyways with the end goal being that the patch is merged and we move to ShowEQ version 6.x and you end up as a developer along with ieatacid. Then you can continue your work on the main repo as you see fit.

But I don't feel comfortable letting this happen without at least seeing what you're doing a bit.

At this point, if you're comfortable with what you're doing and do want to eventually get this in the main repository and become a developer, just get me a patch or give me access to your svn repo or a tarball or at least something that will get me trusting you more than I do right now.

If I see good stuff, I'd definitely be behind making you a dev and branching the 5.x code that is on trunk now and helping get trunk to be the new QT4 6.x line. We can decide whether we want to maintain both for a bit while the QT4 line stabilizes or what.

[brainiac]

Thanks for the input, purple. Sounds like a plan. I don't want to sound like I am trying to thrust my way in or anything, I am mainly just seeing what my options are.

That said, I'm moving next week so finding time to wrap up some in-progress changes might not happen until after.

I'll keep you posted.

[twizzlerz]

I don't want to lose or replace "plain old" SEQ so I'm for keeping the projects separate - not to mention keeping MQ away from SEQ.

That's not to say I wouldn't use SEQ if it were fancier and I had no choice, but I'm of the opinion it does everything I need need (mainly skittles/ground spawns). Personally I don't need anymore than these two.


We're lucky enough to have one person willing to maintain live compatibility in a consistent and speedy way.

[brainiac]

Sorry for lack of updates. Got married, moved, got a new job, etc.

Anyways, thought I'd throw out something to spur anybody who cares about what I'm doing on..

http://www.vexislogic.com/dev/showeq-windows.png

Thats showeq running natively on Windows 7... Network code is *almost* working, but I haven't had a chance to merge the latest patch changes into my source.

[Fatal]

Need some testers?

[BlueAdept]

Looks good. Would it be native to windows or can it be compiled under both windows and linux?

[Carpathian]

Theoretically it should be compatible with Windows/Linux/MacOS because of the cross compatibility of Qt4.

[brainiac]

Theoretically it should be compatible with Windows/Linux/MacOS because of the cross compatibility of Qt4.

exactly.

The difficulty lies in the network code which doesn't use Qt4.

[Razzle]

Outstanding job so far.

I was looking at winpcap for functionality before, and that seemed the easiest way to go from what I saw. I have an old version of the windows version of seq lying around somewhere and that was what it used.

Razzle