Slouken request: Combat parsing

#0 - July 13, 2007, 6:39 a.m.
Blizzard Post
Hello friends (and more specifically Slouken), this is ckknight.

I'm the author of Parser-3.0, which is a combat log parser library, and as far as current combat log parsing is concerned, it's extremely painful, expensive, and ambiguous.

e.g. event "CHAT_MSG_COMBAT_CREATURE_VS_CREATURE_HITS" with globalstring _G.COMBATHITOTHEROTHER ("%s hits %s for %d.").

What currently happens is that you register "CHAT_MSG_COMBAT_CREATURE_VS_CREATURE_HITS" and arg1 = "Prairie Wolf hits Ckknight for 8.". You have no real knowledge about what globalstring was fired or with what arguments unles you have a complex parsing mechanism.

You must first turn the format string ("%s hits %s for %d.") into a search string ("^(..-) hits (..-) for (%d+)%."), and then check it against the argument. Another complexity is that it might be a different globalstring that is more specific, e.g. _G.COMBATHITOTHERSELF ("%s hits You for %d."). [also, is it actually the player or just some joker named "You"?]

This is an extremely complex mechanism and I believe I have an elegant solution for everybody:

you register event "CHAT_MSG_COMBAT_CREATURE_VS_CREATURE_HITS", and its return arguments are "Prairie Wolf hits Ckknight for 8.", "COMBATHITOTHEROTHER", "Prairie Wolf", "Ckknight", 8.

This is quite nice since string.format(_G["COMBATHITOTHEROTHER"], "Prairie Wolf", "Ckknight", 8) == "Prairie Wolf hits Ckknight for 8."

No parsing involved whatsoever, and any addons that use it can check for the specific globalstring and already know what arguments to check for, without need for localization-specific deformatting.

-------------------------------------

There are also modifiers that go along with this, e.g. (absorb 8), (resist 10), etc. and I figure the best way to handle this would be "Prairie Wolf hits Ckknight for 8 (5 absorbed) (2 resisted)", "COMBATHITOTHEROTHER", "Prairie Wolf", "Ckknight", 8, "ABSORB", 5, "RESIST", 2.

The general idea is that nearly no parsing should happen and things should remain as non-localized as possible. This data is surely already available to the client already, so adding the extra arguments should be minimal effort.

-------------------------------------

More confusing situations arise especially for French and German when some strings are incredibly ambiguous.

There are some ways to get around that, e.g. what SWFixLogStrings does, but that breaks all mods that do parsing before it, which is suboptimal.

Please Slouken, consider this, seeing as it is merely an addition and not a revamp, the effort required will be minimal and the gains received will be enormous.
#3 - July 13, 2007, 5:07 p.m.
Blizzard Post
[teaser]We have some great changes coming down the pike for you guys in 2.4, but I can't say anything else about it yet. *grin* [/teaser]