Btw, why would you register on wow-event types instead of info.type? I think most users would just know if something happened, like someone gained or lost an aura, but he doesn't care about what the original event type was.
And addListener takes 3 parameters, type, name and function.
An enemy casting bar mod in WoW 1.12 would register Cast (for bla Casts bla on target / bla Begins to Cast bla on target) and Interrupt (bla Interrupts target's Spell of Doom).
Optimizing ParserLib: I thought the patterns are rearranged based on they way you have to process them, in order to avoid X hits you for Y Fire damage to be caught by "%d hits You for %d", not on hit-rate.
Apparently, some people were using MCL/MCP for a long, long time after 'discontinuation' (read: it just works, and I got bored with Nurfed CL :P), so I'm going to do a cleanup and review on those two mods and rerelease them. It's nice to see how small a fully featured combatlog can be with just a parser and no other externals, the layout code is 13k and add another 5 for slash handlers.
fyi, parserlib works in tbc. Some strings are missing, but that's it.
As sctd works fine for most stuff, yea.
But as parsing events is one of the most CPU heavy function, it should be done in a better way than loop through table and try them.
Statistical and syntactical analysis should improve efficientcy:
- What's the chance that CHAT_MSG_COMBAT_PARTY_HITS matches COMBATHITOTHEROTHER ("%s hits %s for %d."). Use this data to reorder matching attempts.
- What are the keywords in a pattern? Are they unique for an event?
A log parser should minimize the amout of
- String.find's, without plain=true parameter.
- String.find's with plain=true. It's 10x faster than patterns, but still very slow compared to normal arithmetic.
(I'm off to porting any casting bar to WoW 2.0... default ui bar is bugged, it doesn't adjust time when you get hit while casting :/)
I would if I had the time for it. While ParserLib / MCombatParser does a decent job, I think it's way better to build search tables dynamically, which saves us from updating the lists (80%+ of the code) everytime something changes. But as GlobalStrings is quite large, we'll need a pretty efficient algorithm to searth through it, O(n) or better preferred.