No, I am not saying Ace events can replace ParserLib. I am saying that it can take alot of the work out of it. It is still really a useful lib because it does one thing extremely well and other Ace addons would benefit from it.
The chat flags, the user may want to grab the existing ones or set a new group of events. All I was suggesting there was that if someone wanted to easily grab those settings and register those events/patterns for listening it would be a nice function.
As far as streamlining the pattern matching, I am not as familiar with Lua yet to grasp the FindString construct you created. Using the events would eliminate the if then else construct and only be watching for the specific ones you need.
Parser__Self_Crit_Hit would be an internal event, not registered to other addons, that is used for the internal communication to the same addon.
Its like saying within a win32 application that a click event happened but you dont want to send a message to another application.
Hence, you dont have to create your tree because you already know the pattern and just have to parse the data from the arguments passed in.
So if I have a function called Parse__Self_Crit_Hit(msg) I already know the pattern for it and can disassemble it. Then trigger the real event Parse_Self_Crit_Hit with the arguments "CRIT", Victim, Damage, Absorbed. Absorbed is there for the cases where there is a damage redux like "You Crit Onyxia for 132(50)." It would be null if nothing was absorbed.
You only register the events needed by clients and register the internal ones to parse the patterns. So if a client wanted to know about CHAT_MSG_COMBAT_SELF_HITS specifically Critical Hits, you register CHAT_MSG_COMBAT_SELF_HITS and ONLY the internal evens that you will generate from the original event, say Parser__Hit_Crit_Self_Other. The others might be Parser__Hit_Self_Other, Parser_Damage_Falling_Self, Parser__Damage_Fire_Self and Parser__Damage_Lava_Self. You would then trigger the real Parser events from the internal one and the clients would have to themselves listen for the real ones and only pass them in for registration like
Some type of tracking system like you have for clients is not needed because the addon itself is listening for the event and should handle it. All they need to do is call the inherited func from your Ace_Parser.
Of course this is all based on if the lib can listen for events generated by itself :P
Not that I am an expert or anything, but I was looking into making a combat log parser to do a few things like color coding and maybe a damgemeters type thing.
Just looking at the AceEvent API and the ParserLib code for a while now.
It seems that the AceEvent is really a replacement of ParserLib. Well maybe not a full one, but it seems as though you want to create custom events for parsing combat messages only. Why not just do that?
Just have the ParserLib create custom events for CHAT_MSG_SPELL_XXX and CHAT_MSG_COMBAT_XXX events and trigger the specific events based on the type of message it is.
So for instance
Ace_Parser = AceLibrary("AceAddon 2.0"):new("AceEvent-2.0")
x = self:GetPattern(1,pattern); --1 is the representation for the message, could be a const like PARSERCHATMSGCOMBATSELFHITS = 1 just for clarity
if (x <> nil)
--or i wonder
--you would have to have all the patterns in there to do this though.
I think this just buys you what the pattern it is but then you could change the event fire to be Parser__Self_Hit_Crit to parse the actual arguments internally and the event Parser_Self_Hit_Crit for the client addons.
Lastly, can't you gleen the combat log preferences to see what events the client should or should not parse?