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

[Solinur]

Originally Posted by ZOS_ChipHilseberg unitTag == "player" or better yet: self.control:AddFilterForEvent(EVENT_EFFECT_CHANGED, REGISTER_FILTER_UNIT_TAG, "player") EVENT_MANAGER:AddFilterForEvent("Name", EVENT_EFFECT_CHANGED, REGISTER_FILTER_UNIT_TAG, "player")

This would only track buffs/debuffs that are applied on the player but would also exclude buffs or debuffs that the player cast on someone else.

A common use on buff trackers is to get the uptime of your dot's or debuffs and recast them when necessary. The change made this a bit harder

Though I'm considering to use EVENT_COMBAT_EVENT with the results ACTION_RESULT_EFFECT_GAINED, ACTION_RESULT_EFFECT_GAINED_DURATION, ACTION_RESULT_EFFECT_FADED instead to track effects since you have source and target info there.
There are just many dummy events that need to be taken care of

[Anceane]

Post going on the official forums from Gina :

https://forums.elderscrollsonline.co...omment_3774240

[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.

[Solinur]

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.

Sounds brilliant, thanks a lot Chip. Will we see that before Morrowind?

[ZOS_ChipHilseberg]

Originally Posted by decay2 Sounds brilliant, thanks a lot Chip. Will we see that before Morrowind?

Yes. And it will also probably be a sourceType, the same as combat event uses.

[Solinur]

Originally Posted by ZOS_ChipHilseberg Yes. And it will also probably be a sourceType, the same as combat event uses.

Wow that's even better, once again thank you a lot !

[sirinsidiator]

Originally Posted by ZOS_ChipHilseberg Yes. And it will also probably be a sourceType, the same as combat event uses.

Does that mean the event filters will work on it?

[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?

[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.

[ArtOfShred]

\o/ excellent!

[code65536]

I was wondering about the scope of the planned changes to ACTION_RESULT_BEGIN--how narrow or broad will they be?

As an example, Raid Notifier uses this to warn players of an incoming eclipse field in vMoL, and for players whose systems have difficulty rendering the visual effects in a timely manner, these sorts of warnings can be quite invaluable.

[ZOS_ChipHilseberg]

Originally Posted by code65536 I was wondering about the scope of the planned changes to ACTION_RESULT_BEGIN--how narrow or broad will they be? As an example, Raid Notifier uses this to warn players of an incoming eclipse field in vMoL, and for players whose systems have difficulty rendering the visual effects in a timely manner, these sorts of warnings can be quite invaluable.

Thanks for the info. I can try to confine the combat event changes to PvP as well.

[Solinur]

For now I use the following replacement:

em=EVENT_MANAGER
 
em:RegisterForEvent(CMX.name.."custom", EVENT_COMBAT_EVENT, CMX.onCustomCombatEventDmg)
em:AddFilterForEvent(CMX.name.."custom", EVENT_COMBAT_EVENT, REGISTER_FILTER_COMBAT_RESULT , ACTION_RESULT_EFFECT_GAINED_DURATION, REGISTER_FILTER_IS_ERROR, false)
em:RegisterForEvent(CMX.name.."custom2", EVENT_COMBAT_EVENT, CMX.onCustomCombatEventDmg)
em:AddFilterForEvent(CMX.name.."custom2", EVENT_COMBAT_EVENT, REGISTER_FILTER_COMBAT_RESULT , ACTION_RESULT_EFFECT_FADED, REGISTER_FILTER_IS_ERROR, false)
em:RegisterForEvent(CMX.name.."custom3", EVENT_COMBAT_EVENT, CMX.onCustomCombatEventDmg)
em:AddFilterForEvent(CMX.name.."custom3", EVENT_COMBAT_EVENT, REGISTER_FILTER_COMBAT_RESULT , ACTION_RESULT_EFFECT_GAINED, REGISTER_FILTER_IS_ERROR, false)
 
function CMX.onCustomCombatEventDmg(eventCode, result, isError, abilityName, abilityGraphic, abilityActionSlotType, sourceName, sourceType, targetName, targetType, hitValue, powerType, damageType, log, sourceUnitId, targetUnitId, abilityId)
    if (sourceName==nil or sourceName=="") and (targetName==nil or targetName=="") then return end
    if BadAbility[abilityId] or GetAbilityDuration(abilityId)<=1000 then return end
    local changeType = (result==ACTION_RESULT_EFFECT_GAINED_DURATION or result==ACTION_RESULT_EFFECT_GAINED) and EFFECT_RESULT_GAINED or result == ACTION_RESULT_EFFECT_FADED and EFFECT_RESULT_FADED or nil
    local buffType = abilityId==17906 and BUFF_EFFECT_TYPE_DEBUFF or BUFF_EFFECT_TYPE_BUFF
    CMX.onEffectChanged(_, changeType, _, _, _, _, _, _, _, _, buffType, ABILITY_TYPE_BONUS, _, targetName, targetUnitId, abilityId)
end

Here CMX.onEffectChanged is the function that used to take on the Event EVENT_EFFECT_CHANGED
It tracks a bit more (like all dots are shown as a debuff as well) but at least for my usecase it's quite good. For buff trackers there might be issues as some buffs only have "gained" events.

Note that for EVENT_COMBAT_EVENT it is good to use the "player" filter via the AddFilterForEvent function. This is because Combat events have both source and target which means that the event will be fired when at least one of them is the player, which works nicely.

As I wrote before doing the same with EVENT_EFFECT_CHANGED will limit it to buffs/debuffs that are active on the player only.

One Drawback though: As you can see by that bufftype line, you cannot differentiate easily between buffs and debuffs

I'm going to test this for a bit.