Combat_Log_Event simple explanation please..
 

I have no clue what the new combat log syntax is or anything. None of it makes sense.

Can someone please provide a working example of the new combat log format for this event so I can understand what the format is supposed to be:

if (event == "UNIT_AURA" and arg1 == "pet") then

I second that! So far I resent the update, as I usually do. The new combat log is nothing special. All it did was over-complicate simple tasks as far as I can tell. I'm having a similar problem trying to identify killing blows with the new patch. Hopefully we'll both get what we need!...=)

Thaenin

I'm sure you've seen this:

http://www.wowwiki.com/COMBAT_LOG_EVENT_Details

Which is pretty un-user friendly, but has a lot of info. here are some quick tips:

1. The only event you care about or want to register is "COMBAT_LOG_EVENT_UNFILTERED"
2. The second argument of the above event is also called "event" but it is not an event, it's a string representing the sort of thing that happened to trigger "COMBAT_LOG_EVENT_UNFILTERED"
3. There are 8 base arguments from "COMBAT_LOG_EVENT_UNFILTERED", they are: timestamp, event, sourceGUID, sourceName, sourceFlags, destGUID, destName, destFlags
4. If you just want to get the same functionality as the 2.3 log, all you care about are "event", and the two "name"s
5. For the most part you can ignore "flags," if you aren't used to them. They're there to help filter things faster, but you can still use "name" to do that yourself.
6. GUIDs are useful if you need to seperate entities that have the same name, for example:
if destGUID == UnitGUID("target") then --the thing that got hit *is* my target, and I know this even if there are other things with the same name
7. Each possible value of "event" (arg2) has its own set of additional arguments that get passed *after* arg8 (destFlags)
7-a. Up to 3 of those are determined by the first word of "event", for example "COMBAT_LOG_EVENT_UNFILTERED" events which have an arg2 that starts with "SPELL_", have an arg9 "spellId"
7-b. Up to 8 more arguments *after* the 3 from the last point are determined by the remaining words of "event", for example if arg2 contains "_DAMAGE" then the event has an arg12 of "amount"


Hopefully that helps in decoding the wowwiki stuff somewhat better. :)

is this anywhere close to being right?

should be like:

base params go up to 8, then the prefix params go up to (at most) 11, then the suffix params start, wherever the prefix params left off

Using the info you gave me:
I was able to return the following info for the Pet Feeding:

timestamp - arg1 == 1207312869.231
event - arg2 == SPELL_PERIODIC_ENERGIZE
srcGUID - arg3 == 0x00000000004B7A6C
srcName - arg4 == PlayerName
srcFlags - arg5 == 1297
destGUID - arg6 == 0xF54035EBC8000028
destName - arg7 == Pet Name
destFlags - arg8 == 4369
spellID - arg9 == 1539
spellName - arg10 == Feed Pet Effect
spellSchool - arg11 == 1 (Physical)
PowerAmount?? - arg12 == 0
powerType - arg 13 == 4 (Pet Happiness)

If Arg 12 does indeed indicate powertype then string finding is obsolete as you can just compare arg 12 with the value that corresponds to the original string. Lemme know if there's anything more you can add to this. I think my understanding is along the right track though.

Now I can understand, using wowwiki information how the filters and stuff works to get this info. What I don't quite understand yet is how to do a string compare. In the old event system we could just use arg1 as the string compare but with all of these values, where is the actual string stored:

Code:

---

string.find(argX, "(.+) gains ## Happiness()");

---

In GlobalString.lua:

SPELLHAPPINESSDRAINOTHER = "%s's %s loses %d happiness.";
SPELLHAPPINESSDRAINSELF = "Your %s loses %d happiness.";
POWERGAINOTHEROTHER = "%s gains %d %s from %s's %s.";

Etc... :)

there isn't one, the default combat log creates its messages from the various parameters it gets now (using globalstring.lua), instead of just outputting a string that the server created for it.

Thank you for helping me understand the log enough to get this working. Once I was able to get the specific arguments, it made deciphering the event a lot simpler. Let me know if you'd do anything differently.

This is what I ended up with and it seems to be working fine: