make SEQ smaller, faster, more modular ?!?!?!

[black.rabbit]

the problems:
a) my SEQ system isn't the fastest (P1/200; i would prefer my G4 to run it, but w/o a working libEQ ... well ... :-)
b) also i would like to do an alternate interface, but don't want to interfere with the existing algorithms.

so i had some ideas:
1) move the packet filtering stuff to a (kernel) module.
2) put the packet analysing stuff and the calculations in a library.
or maybe even more libraries.
3) module support for SEQ

what are the reasons:
with (1) the packet filtering runs in kernel mode, so it will not get interrupted (so easily) if it "doesn't want to" and it should have more ressources availible, or have more control over them. actually doing something like ipchains was my basic idea.

idea (2) should make it possible, to make different alternate clients, for example a C based Xlib only version. or even a
TTY only version for very very special things.

ok, for point (3) the idea is, only to load things that are needed.
if i don't want the "special AC tracking and hunt down" module, but instead need the "how to kill flippy 1000 times an hour" and configure this using a file, like apache does it for example.

additional thoughts:
i like C++ and Qt, but they grew a lot in the last years, and IMHO a C/Xlib (maybe Xt) based solution should be more suitable for smaller machines. i know they are a bit more complicated to do, because i did Xlib/Xt programming, and was delighted when i started with Qt.

also maybe more people could "donate" work to this project. some may like to shift the bits in the kernel, others prefer the analysis part, and last but not least some may like to work on GUI interfaces. maybe some even start to add skins to SEQ, with a site like "skins.seq.org" ... ack ... ;-)

[putting on my fire resistance gear ... ;-)]

[high_jeeves]

I'll say before everyone else gets here...

Its open source... drop us a line, and let us know how your "modularization" is going :)

--Jeeves

[black.rabbit]

this highly intelligent reply somehow gives me the impression you are a "on error resume next" user. and even the :) doesn't help it.

[high_jeeves]

No, I'm just a realist. This project is hardcore hobby work... I seriously doubt the dev's are looking to spend months on serious architecural changes for the sake of a 10% speed iprovement and a TTY renderer...

You must be one of those programmers that says "SOAP is the next big thing, all are products MUST use SOAP now!"... then 3 days later.. "WAIT! ebXML is the next big thing, all our products MUST use ebXML now!"...

--Jeeves

[fee]

black rabbit.

The project is always open to suggestions. The ultimate decision factor of code changes being implemented is up to the project folks.

I ran and developed showeq on a pentium 166 quite happily for a long time. At this point I doubt you will recieve much support for a C Xlib version though, atleast from me at any rate. I can almost guarantee libEQ will not be back ported to straight C.

I think I finally have access to a GNU toliet seat I could build libEQ, I'll see what I can do.

As to skins, I believe Qt supports a similar feature thru its Style class.

Anything you are willing to contribute would be well appreciated.

Fee

[Zaphod]

1) The packet filtering is occuring in the kernel using the existing kernel level filtering modules through the pcap library to maintain portability to other Unices... Then the packet capture thread makes calls to pcap to bring the captured data from kernel space to user space. We then do analysis and dispatch in the main thread. Except for having the seperate capture and main threads, this is basically also how tcpdump works. I'll let fee (floyd) respond further on this topic.

2) Yeah, but we'd prolly still keep them in Qt. Relatively speaking it's not adding too much memory/CPU.

3) Module support would be nice. We've actually been working towards that. We've come a long way towards seperating the GUI from the state storage and management. It's also why lots of the GUIs and state management are done in seperate classes in seperate files. We've also been working to get rid of some of the artificial interdependencies in the code base. Right now a migration to runtime loading of modules would be problematic without forcing a migration to Qt3. Which we are reluctant to force since many peoply have already had to upgrade compilers and Qt versions for ShowEQ, and I don't wanna deal with the uproar until we're ready to release ShowEQ 5 someday... ;)

As to speed and memory, we've come a long way. Between SEQ 3 and 4 we increased ShowEQ's speed tremendously and drastically decreased its memory footprint. We've still got things to improve upon, like seperating state maintenance from the GUI code in the ExperienceWindow, CombatWindow, and EQInterface. We also need to cleanup the handling of channel messages and support away of clearing the history (this history can get quite large over time) either on zone or via menu pick.

