Ferok
09-10-2012, 12:58 PM
Hello,
I understand that SEQ/MQ is prohibited (and rightly so), as these things give an advantage and provide information that is not otherwise exposed through the client.
However, I assume that log parsing, a la DPS parsing is allowable, as it was in classic. I've started a little .NET project to create a parsing framework for EQ logs. The scope of what it'll achieve isn't strictly laid out (at this point), but is it okay to assume that as long as my only input are log files and that I'm not creating key-presses to the EQ client that this is allowable?
I won't be packet sniffing or reading the client's memory, though I will likely create a few (in-game) macros to dump off the information i require into log files from the client.
For instance, my starter project would produce a map/maps of the zone you're in based on the 'you have entered' text, and /loc would blink that position onto the map.
If deemed allowable, I'd be happy to supply the source / executables to the community once complete.
I understand that SEQ/MQ is prohibited (and rightly so), as these things give an advantage and provide information that is not otherwise exposed through the client.
However, I assume that log parsing, a la DPS parsing is allowable, as it was in classic. I've started a little .NET project to create a parsing framework for EQ logs. The scope of what it'll achieve isn't strictly laid out (at this point), but is it okay to assume that as long as my only input are log files and that I'm not creating key-presses to the EQ client that this is allowable?
I won't be packet sniffing or reading the client's memory, though I will likely create a few (in-game) macros to dump off the information i require into log files from the client.
For instance, my starter project would produce a map/maps of the zone you're in based on the 'you have entered' text, and /loc would blink that position onto the map.
If deemed allowable, I'd be happy to supply the source / executables to the community once complete.