Thread Tools Display Modes
01/17/17, 09:40 PM   #21
ArtOfShred
 
ArtOfShred's Avatar
AddOn Author - Click to view addons
Join Date: Jun 2016
Posts: 103
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.

Last edited by ArtOfShred : 01/17/17 at 09:49 PM.
  Reply With Quote
01/18/17, 03:35 PM   #22
code65536
AddOn Author - Click to view addons
Join Date: Mar 2016
Posts: 21
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.
  Reply With Quote
01/19/17, 08:53 AM   #23
ZOS_ChipHilseberg
ZOS Staff!
Premium Member
Yes this person is from ZeniMax!
Join Date: Oct 2014
Posts: 551
Originally Posted by code65536 View Post
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.
  Reply With Quote
01/19/17, 09:50 AM   #24
dorrino
AddOn Author - Click to view addons
Join Date: Mar 2015
Posts: 50
Originally Posted by ZOS_ChipHilseberg View Post
Combat events will also only be sent for abilities that come from you or target you instead of what we do now which is clear out some of the identifying info.
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

Last edited by dorrino : 01/19/17 at 10:11 AM.
  Reply With Quote
01/19/17, 03:27 PM   #25
ZOS_ChipHilseberg
ZOS Staff!
Premium Member
Yes this person is from ZeniMax!
Join Date: Oct 2014
Posts: 551
Originally Posted by dorrino View Post
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?
We will allow those results through in PvP as they had been in the past.
  Reply With Quote
01/19/17, 06:35 PM   #26
dorrino
AddOn Author - Click to view addons
Join Date: Mar 2015
Posts: 50
Originally Posted by ZOS_ChipHilseberg View Post
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.
  Reply With Quote
01/24/17, 08:14 AM   #27
Solinur
AddOn Author - Click to view addons
Join Date: Aug 2014
Posts: 78
Very nice thread. I like having a little insight into those issues.

Originally Posted by ZOS_ChipHilseberg View Post
What would you need the unit id for in this new system?
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.
  Reply With Quote
02/07/17, 04:45 AM   #28
MagiczneTornado
Guest
Posts: n/a
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).
  Reply With Quote
02/07/17, 05:04 AM   #29
ArtOfShred
 
ArtOfShred's Avatar
AddOn Author - Click to view addons
Join Date: Jun 2016
Posts: 103
Originally Posted by MagiczneTornado View Post
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.
  Reply With Quote
02/07/17, 07:06 AM   #30
Solinur
AddOn Author - Click to view addons
Join Date: Aug 2014
Posts: 78
Originally Posted by MagiczneTornado View Post
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 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)
  Reply With Quote
02/07/17, 11:07 AM   #31
Anceane
 
Anceane's Avatar
AddOn Author - Click to view addons
Join Date: Feb 2014
Posts: 306
Post going on the official forums from Gina :

https://forums.elderscrollsonline.co...omment_3774240
  Reply With Quote
02/07/17, 01:32 PM   #32
ZOS_ChipHilseberg
ZOS Staff!
Premium Member
Yes this person is from ZeniMax!
Join Date: Oct 2014
Posts: 551
Originally Posted by decay2 View Post
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)
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")
  Reply With Quote
02/07/17, 02:32 PM   #33
Solinur
AddOn Author - Click to view addons
Join Date: Aug 2014
Posts: 78
Originally Posted by ZOS_ChipHilseberg View Post
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

Last edited by Solinur : 02/07/17 at 05:29 PM.
  Reply With Quote
02/07/17, 04:10 PM   #34
Solinur
AddOn Author - Click to view addons
Join Date: Aug 2014
Posts: 78
For now I use the following replacement:

Lua Code:
  1. em=EVENT_MANAGER
  2.  
  3. em:RegisterForEvent(CMX.name.."custom", EVENT_COMBAT_EVENT, CMX.onCustomCombatEventDmg)
  4. em:AddFilterForEvent(CMX.name.."custom", EVENT_COMBAT_EVENT, REGISTER_FILTER_COMBAT_RESULT , ACTION_RESULT_EFFECT_GAINED_DURATION, REGISTER_FILTER_IS_ERROR, false)
  5. em:RegisterForEvent(CMX.name.."custom2", EVENT_COMBAT_EVENT, CMX.onCustomCombatEventDmg)
  6. em:AddFilterForEvent(CMX.name.."custom2", EVENT_COMBAT_EVENT, REGISTER_FILTER_COMBAT_RESULT , ACTION_RESULT_EFFECT_FADED, REGISTER_FILTER_IS_ERROR, false)
  7. em:RegisterForEvent(CMX.name.."custom3", EVENT_COMBAT_EVENT, CMX.onCustomCombatEventDmg)
  8. em:AddFilterForEvent(CMX.name.."custom3", EVENT_COMBAT_EVENT, REGISTER_FILTER_COMBAT_RESULT , ACTION_RESULT_EFFECT_GAINED, REGISTER_FILTER_IS_ERROR, false)
  9.  
  10. function CMX.onCustomCombatEventDmg(eventCode, result, isError, abilityName, abilityGraphic, abilityActionSlotType, sourceName, sourceType, targetName, targetType, hitValue, powerType, damageType, log, sourceUnitId, targetUnitId, abilityId)
  11.     if (sourceName==nil or sourceName=="") and (targetName==nil or targetName=="") then return end
  12.     if BadAbility[abilityId] or GetAbilityDuration(abilityId)<=1000 then return end
  13.     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
  14.     local buffType = abilityId==17906 and BUFF_EFFECT_TYPE_DEBUFF or BUFF_EFFECT_TYPE_BUFF
  15.     CMX.onEffectChanged(_, changeType, _, _, _, _, _, _, _, _, buffType, ABILITY_TYPE_BONUS, _, targetName, targetUnitId, abilityId)
  16. 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.

Last edited by Solinur : 02/07/17 at 04:46 PM.
  Reply With Quote
02/07/17, 05:10 PM   #35
ZOS_ChipHilseberg
ZOS Staff!
Premium Member
Yes this person is from ZeniMax!
Join Date: Oct 2014
Posts: 551
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.

Last edited by ZOS_ChipHilseberg : 02/07/17 at 05:27 PM.
  Reply With Quote
02/07/17, 05:27 PM   #36
Solinur
AddOn Author - Click to view addons
Join Date: Aug 2014
Posts: 78
Originally Posted by ZOS_ChipHilseberg View Post
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?
  Reply With Quote
02/07/17, 05:54 PM   #37
ZOS_ChipHilseberg
ZOS Staff!
Premium Member
Yes this person is from ZeniMax!
Join Date: Oct 2014
Posts: 551
Originally Posted by decay2 View Post
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.
  Reply With Quote
02/07/17, 06:01 PM   #38
Solinur
AddOn Author - Click to view addons
Join Date: Aug 2014
Posts: 78
Originally Posted by ZOS_ChipHilseberg View Post
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 !
  Reply With Quote
02/07/17, 06:09 PM   #39
ArtOfShred
 
ArtOfShred's Avatar
AddOn Author - Click to view addons
Join Date: Jun 2016
Posts: 103
\o/ excellent!
  Reply With Quote
02/08/17, 08:56 AM   #40
sirinsidiator
 
sirinsidiator's Avatar
AddOn Author - Click to view addons
Join Date: Apr 2014
Posts: 1,567
Originally Posted by ZOS_ChipHilseberg View Post
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?
  Reply With Quote

ESOUI » Developer Discussions » General Authoring Discussion » PTS 2.7.2 - Effects longer than 30 sec now act same as less than 30 sec.

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off