If you are having memory and some speed issues, start turning off certain displays. This would have more impact but one of the developers (you know who you are) removed the runtime instantiation of the Player Skills, Player Stats, and SpawnList of these GUI; this will be fixed. The map display is has been and continues to be one of the biggest CPU sucks of the entire program. If you have a slower machine I would recommend only using 1 map, and start turning off some of the "Show" options, or turning off "Animate Spawns". This can have a radical impact on speed. After that the Spawn list is a big CPU suck.


also maybe more people could "donate" work to this project.
As for volunteering and donating work, I await your FIRST patch with the utmost anticipation. We are making progress on improving ShowEQ, and we do need help. It's difficult to keep up with the latest Verant changes and add features. This is a well established and "old" code base with a lot of legacy. We're cleaning it up, but it takes time and support from volunteers like yourself. Just try to make your contributions modular, with GUI seperate from state/data storage, and without tightly binding modules throughout the code. Lastly, don't use the Experience Window (or it's son Combat Window) as the basis for future design. We could also use volunteers to help debug crashes, as well as protocol and structure changes from VI.

Enjoy,
Zaphod (dohpaZ)

[black.rabbit]

now this _is_ a response i was waiting for, because this is something where you can start to talk about ideas and how crappy they are.


Originally posted by Zaphod
As for volunteering and donating work, I await your FIRST patch with the utmost anticipation...

i will try to do my best, but i bet i will take some time before i will do something like that, because programming 5x10 at a large company isn't quite a good base to add some more hours of coding after work.

on the other hand, doing work for SEQ would be some creative work.

[black.rabbit]

Originally posted by high_jeeves
No, I'm just a realist. This project is hardcore hobby work... I seriously doubt the dev's are looking to spend months on serious architecural changes for the sake of a 10% speed iprovement and a TTY renderer...

a) i never wanted a TTY renderer ... on the other hand a pretty good idea

b) i never said the dev team _has_ to do the changes, but i was speaking of ideas, people could talk about. and maybe if some are interested they may team up to do something together.


Originally posted by high_jeeves
You must be one of those programmers that says "SOAP is the next big thing, all are products MUST use SOAP now!"... then 3 days later.. "WAIT! ebXML is the next big thing, all our products MUST use ebXML now!"...

interesting thought ... but if i would be such a guy, do you really think i would like to code in C ... wouldn't i be one of those java or C# fanatics ?

gimme a break, this is nuts ? why can't you reply in a manner like Zaphod ? if i wanted to start a personal flame war with you, i would have gone to the "Help Desk" and asked how to install "Windows XP" on a Mac.

i wonder if my question/ideas was/were really so fucked up ? can't have been so bad, or Zaphod must have been pretty stupid as well, to take the time to respond in such a big post ! and he knows how to kick ass is in a mannerly way.

[black.rabbit]

Originally posted by fee
As to skins, I believe Qt supports a similar feature thru its Style class.

that was just a sick joke ! do you really think i want to have such spiffy things ?

i really start to love Jeeves idea about a TTY renderer.


Originally posted by fee
...I can almost guarantee libEQ will not be back ported to straight C.

i already saw it is not C based, after i nmed it. i still hoped it is C based and "only" has a C++ wrapper in it.

[fee]

blackie wabbit,

welcome to the land of lunatics and insane childish taunting.


a) i never wanted a TTY renderer ... on the other hand a pretty good idea

i seriously hope this is joke...

See Zaphod is a polite individual who prefers subtly as opposed to outright AE fire. Its his way. The rest of us are somewhat more... wide open...., so relax and enjoy :)




Lesson 1, have a sense of humor.

Here endith lesson 1



Seriously though, if you submit any code in C expect it not to get used.

[high_jeeves]

I posted a perfectly reasonable response, you are the one who started with the name calling. There are too many people who come around here with feature demands... If you want changes, start adding patches instead of telling the developers what they should do for you...

I've run ShowEQ on my Pentium 75 laptop.. is it slow? Hell yes! Does that mean the developers should spend time rearchitecting their system, and rewrite the app in C and Xlib? No! (I just chucked my book on Xlib last week, I havent looked at it in 5 years, kinda made me laugh to here that people still write using this!)

As for the TTY renderer, here is a quote from you:


or even a TTY only version for very very special things.

So, lets not call it the jeeves TTY renderer....

--Jeeves

[Virusmaster]

Would be cool if the thing ran faster, but then again, computers are pretty cheap these days. I think I'll just upgrade :)

[black.rabbit]

