When any unit takes damage or healing from the player, I need to know whether the target is affected by any auras from a list of forbidden auras. I keep track of these auras with SPELL_AURA_APPLIED, SPELL_AURA_REMOVED etc. However when a unit's auras fades due to death, the SPELL_AURA_REMOVED events fires before both the damage and kill events, leading the addon to erroneously think that the damage of the killing blow was not affected by any auras, forbidden or no. Example: (highlighted the events relating to the same unit)
I can think of a few ways to circumvent this, such as waiting to see what the next event related to this unit is before really clear the auras off the unit, but I'm wondering if anyone else has any possibly-brilliant ideas.
I don't recall the specifics, but I had to do something similar to what you're talking about possibly doing with Hermes. My case was simpler, I only had to remember the last relevent combat log event per player. I would use it when processing the next event found for the player, and continuously reset, etc.
I'm a little confused by your snippet, it looks like the only thing that died was an NPC, but your post talks about healing so I'm assuming you're worried about players, and not NPC's.
One possibility is to make special condition for SPELL_AURA_REMOVED events. If it's true that SPELL_AURA_REMOVED events all fire sequentially with nothing else relevent in between, then you can remember for the player that a SPELL_AURA_REMOVED event was caught. For all the following events, if you keep seeing SPELL_AURA_REMOVED without something else like damage, healing, whatever, and it keeps going and going with nothing but SPELL_AURA_REMOVED before you finally see a UNIT_DIED then that might work. It's essentially what I id but I didn't have to worry about repeated occurrences of the same event.
I have no clue what events fire when someone dies. But this might give a clue.
I'm a little confused by your snippet, it looks like the only thing that died was an NPC, but your post talks about healing so I'm assuming you're worried about players, and not NPC's.
damage or healing from the player
:)
Thanks for your input, though. I'll see what I can make of it.
Another problem is I need to be able to tell apart the above mentioned situation, from one where the auras actually fade first, and I then proceed to deliver the killing blow. I'm not sure there's any not-too-hacky way around that, though, but I could live with it.
Just so I understand: if BobTheTank dies from Shadow Word: Pain, SPELL_AURA_REMOVED fires, then UNIT_DIED, in that order? In that case, I would hook UNIT_DIED, and in the event handler, hook UNIT_AURA, not SPELL_AURA_REMOVED.
[PHP]-- assuming Ace3, but could be done without
function MyAddon:OnEnable()
self:RegisterEvent("COMBAT_LOG_EVENT_UNFILTERED", "CLEU")
end
function MyAddon:CLEU()
if type == "UNIT_DIED" then
MyAddon:RegisterEvent("UNIT_AURA")
end
end
function MyAddon:UNIT_AURA(unit)
-- if not correct unit then return end
-- do stuff here, knowing the unit died first, then buffs and debuffs were removed
end[/PHP]Reference:
I have no clue what events fire when someone dies.
PLAYER_DIED which is not part of CLEU, but that is limited to the player, and UNIT_DIED for anything, mob, NPC, player, party/raid member, etc, which is part of CLEU.
PLAYER_DIED which is not part of CLEU, but that is limited to the player, and UNIT_DIED for anything, mob, NPC, player, party/raid member, etc, which is part of CLEU.
I meant, in the context of his problem, I don't know what all can fire in between a unit/player having died, and the final PLAYER_DIED/UNIT_DIED event/cleu happening. Clearly, we know SPELL_AURA_REMOVED does but not sure what else is in there that could throw off his code.
Just so I understand: if BobTheTank dies from Shadow Word: Pain, SPELL_AURA_REMOVED fires, then UNIT_DIED, in that order? In that case, I would hook UNIT_DIED, and in the event handler, hook UNIT_AURA, not SPELL_AURA_REMOVED.
Those events triggers in that order, yes, but as you can see there are a few events triggering in between. The killing blow event triggers before UNIT_DIED, for example, but at that point I already need to know whether the target was affected by any forbidden auras. PARTY_KILL triggers before the damage portion (but still after SPELL_AURA_REMOVED), and would be more appropriate for this purpose. I'm also only interested on damage or healing dealt by the player. Thus I cannot use UNIT_AURA as there isn't always an available unit token. (eg DoTs)
Have you tried a flag method? Set a default of false, then when the player affects the target with one of your unwanted spells, set it to true. It should only be true when the sourceGUID is player, destGUID is player's cast target, and the spell is on your list.
Create different flag for REMOVED and hold it for UNIT_DIED.
In UNIT_DIED, check if the first flag is true, along with the second. If both are true, then the unit died with an unwanted buff or debuff. If only the flag for REMOVED changed after an OnUpdate interval of, say, 1 second, then the unit was decursed, and did not die.
You could also create one flag, and make it tri-state.
I ended up deciding to do something similar. Going with the assumptions that PARTY_KILL triggers immediately after SPELL_AURA_REMOVED, and that the damage event with overkill >= 0 is the last damage event to the killed unit. At any SAR, I flag the target as dirty. If the following event related to the target is not SAR nor PK, then the target is clean, otherwise all subsequent damage events are ignored, up until the killing blow event, where the target is clean again. (since it's not gonna receive any more damage, and we don't want to litter the dirty targets-table)
Thanks for all input!
Edit: Silly me, it does have to be tri state, indeed. Otherwise targets will just become clean on the event following PARTY_KILL. So set state 0 for example, on SAR. On PK, if state is 0, set state 1. On any other event, if state is 0, set state nil. On damage, if state is 1, ignore damage.
When any unit takes damage or healing from the player, I need to know whether the target is affected by any auras from a list of forbidden auras. I keep track of these auras with SPELL_AURA_APPLIED, SPELL_AURA_REMOVED etc. However when a unit's auras fades due to death, the SPELL_AURA_REMOVED events fires before both the damage and kill events, leading the addon to erroneously think that the damage of the killing blow was not affected by any auras, forbidden or no. Example: (highlighted the events relating to the same unit)
I can think of a few ways to circumvent this, such as waiting to see what the next event related to this unit is before really clear the auras off the unit, but I'm wondering if anyone else has any possibly-brilliant ideas.
Thanks
I'm a little confused by your snippet, it looks like the only thing that died was an NPC, but your post talks about healing so I'm assuming you're worried about players, and not NPC's.
One possibility is to make special condition for SPELL_AURA_REMOVED events. If it's true that SPELL_AURA_REMOVED events all fire sequentially with nothing else relevent in between, then you can remember for the player that a SPELL_AURA_REMOVED event was caught. For all the following events, if you keep seeing SPELL_AURA_REMOVED without something else like damage, healing, whatever, and it keeps going and going with nothing but SPELL_AURA_REMOVED before you finally see a UNIT_DIED then that might work. It's essentially what I id but I didn't have to worry about repeated occurrences of the same event.
I have no clue what events fire when someone dies. But this might give a clue.
:)
Thanks for your input, though. I'll see what I can make of it.
Another problem is I need to be able to tell apart the above mentioned situation, from one where the auras actually fade first, and I then proceed to deliver the killing blow. I'm not sure there's any not-too-hacky way around that, though, but I could live with it.
-
View User Profile
-
View Posts
-
Send Message
Forum Moderator[PHP]-- assuming Ace3, but could be done without
function MyAddon:OnEnable()
self:RegisterEvent("COMBAT_LOG_EVENT_UNFILTERED", "CLEU")
end
function MyAddon:CLEU()
if type == "UNIT_DIED" then
MyAddon:RegisterEvent("UNIT_AURA")
end
end
function MyAddon:UNIT_AURA(unit)
-- if not correct unit then return end
-- do stuff here, knowing the unit died first, then buffs and debuffs were removed
end[/PHP]Reference:
-
View User Profile
-
View Posts
-
Send Message
Forum Moderator-
View User Profile
-
View Posts
-
Send Message
Forum ModeratorI meant, in the context of his problem, I don't know what all can fire in between a unit/player having died, and the final PLAYER_DIED/UNIT_DIED event/cleu happening. Clearly, we know SPELL_AURA_REMOVED does but not sure what else is in there that could throw off his code.
Those events triggers in that order, yes, but as you can see there are a few events triggering in between. The killing blow event triggers before UNIT_DIED, for example, but at that point I already need to know whether the target was affected by any forbidden auras. PARTY_KILL triggers before the damage portion (but still after SPELL_AURA_REMOVED), and would be more appropriate for this purpose. I'm also only interested on damage or healing dealt by the player. Thus I cannot use UNIT_AURA as there isn't always an available unit token. (eg DoTs)
-
View User Profile
-
View Posts
-
Send Message
Forum ModeratorCreate different flag for REMOVED and hold it for UNIT_DIED.
In UNIT_DIED, check if the first flag is true, along with the second. If both are true, then the unit died with an unwanted buff or debuff. If only the flag for REMOVED changed after an OnUpdate interval of, say, 1 second, then the unit was decursed, and did not die.
You could also create one flag, and make it tri-state.
Thanks for all input!
Edit: Silly me, it does have to be tri state, indeed. Otherwise targets will just become clean on the event following PARTY_KILL. So set state 0 for example, on SAR. On PK, if state is 0, set state 1. On any other event, if state is 0, set state nil. On damage, if state is 1, ignore damage.