Made a post earlier over on the ESO forums about this, though it might be a bit irrelevant at this point: https://forums.elderscrollsonline.co...log-pts#latest

Am I to understand that its now the future intention for us not to be able to see hostile player buffs and debuffs any longer? But once again we'll be able to see passive PVE mob buffs like "Scary Immunities" and buffs on players?

Also I have an inquiry about detecting events:
For developing LUI I've been making a comprehensive spreadsheet of all abilities (https://docs.google.com/spreadsheets...it?usp=sharing - it's a bit hard to read atm because I'm using it to keep track of my workflow) and how they interact by using Srendarr to detect events going on in the worldspace. Srendarr simply provides a chat printout of any ability usage that occurs and due to API limitations will only show the source/target if the player is one of those.

I use OnCombatEvent currently for LUI to create "fake aura" buffs/debuffs for attacks in game that don't correctly show an active effect - by tracking events sourced from a target onto the player. When an ability is applied and detects a valid source NPC applying it to the player it creates a buff container, and when it is removed it sees no source removing it from the player - destroying the container, effectively allowing me to create accurate fake buffs that apply and fall off correctly when removed or cleansed.

As it stands I could easily make an addon that notifies me of a player using any ability targeting me via OnCombatEvent as well - or to simply alert me to stealthed nearby players.

I understand you are likely going to limit this functionality - and if so would you potentially be able to limit that functionality to only stealthed targets or only inside Cyrodiil. I'd appreciate still being able to see events that NPC's are performing to other targets.

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.

I've been thinking, Chip. Will it be possible to exclude all these combat events, but ACTION_RESULT_KILLING_BLOW and ACTION_RESULT_DIED_XP specifically?

if you still keep sending these 2, with blank sourceName and sourceId (like it is right now on live), but with targetName and abilityId only (no need for targetId) i'll still be able to provide Kill Feed without compromising privacy of these players in a fashion it happens right now.

I'll just need these 2 (ACTION_RESULT_KILLING_BLOW, ACTION_RESULT_DIED_XP) and targetName and abilityId for anybody dying in pvp.

One of the reasons i'm asking for this is that if you stop sending them all, there will be no way to know if the guy you're attacking died unless your attack was the killing blow.

Could you discuss it with the design team?

Cheers.

PS. Btw, kills from Ballista are reported as Ballista's kills instead of the player's kills. Could you take a look at this as well?:)

Edit: Or even with sourceName as well, without sourceId:)

We will allow those results through in PvP as they had been in the past.

Thanks Chip! But since now i won't be able to connect targetIds in those events to the players' names as i did before, this essentially means that i'll be able to get Kill Feed information only for those who i attacked or who healed/buffed me.

I'm making sure i understand the design choice correctly and that the design is against giving everybody's names even in these events only.

Ps. Even if this is all the design agrees to provide, it's still a lot and thank you, guys, for this.

Very nice thread. I like having a little insight into those issues.

Having a way to determine UnitId's before going into combat (for the player and groupmembers) would help me a little when setting up my data for Combat Metrics. Something like a GetUnitId(unittag). Just not sure how this goes with the changes you are doing right now in PVP.

So it seems now that buff tracking addons pick up EVERY buff that is under 30 sec. Im seeing every other players curses, endless hails, blockades, everything....

To keep Srendarr functional ill have to add like 50 buffs to blacklist to stop them from showing (because they are not mine).

I believe we're all working on our respective addons to fix the problems! I'll already have a solution for LUI but I need to improve how effective it is from a performance standpoint.

I recommend turning off debuff tracking for now. I'm anyway working on a library (still needs a few weeks, I guess) which could really help in this situation.

but it would be good to know it this change is intended as it is right now.

If it is intended to stay it would be really helpful if there was an indication who caused a particular effect in EVENT_EFFECT_CHANGED. It would be enough to know if the player caused it or not. (It is done like this in GetUnitBuffInfo(...) however this one requires a unittag which is not always available)

Post going on the official forums from Gina :

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

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

For now I use the following replacement:


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.

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.

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.

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

\o/ excellent!

Does that mean the event filters will work on it?