Raistlin
12-30-2003, 03:13 PM
Apologies in advance if this turns into a long message.
So here's what i'm trying to do. After reading several ideas for SEQ over the last year or so i've been on the boards i've noticed that one of the big issues to getting new SEQ "plugin" programs so to speak implimented is the fact that there doesn't seem to be an easy way to get ahold of the data SEQ has after the decryption/uncompression/unrolling of the packet stream. What would be useful to alot of people (in my humble opinion) is if SEQ could take the translated data and format it somewhere where other programs (like log parsers, bazaar watchers, etc.) could read them.
Programs off the top of my head I could think of that might be useful. Timer programs (for various EQ related timers...alot of this is already in SEQ, but there might be a need for other stand alone situational timers), log parsers (Yes, there is a small DPS parser included, but it doesn't give the flexability of something like EQCompanion), and bazaar watcher programs are just a few of things that could be done outside of the SEQ development arena if we had access to the decrypted/formatted packet stream.
So this morning I started looking into SEQ to see if it would be possible for me with a limited knowledge of QT (but a good background in C/C++) to get the packet stream sent out to a file sort of as an exercise in "could this be done".
I think I have the point in the code where the packet data has been decoded, decrypted, unrolled, put together (if fragmented) and ready to be sent to the handlers for the particular opcodes, but I don't QUITE get it.
I've found dispatch->activate which breaks down to an emit signal(data, len, dir) which I believe to be the decompressed/formatted packet being sent (by QT signal) to the various packet handlers...
What I don't get (Havn't found yet) is where the signal handlers are setup (I do see a bunch of connect2's in interface.cpp, but the signal/slot names don't seem to match) to receive the emitted "signal" and it's relivant data, or where that data is processed.
So, here are my questions.
1) Is this outputting of a packet somethign that SEQ already does? And if so can someone give me a clue as to where it is.
2) If it doesn't already do something like this, is this something that anyone sees a potential need for? Should I be wasting my time doing this?
3) Mostly if the answer to the last question is yes but just for my own edification and understanding also, can someone give me a pointer(get it, pointer?) to where in the code the emitted signal is being picked up, or how/where the correct signal/slot linking is being done?
Ok, I guess flame away if i'm being a tool about this...I know, I know, *mutter damned newbie developers...*
--Raistlin
So here's what i'm trying to do. After reading several ideas for SEQ over the last year or so i've been on the boards i've noticed that one of the big issues to getting new SEQ "plugin" programs so to speak implimented is the fact that there doesn't seem to be an easy way to get ahold of the data SEQ has after the decryption/uncompression/unrolling of the packet stream. What would be useful to alot of people (in my humble opinion) is if SEQ could take the translated data and format it somewhere where other programs (like log parsers, bazaar watchers, etc.) could read them.
Programs off the top of my head I could think of that might be useful. Timer programs (for various EQ related timers...alot of this is already in SEQ, but there might be a need for other stand alone situational timers), log parsers (Yes, there is a small DPS parser included, but it doesn't give the flexability of something like EQCompanion), and bazaar watcher programs are just a few of things that could be done outside of the SEQ development arena if we had access to the decrypted/formatted packet stream.
So this morning I started looking into SEQ to see if it would be possible for me with a limited knowledge of QT (but a good background in C/C++) to get the packet stream sent out to a file sort of as an exercise in "could this be done".
I think I have the point in the code where the packet data has been decoded, decrypted, unrolled, put together (if fragmented) and ready to be sent to the handlers for the particular opcodes, but I don't QUITE get it.
I've found dispatch->activate which breaks down to an emit signal(data, len, dir) which I believe to be the decompressed/formatted packet being sent (by QT signal) to the various packet handlers...
What I don't get (Havn't found yet) is where the signal handlers are setup (I do see a bunch of connect2's in interface.cpp, but the signal/slot names don't seem to match) to receive the emitted "signal" and it's relivant data, or where that data is processed.
So, here are my questions.
1) Is this outputting of a packet somethign that SEQ already does? And if so can someone give me a clue as to where it is.
2) If it doesn't already do something like this, is this something that anyone sees a potential need for? Should I be wasting my time doing this?
3) Mostly if the answer to the last question is yes but just for my own edification and understanding also, can someone give me a pointer(get it, pointer?) to where in the code the emitted signal is being picked up, or how/where the correct signal/slot linking is being done?
Ok, I guess flame away if i'm being a tool about this...I know, I know, *mutter damned newbie developers...*
--Raistlin