The parser is making progress. Slow but steady. You can see a screenshot of how it looked 2 weeks ago:
The only thing you really see here though is my vision for how the information will be organized and displayed. Much more structured than in Spyle's parser, with the ability to configure multiple "views" of data.
I've been making slow progress recently though, for a couple of reasons. First, I rely on a third party tool to read the chat log from memory. Unfortunately, that tool is actually a UI program by itself, and the parser has to exist as a "plugin". This fucking pisses me off, I hate it, and he's said basically that he has no intention to make a DLL only interface so that people don't have to load his app first. Because of this, I've been spending some time doing some research into how I can get the chat log directly from memory on my own. I have some ideas I'll try pretty soon.
Another reason it was moving slowly at first is that I had the wrong initial idea for implementing the chat log message format parsing engine. At first I was writing actual code for parsing and storing every type of message. Each time I wanted to add support for recognizing a new type of message in the chat log, I had to go and write 100 lines of code. It was really annoying, but I finally came up with a much more general system where I can specify all the rules, formats, and parameters for various chat log messages in an XML file, then I read that XML file. It makes it much more convenient to support new types of messages. Lastly, I've been busy playing the game lol.
I'm still working on it though, and before I implemented that XML parsing of rules/message formats, it actually worked and displayed counters for crit rate, number of hits/misses, accuracy, and a few other counters.
Regarding dual wield and haste, I've been thinking about this and have some ideas. There's no way it will be able to measure perfectly, but I have some ideas for a heuristic (i.e. guessing) algorithm. Pseudocode for the algorithm would be something like this:
Code:
TotalNumberOfSecondsFighting = 0
FightSequenceStartTime = 0
IsCurrentlyFighting = false
Repeat Forever
Whenever PlayerHitsOrMissesEnemy
if (IsCurrentlyFighting == false)
FightSequenceStartTime = Now
ResetFourSecondTimer
IsCurrentlyFighting = true
End Whenever PlayerHitsOrMissesEnemy
Whenever FourSecondTimerFires
TotalNumberOfSecondsFighting = TotalNumberOfSecondsFighting + (Now - FightSequenceStartTime - 4 Seconds)
FightSequenceStartTime = 0
IsCurrentlyFighting = false
End Whenever FourSecondTimerFires
End Repeat Forever
In essence what this does is, when you hit a mob it records you as in "fighting" state. If you don't do anything for more than 4 seconds (e.g. because you're slept, because you're dead, because you disengaged, whatever) it decides that you "stopped" fighting 4 seconds ago. It then adds up the number of seconds that you WERE fighting to a running counter of how long you've been fighting. Note that the line ResetFourSecondTimer means that if a four second timer already exists, it's erased and initialized from scratch to count to 4 seconds. That way if you swing once, then swing again in 3 seconds, it keeps counting. Never stops until there's a 4 second gap.
Instead of reporting a "Haste" stat as a percentage, it will instead report "Swings / Second". by taking (NumMeleeHits + NumMeleeMisses) / TotalNumberOfSecondsFighting. From that, you can get a pretty good guess about Haste from Attack Speed.
This method has a few flas, but nothing is perfect when you're writing a parser such as this. You just have to make a model that's "as close as possible" to the real number. Again this is just an idea that I've been tossing around, if anyone wants to suggest a way to improve it I'm all ears.