how about a C++ TTY renderer then ?

well, let's see what i may do ...

what i really already learned, was the (1) in Zaphod's post, because i knew tcpdump uses libpcap, but i didn't know how it works. that's why i thought an ipchains like module - even it would be sort of linux only - may be more direct.

but fee, please don't go into those details.

[fee]

details?

[black.rabbit]

Originally posted by fee
details?


Originally posted by Zaphod
1) The packet filtering [...] tcpdump works. I'll let fee (floyd) respond further on this topic.


those details ... :)

[black.rabbit]

well, Jeeves, maybe to make my "a TTY only version for very very special things" clear, as i don't need the map, and only the display of changes in exp and skills, an X-less version would be quite enough for me.

i didn't fiddle around with parameters too much, but i believe even if every window is turned off, the proggy won't start up without X running - maybe time to prove me wrong.

because no one but me needs this, it was clear that i will have to do it.

but i want to still be able to use the current, well, let's call it SEQ engine, and i didn't know how modular the sources are - and i prefer another lecture than reading through sources of others in the evening again - it would be great if you guys already thought about moving some things to libraries, so it wouldn't be necessary to search through the list of the sources, where a class/function moved to, after an update.

i almost think i know what comes next: because you want to do your own stuff, why should we care about it. it looks like you are already doing something like this, as Zaphod detailed in (3).
maybe just do an additional step...

as i said, just ideas, not demands.

[S_B_R]

Look around for an app called Xvfb (X virtual frame buffer), you should be able to get SEQ running without an actual X server running and then you'd just what the console for the text version of SEQ. :D

[Rootuser]

I'm not a deep level kernel hacker by any stretch of the imagination, so take what I say with only the knowledge that I have some low level game programming experience and I have some insight into how good game companies think, although Verant might be an exception to the good game company theory.....

Zaphod said:

This is a well established and "old" code base with a lot of legacy. We're cleaning it up, but it takes time and support from volunteers like yourself. Just try to make your contributions modular, with GUI seperate from state/data storage, and without tightly binding modules throughout the code. Lastly, don't use the Experience Window (or it's son Combat Window) as the basis for future design. We could also use volunteers to help debug crashes, as well as protocol and structure changes from VI.



I think the foundation of SEQ is solid. It is paramount that this rock hard pillar be kept as the over all idea. While skins etc. might be a nice "add-on" if there is no real improve in functionality or CPU/Memory utilization (I would define this as changes of 10% or more) then I think perhaps you risk the stability of the product. I know the "Windows" crowd likes a nice GUI, and albeit, it does make things easier, but I think functionality should be the overall agenda. Command line options work just as well as GUI options, the point is to have "Options" rather than how you fire off those options.

As for legacy code, this is the only lesson I think we need to take from Micro$oft, keep legacy code forever, even if it is just "Sitting" there. Let's remember, a good part of the EQ world was built using certain schemas that SEQ was built upon (the way mob locations are broadcasted etc). Over time those tenants have changed slowly but surely, however it is just a few clicks away from becoming active again should Verant want to implement something. I don't know how many times I have pulled out old code that I thought may be useless but it fixed something that was broken by a 3rd party vendor (in this case Verant).

I will sign off this spammy post by saying "Thank You" to all the developers and real contributors to SEQ. You guys have done a great job, and I hope to be of help in the future as much as I can be.


Rootuser

[RSB]

I don't equate "Rendering" with just the map. To me the term refers more to data presentation in what ever form from the data storage. You know 3 layer model and all. It be a laugh to see a bit of an ascii map but I'd probably laugh (not in a negitive way but a crazy way) at the developer that did it.

Did anyone else ever see the ASCIIQuake that was being developed along time ago?

RSB

[Ratt]

Heh.. you laugh at a TTY renderer... when in fact I actually had a semi-working version of a TTY SEQ.

It never worked quite right and there was a big lack of interest in it, so the whole thing was abandoned ;)

[high_jeeves]

The ASCII Quake renderer is alive and well... its quite good actually... (for an ASCII renderer, that is)...

--Jeeves

[black.rabbit]

Originally posted by S_B_R
Look around for an app called Xvfb [...] the text version of SEQ. :D

just checked it out, basically it works (starting Xvfb and seq) ... thx.

only good it is friday, so i can play around with this setup.

[Pyzjn]

Its insane and not that easy to play.

Check it out.

http://webpages.mr.net/bobz/ttyquake/