PTS 2.7.2 - Effects longer than 30 sec now act same as less than 30 sec.

[ZOS_ChipHilseberg]

Originally Posted by sirinsidiator Does that mean the event filters will work on it?

That is correct.

[Phinix]

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

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

numAuras = GetNumBuffs('reticleover') + ActiveFakes()

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]

Originally Posted by ZOS_ChipHilseberg 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]

Originally Posted by Phinix @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]

Originally Posted by ZOS_ChipHilseberg 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]

Originally Posted by Phinix 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.

Originally Posted by Phinix 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]

@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]

Originally Posted by Phinix @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:

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]

Originally Posted by decay2 Since Homestead, GetUnitBuffInfo returns a boolean castByPlayer at the end: 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]

Originally Posted by Phinix 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]

Originally Posted by decay2 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]

Originally Posted by Phinix 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]

From the patch notes:

Addons can now determine if an effect is cast by the local player or by someone else.

[Phinix]

Possible EVENT_EFFECT_CHANGED castByPlayer values (thanks Ayantir):

COMBAT_UNIT_TYPE_NONE			= 0
COMBAT_UNIT_TYPE_OTHER			= 5
COMBAT_UNIT_TYPE_PLAYER			= 1
COMBAT_UNIT_TYPE_PLAYER_PET		= 2
COMBAT_UNIT_TYPE_TARGET_DUMMY		= 4

Also it is the 17 (and last) return field.

[ArtOfShred]

Originally Posted by Phinix Possible EVENT_EFFECT_CHANGED castByPlayer values (thanks Ayantir): COMBAT_UNIT_TYPE_NONE = 0 COMBAT_UNIT_TYPE_OTHER = 5 COMBAT_UNIT_TYPE_PLAYER = 1 COMBAT_UNIT_TYPE_PLAYER_PET = 2 COMBAT_UNIT_TYPE_TARGET_DUMMY = 4 Also it is the 17 (and last) return field.

Oooh thanks for posting this over here, gonna need it later :-D

[Yngvarr]

Originally Posted by Phinix Possible EVENT_EFFECT_CHANGED castByPlayer values (thanks Ayantir): COMBAT_UNIT_TYPE_NONE = 0 COMBAT_UNIT_TYPE_OTHER = 5 COMBAT_UNIT_TYPE_PLAYER = 1 COMBAT_UNIT_TYPE_PLAYER_PET = 2 COMBAT_UNIT_TYPE_TARGET_DUMMY = 4 Also it is the 17 (and last) return field.

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.

Incase it helps someone

[Ayantir]

COMBAT_UNIT_TYPE_GROUP 3

so it should be this