damage meter issue related to Pet OwnerName and OwnerID
 

Hi Everyone !

I'm working on porting an old addon back from Cata. so far everything works fine except (it seems) Pet. (it's a kind of DPS meter)

The way used in there to get the ownername,ownerID and petID is a bit scriptic for me (i'm not a huge LUA expert, i'm just digging info and fixing with the resources i find)

Basically the issue is that (it seems) each time a hunter uses stampede, or any other classes that seem to have some weird pets, the addon floods me with errors :

Below is the part of code that it is complaining about

Any idea or help for fixing would be very appreciated as i'm totally facing a wall on that part currently. i've been doing some digging on the web, wowiki api sites etc etc.. i could find that all these bit.band are searching for the HEX values that seem to be attributed to an npc,a player,enemi etc etc.. so my "guess" is that some IDs or the way they are reported have changed and its not just giving a number like it is expecting but a string....

Many thanks for your time and help!

BuG

The problem is likely caused by the order of the arguments for COMBAT_LOG_EVENT_UNFILTERED being changed.

The error is from the variable 'flag' being a string instead of a number, which probably means it's holding the unit's name or something instead of its flags.

Can you show us what the variables are being assigned to for the COMBAT_LOG_EVENT_UNFILTERED event?

Although the fact that you say everything else is working fine would seem to indicate that it's something else..

Hi and thank you for your answer.

sorry for such a nebbish question but, what/where exactly should i find what you would like to see ? i do register the combat log unfiltered in the add-on, but i'm not familiar with such thing. is that printed somewhere in the cache/variables ?

i tried a suggestion from someone to print what it is showing :

but that was just a bad idea and more or less crashed everything (there are too many lua errors etc etc)

Although, here is a more complete error that happens (just realized the original one was missing a few lines)

and yeah maybe it is somewhere else but it's always pointing to the same place all the time, and it "seem" to happen when units with pets are around. but sometime, i'll be spamming spells around for 10mins without any errors popping and another moment, after 5sec of being in combat it appears…


Edit 2 : the easiest way i found to reproduce it is have a lock with me and wait for him to have a "proc Imp" this brings the error right away and will keep spamming it every few seconds.

Now i'm "convinced" more and more that it has to do with Guardians and not pet (since pet seem to be coded "okish") as guardians do not have names or id or something the add-on just get lost

Okay, even though that function is where the error is being thrown, it isn't the source of the problem.

The problem is being caused by the fact that the function is being fed a string instead of the flags it's expecting.

The stack trace shows you the line numbers of the function calls leading up to the error. Even though line 411 is the one that it's actually failing on, that function is being called from another line (2776 in your last post).

The function _RelevantMember is being called with something other than the flags. You need to identify what it's being called with. Find where _RelevantMember is being called, look at what the variable it's being called with is named, then go back through the script until you find where that variable is assigned. That is the source of the problem.

If you can't do that, post the entire script somewhere.

Hi Semiar,

this is very useful and your help is very appreciated.

RelevantMember is called (as you said) further down the script in the following function :

arg4, if i'm correct relates to the sourceGUID. which, if i'm correct guardians do not have and would correlate to the behavior that i'm seeing :

as soon as a Lock gets his Imp procs the error pops.

for example the part around line 2776 :

sourceGUID is already defined, arg4 is referring to the fourth argument after "targetRaidFlag" in the parameters that the CLEU event contains. What arg4 happens to be depends on the subEvent.

The error isn't being caused by an incorrect value for flag, it's being caused by this little line inside of _RelevantPet..

edit: It's expecting guid to be a number, not a string. I don't know if this was changed at some point, but it's certainly not a number today.

Try changing it to or tonumber(strsub(guid or '00000', 5, 5) or 0, 16) % 8 == 4 which is basically pulling the fifth character out of the guid (which identifies the unit type) and checks if it's 4 (which identifies it as a pet).

I was actually wondering exactly what is this part of code doing exactly, i could find the correspondences of all the HEX part on the web like

http://wowdiff.googlecode.com/svn-hi.../Constants.lua

but the last bit you mentioned, i couldn't find it anywhere… do you know what this is doing ?

i'm gonna try first to see what happens when i set it to FLAG instead of GUID and see if anything happens..

Check my edit, I realized what it's supposed to be doing after I wrote it.

yep just checked it and understand.. however that code you gave gives an error :


it doesn't seem to like that

strsub is a valid function implemented in the client. It shouldn't be throwing an error in-game. It's not a native lua function so it might cause problems if you're trying to run it outside of the game.

Just change it to string.sub.

yeah, i have that strsub in other add ons just ok..and i use that in game.. no idea but str.sub works ok.. i'm gonna try and see what happens… thanks so much for your help so far !


Edit :

doh ! almost.. (error popped up when hunter used stampede)

but from my few readings, i think guardians actually don't have a proper ID or at least they don't have a name (saw that in TinyDPS for example :

that could explain why it has a "nil value" ?

You need to add something like if not guid or guid == '' then return end to the top of the _RelevantPet function to just exit if there's no guid.

The error is being caused by the guid being an empty string which is one of the only things I didn't make an exception for in my example.

Actually, hang on I'll write something better because that will make it lose some of its functionality.

wouldn't it cause the function to not work at all if we completely exit when there is no GUID ?

wouldn't setting something like NONE (as the example above) shown would work better ?

Try changing the if statement to this..

A unit can not have a name, but it should never be missing a GUID. If the GUID field is missing, there's no way to track the unit. In other words even if there were a unit without a GUID, it wouldn't be possible to identify who it belonged to.

I know for a fact stampeded pets all have GUIDs and even guardians summoned by trinkets such as voodoo gnomes do as well.

Ok, good to know, not sure exactly what i did read before (i guess i'm confused between name/guid etc)

so far, with your latest tweak, it seem to be fully working, and dos tracked by hunter + lock is accurate (compared to skada/recount) i'll give it further try, but thank you so much for your work and your help, i would have never figured that out!

i'll continue testing but so far that issue seem to be solved! thanks again!

Hi Semlar.

So far so good, the add-on works errorless.. however it is not recording all pet/guardians damage all the time. it will randomly record or not. resulting in totally off values.

i wonder if you might have an idea ?

thanks

cheers

BuG

Is there anything that the missing pets have in common?

i'm investigating deeper, been doing billions of dog and lfr etc. running both recount/skada + the add-on all in parallel. damages are spot on up to the last digit.

i think the issue is coming from the default updating time of 5sec for the data. using 1sec (which is what recount/skada are using) makes it work fine.

i guess the delay is way too big for the amount of data and creates gab + sometimes will just lose some stuff if you are not actively fighting and just let a pet do things. (i.e. : cast a dot on dummy and nothing else, it won't show anything in the add-on since you get out of combat before the 5sec starts)

Either the way it was "storing" the data before needs some update or there is maybe a way to make it "buffer" somehow but well that's way out of my knowledge...if 1sec isn't make memory usage + cpu go nuts, i guess it should be fine. feel free if you have an idea tho ^^


thanks for following up with me, very appreciated! i'll keep you up to date.

If the caster is not in combat, it stops recording. for example, i died on on Sha and it will stop recording anything.

couldn't figure where this is.

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.

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

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 ?

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

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.

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

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.

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)

Are imps not triggering either print?

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

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.

+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 :

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

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 :

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)

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.

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 :D).

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.

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 :(

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.

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 :

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 :

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

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.