damage meter issue related to Pet OwnerName and OwnerID

[semlar]

The function C_EndCombat_OnUpdate is there to periodically check if anyone else is in combat after you've left it, so presumably it shouldn't stop until everyone has left combat.

[zbugrkx]

yeah thats also what i assumed. i guess it must be due to the specificness of this world change on Sha of Fear… maybe

need to try that in another area/raid see if i can reproduce it

[zbugrkx]

Originally Posted by semlar Is there anything that the missing pets have in common?

So, after a lot of testing with several classes.

the issue is with warlocks, demo specs (at least) where there imps which have their own random name get considered as a player and not added to the player's damage :



could it have anything to do with the GUID sorting we fixed ?

[zbugrkx]

I have been testing it further with several warlocks and so far i could only have that happen with warlocks.

Their Imps just appear as an additionnal player which now makes sense why the damage is always a bit off by a few k.

if you get time and have any idea let me know, as i'm totally clueless on that one.

i think, around line 388, we add the pet to owner, where we check the petid, and around that line 411 we check the relevantpet. i'm just guessing that it could be around that area of the code...

cheers

[semlar]

Line 2934 of what you linked me is where it attributes guardians like the warlock imps to a player through the SPELL_SUMMON event.

You might try adding some prints around there to see if it's detecting them properly.

For example print('RelevantMember', sourceName, targetName, ...) after if _RelevantMember(sourceFlag) and print('Else', sourceName, targetName, ...) after the "else" to figure out which one, if any, are firing.

[zbugrkx]

Originally Posted by semlar Line 2934 of what you linked me is where it attributes guardians like the warlock imps to a player through the SPELL_SUMMON event. You might try adding some prints around there to see if it's detecting them properly. For example print('RelevantMember', sourceName, targetName, ...) after if _RelevantMember(sourceFlag) and print('Else', sourceName, targetName, ...) after the "else" to figure out which one, if any, are firing.

Ok thanks, going to try that on a lock and see what happens. thanks i'll keep you informed.

[zbugrkx]

well, I'm getting some printouts, so the function is defo firing :


Else Yukin-Aggra(Português) Greater Fire Elemental 117663 Fire Elemental Totem 4
Else Yukin-Aggra(Português) Fire Elemental Totem 2894 Fire Elemental Totem 4
Else Brokencyde-Twilight'sHammer Past Self 108978 Alter Time 64

[zbugrkx]

i'm wondering why is there this line about the FIRE ELEMENTAL thing… could be that adding all guardians there could help. but the imps have some random names.

trying to get a dummy up in an area with no one else so i can have only lock logs to compare.

[zbugrkx]

Ok i "got it".

Pet summoned by a lock using :

http://www.wowhead.com/spell=115578 (Grimoire of Supremacy) is a "Minion" and not a pet or guardian.

The add-on just do not consider it at all being from the caster/owner which is why (seeing on the previous screenshot) it is listed as an additional damage source. (the "proc" imps which are guardians do show up)

[semlar]

Are imps not triggering either print?

[zbugrkx]

the proc imps are triggering it, the summoned minion one not

[semlar]

Alright, well you've forced me to bring my warlock out of retirement for this.

This is the pet summoned by Grimoire of Supremacy and it's treated exactly the same as a normal warlock pet, it can accessed through the unitID "Player-Pet" and it causes a SPELL_SUMMON event so there's no reason why it shouldn't be detectable.

Also you can just head into an instance like RFC when you want to monitor events in peace.

[zbugrkx]

+1 here, got my 2nd account back up to get my lock out of the graveyard.

well, the imp is detected, but as a separate damage dealer. when checking the source of damage taken by mob X you get the player + the imp. where the total of both equals what another meter/wol shows.

i am going to retest in a quiet zone as suggested to make sure 100% that it's not firing up on the print. i'll get the proc imp out and only have him.

Looking at your screenshot, i can see that COMBAT_LOG_EVENT_UNFILTERED has 14 arguments.

around line 2636 there is the parser function :

local function _LogParser(timeStamp, subEvent, hideCaster, sourceGUID, sourceName, sourceFlag, sourceRaidFlag, targetGUID, targetName, targetFlag, targetRaidFlag, ...)

- checking about this, i'm actually wondering, by reading the wowapi web site, it's listed this way :

timestamp 	event 	hideCaster 	sourceGUID 	sourceName 	sourceFlags 	sourceRaidFlags 	destGUID 	destName 	destFlags 	destRaidFlags 	spellId 	spellName 	spellSchool 	missType 	isOffHand 	amountMissed

can that actually be the "start" of an issue. as it seem the arguments have been moved around (why can we actually use sourceFlag instead of sourceFlags ?)

with also these :

local arg1, arg2, arg3, arg4, arg5, arg6, arg7, arg8, arg9, arg10, arg11, arg12 = ...

