What at first glance seemed like it would be a major loss has turned out to be a gain for 90% of modding purposes. Thanks Chip, for taking the time to listen to our concerns and for making the stuff that matters work even better.
Since these changes are still "in the oven" so to speak, I thought it pertinent to revisit a request I posted on the ZOS forums some months back. Specifically, might it be possible to return persistent, unique, non-player unitID information to EVENT_RETICLE_TARGET_CHANGED?
Right now for Srendarr I am using a table built on the fly based on the NAME of the target, to keep track of debuffs not returned by GetUnitBuffInfo().
Starting at line 353 in AuraControl.lua:
Warning: Spoiler
Code:
local function ActiveFakes() -- Check for active fake debuffs
local total = 0
for k,v in pairs(fakeTargetDebuffs) do
currentTime = GetGameTimeMillis() / 1000
if trackTargets[k] ~= nil and trackTargets[k][unitName] ~= nil then
if trackTargets[k][unitName] < currentTime then
trackTargets[k][unitName] = nil -- Clear expired targets from cache
else
total = total + 1
end
end
end
return total
end
if (numAuras > 0) then -- target has auras, scan and send to handler
for k,v in pairs(fakeTargetDebuffs) do -- Reassign still-existing fake debuffs on target
currentTime = GetGameTimeMillis() / 1000
if trackTargets[k] ~= nil and trackTargets[k][unitName] ~= nil then
if trackTargets[k][unitName] > currentTime then
AuraHandler(
false,
GetAbilityName(k),
'reticleover',
currentTime,
trackTargets[k][unitName],
fakeTargetDebuffs[k].icon,
BUFF_EFFECT_TYPE_DEBUFF,
ABILITY_TYPE_NONE,
k
)
end
end
end
...
However this is obviously limited as mobs will frequently be in packs where they all share the same name (Vicious Mudcrab, Crazy Cultist, etc.)
Having a unique identifier that is semi-persistent (phase/shard-specific until death?) would allow proper multi-unit debuff tracking. I could easily enough code a cleanup function based on timestamps, so anything that didn't have any buff info within say a 30sec window would be purged on reticle target change.
Thanks again!
EDIT:
I see that EVENT_EFFECT_CHANGED already has a unitId interger but it always returns nil is that correct? Also EVENT_COMBAT_EVENT seems to return an actual value. Is this actionable? How is persistence determined for example for the unitId returned for the player?
Phinix
02/12/17 08:19 PM
Quote:
Originally Posted by ZOS_ChipHilseberg
(Post 29697)
Ah, I see your point about knowing if the player was the source. I can add a new boolean field to the event: sourceIsPlayer. Between this and checking the duration you should be able to recreate to previous rules which filtered out all effects under 30s duration that didn't come from or target the player.
@ZOS_ChipHilseberg
Hi Chip,
Any chance this will go live with tonight's patch?
ZOS_ChipHilseberg
02/13/17 08:56 AM
Quote:
Originally Posted by Phinix
(Post 29838)
@ZOS_ChipHilseberg
Hi Chip,
Any chance this will go live with tonight's patch?
No, sorry, it wasn't in time for that patch cycle. It should be in the next one though.
Phinix
02/13/17 10:17 AM
Quote:
Originally Posted by ZOS_ChipHilseberg
(Post 29848)
No, sorry, it wasn't in time for that patch cycle. It should be in the next one though.
Well, good to know it's coming soon at least. Gives me time to finish some other features I'm been working on. :)
EDIT: Has this gone live on the current PTS?
Solinur
02/14/17 08:57 AM
Quote:
Originally Posted by Phinix
(Post 29850)
Well, good to know it's coming soon at least. Gives me time to finish some other features I'm been working on. :)
EDIT: Has this gone live on the current PTS?
The PTS is not updated after a patch went live. It will probably remain on 2.7.4 until the next big patch comes.
Quote:
Originally Posted by Phinix
(Post 29722)
EDIT:
I see that EVENT_EFFECT_CHANGED already has a unitId interger but it always returns nil is that correct? Also EVENT_COMBAT_EVENT seems to return an actual value. Is this actionable? How is persistence determined for example for the unitId returned for the player?
unitId returns proper numbers for me. The thing is it returns the id of "target" so it refers to the same entity as unitName and unittag. The new parameter will refer to the source which allows us to seperate effects cast by the group from the ones cast by the player.
Unitids are supposed to be persistent as long as the entity is known to the client. Which for groupmembers should be as long as everyone is in the instance (and doesn't port to another location). For other enemies it should be valid at least as long as they are visible. These are just some guesses of mine but at least should give an idea. The least I can say is that they are persistent during a fight.
Phinix
02/14/17 09:55 PM
@ZOS_ChipHilseberg
Would it be possible to add unitID to the values returned for GetUnitBuffInfo('unit', i), if if not that, then have a new function GetUnitID('unit') that would return this information?
This would allow proper multi-target debuff tracking in Srendarr.
Solinur
02/15/17 06:16 PM
Quote:
Originally Posted by Phinix
(Post 29894)
@ZOS_ChipHilseberg
Would it be possible to add unitID to the values returned for GetUnitBuffInfo('unit', i), if if not that, then have a new function GetUnitID('unit') that would return this information?
This would allow proper multi-target debuff tracking in Srendarr.
Since Homestead, GetUnitBuffInfo returns a boolean castByPlayer at the end:
Lua Code:
GetUnitBuffInfo(string unitTag, number buffIndex)
Returns: string buffName, number timeStarted, number timeEnding, number buffSlot, number stackCount, textureName iconFilename, string buffType, number BuffEffectType effectType, number AbilityType abilityType, number StatusEffectType statusEffectType, number abilityId, boolean canClickOff, boolean castByPlayer
Maybe this helps?
Phinix
02/15/17 11:44 PM
Quote:
Originally Posted by decay2
(Post 29917)
Since Homestead, GetUnitBuffInfo returns a boolean castByPlayer at the end:
Lua Code:
GetUnitBuffInfo(string unitTag, number buffIndex)
Returns: string buffName, number timeStarted, number timeEnding, number buffSlot, number stackCount, textureName iconFilename, string buffType, number BuffEffectType effectType, number AbilityType abilityType, number StatusEffectType statusEffectType, number abilityId, boolean canClickOff, boolean castByPlayer
Maybe this helps?
Not for multi-target debuff tracking, but this does allow coding a "show only my debuffs" type option. :)
To reliably keep track of for example taunts on multiple targets you need the unitID. You can "guess" based on health values but this isn't really that reliable as they can change rapidly.
Solinur
02/18/17 06:57 AM
Quote:
Originally Posted by Phinix
(Post 29922)
Not for multi-target debuff tracking, but this does allow coding a "show only my debuffs" type option. :)
To reliably keep track of for example taunts on multiple targets you need the unitID. You can "guess" based on health values but this isn't really that reliable as they can change rapidly.
Well as I said, the unitid part works fine for me. Untaunted wouldn't work otherwise :)
Phinix
02/18/17 08:43 AM
Quote:
Originally Posted by decay2
(Post 29964)
Well as I said, the unitid part works fine for me. Untaunted wouldn't work otherwise :)
Good catch!
I guess I should say, that it won't work without unitID for buffs/debuffs that aren't returned by GetUnitBuffInfo(). This includes enchant procs like Crusher, certain abilities like Trap Beast, set procs, and I had thought taunts but apparently those do show up.
Still it's a good solution for most cases. Srendarr already uses GetUnitBuffInfo() on EVENT_RETICLE_TARGET_CHANGED to populate the debuff frame. I just had to use the imperfect name tracking method for those cases where as I said, the buff/debuff is one that is not returned by GetUnitBuffInfo().
That is where returning unitID from GetUnitBuffInfo('unit', i) as well, or having a new function GetUnitID('unit'), would be really helpful. Because the name method is imperfect to catch these cases.
Solinur
02/18/17 02:48 PM
Quote:
Originally Posted by Phinix
(Post 29967)
Good catch!
I guess I should say, that it won't work without unitID for buffs/debuffs that aren't returned by GetUnitBuffInfo(). This includes enchant procs like Crusher, certain abilities like Trap Beast, set procs, and I had thought taunts but apparently those do show up.
Still it's a good solution for most cases. Srendarr already uses GetUnitBuffInfo() on EVENT_RETICLE_TARGET_CHANGED to populate the debuff frame. I just had to use the imperfect name tracking method for those cases where as I said, the buff/debuff is one that is not returned by GetUnitBuffInfo().
That is where returning unitID from GetUnitBuffInfo('unit', i) as well, or having a new function GetUnitID('unit'), would be really helpful. Because the name method is imperfect to catch these cases.
Ah now I understand. A workaround to identify units is to look for buffs and their start/end times (that you saved previously). Those times are really precise. I use it to "identify" reticle targets in Untaunted as well (and highlight the corresponding frame)
Sounomi
02/20/17 06:51 AM
From the patch notes:
Quote:
Addons can now determine if an effect is cast by the local player or by someone else.
:banana:
Phinix
02/20/17 09:02 AM
Possible EVENT_EFFECT_CHANGED castByPlayer values (thanks Ayantir):
Not sure where to find this info and if it is already mentioned there but I did a quick test and it seems to work like this:
your own effects return 1 (obviously) but other players return 5 when not grouped with the player and 3 when grouped with the player. I did this with a friend casting wall of elements/liquid lightning in open world.