and well actually starting from that up to line 2934 or so.

there is also around line 2925 the "Fire Elemental Totem" that forces a check of it's sourceGUID and add it to the owner, could be that it's needed for the Imps too. (but seems unlikely as the way this totem works is different afaik)

[Phanx]

COMBAT_LOG_EVENT_UNFILTERED has a variable number of arguments. It always has at least 11 arguments, and then has anywhere from 0 to 12 additional arguments for the specific combat event being described. There is nothing wrong with your argument naming or ordering.

You should look at how other damage meters (for example, Recount) handle pets. While I haven't ever done anything of this sort myself, I believe you're going to want to for the SPELL_SUMMON combat event, and maintain a table that maps each pet's GUID to its owner's GUID, and later use that to determine whether a GUID belongs to a pet or not.

[zbugrkx]

Hi Phanx and thank you for your feedback.

Pets are almost all being handled correctly. i've been scouting a lot recount/skada like you said to come to the current point of what the addon does (it was even more broken before ).

i've just came accross an old thread :

http://www.wowace.com/addons/skada/t...-pets-of-pets/

and, i think this is a similar behavior i'm facing. where some specific pets are not considered as a straight pet but more a summoned pet of pet or something like that. hence why they appear as additional damage dealers and not being from the owner.

i can't test anything right now as i'm at work. but i will try to verify with several classes and see which pets are being tracked separately, if that's the case and i can see a kind of pattern on them, then they must have something in common compared to others which might help.

[zbugrkx]

Ok, so i've spent a good hour trying with a DK/LOCK/MAGE//HUNTER

The only Issue is appearing with Locks and hunters

What i observed :

- The print thingy only occurs when you summon a pet in combat :
- prints for all classes (even hunter/lock)

- Hunter's pet will not always be under the owners. i couldn't find any pattern of that behavior, but like 1 time out of 5+ the pet would appear as another unit, all the other time it was listed as the hunter's damage.

EDIT : actually, after like 20 tries, i had the demo pet also appear under my damage….

so in the end, 90-99% of the time, a lock pet just won't show up under the owner's. a hunter pet more likely but can also bug out.

i'm really lost

[semlar]

As far as I can tell, it's only registering the COMBAT_LOG_EVENT_UNFILTERED event when you enter combat, which means unless you were in combat when the pet was summoned the addon isn't going to be able to attribute it to a player.

I would just comment out _G.Chronicle:UnregisterEvent("COMBAT_LOG_EVENT_UNFILTERED") and add Chronicle:RegisterEvent("COMBAT_LOG_EVENT_UNFILTERED") right outside of the _EndCombat() function and see if that fixes it and if it does then it needs to be redesigned a little bit.

[zbugrkx]

Thanks for that feedback and you are once again totally right. no idea why i have been searching so much about a pet/issue.. it was actually back to the 2nd "issue" i had back then (when i had to shorten the refresh time) : checking the combat status

basically : if i enter combat first, pets are shown fine. if pets / owner are already in combat and i enter after them, they show as additional damage dealers.

so, i would need as you hint to change the way the add-on "gets into combat" a bit like recount does, but i have been reading recount a lot tonight and i can't figure out how they do it.

i have been thinking at having a function like :

local function checkCombat()
  if UnitAffectingCombat("player") or UnitAffectingCombat("pet") then
    ch_incombat = true
    return
  end
  for i = 1, GetNumGroupMembers() do
    if IsInRaid() then
      if UnitAffectingCombat(format("raid%i", i)) or UnitAffectingCombat(format("raidpet%i", i)) then
        ch_incombat = true
        return
      end
    else
      if UnitAffectingCombat(format("party%i", i)) or UnitAffectingCombat(format("partypet%i", i)) then
        ch_incombat = true
        return
      end
    end
  end
  ch_incombat = false
end

so that function check if anyone in my party is in combat and if so, makes ch_incombat = true

now, where i'm clueless is, great i have such nice thing (it looks good on paper) but what the hell can i do with that ?. my idea behind is just to force the add-on to enter in combat if anyone in my party/raid is already in combat and starts recording and not just myself.

i also found that the current _StartCombat gets called around line 3229 with :

elseif event == "PLAYER_REGEN_DISABLED" then
			_StartCombat()

i thought that maybe i need to "enrich" this section or would it be the _StartCombat function that needs "rewriting" somehow ?

[zbugrkx]

So, i updated the C_EndCombat_OnUpdate function to add pets. at least this seem to work ok once i'm in combat. until the pet stops attacking the meter keeps running.

i'm still open for suggestions for having the meter enter combat as soon as anyone in my party/raid enters combat (i'm convince that it will fix the pet issues). i tried all combination that i could think of (with limited knowledge) but it doesn't seem to make a difference.