ESOUI

ESOUI (https://www.esoui.com/forums/index.php)
-   General Authoring Discussion (https://www.esoui.com/forums/forumdisplay.php?f=174)
-   -   PTS 2.7.2 - Effects longer than 30 sec now act same as less than 30 sec. (https://www.esoui.com/forums/showthread.php?t=6745)

MagiczneTornado 01/16/17 01:25 PM
PTS 2.7.2 - Effects longer than 30 sec now act same as less than 30 sec.
 
Quote:
Addons

Effects that last longer than 30 seconds now follow the same rules as effects that last less than 30 seconds: they are only available to player-made addons if they are cast by the player or cast on the player.

So no more checking if other player has mundus stone equipped, no more checking if someone has food/drink active or is a werewolf/vamp?

timidobserver 01/16/17 01:47 PM
I was honestly expecting a lot more collateral damage from their attempt to nerf Miat's addon. Hopefully they don't do anything else.

MagiczneTornado 01/16/17 02:10 PM
If double/triple/more mundus exploit comes back (again) for third or maybe fourth time (since its back again) it will be much harder for players to discover it or find potential exploiters...

dorrino 01/16/17 06:19 PM
I can confirm that on PTS GetNumBuffs('reticleover') and consequenty GetUnitBuffInfo('reticleover', index) return nothing. EVENT_EFFECT_CHANGED is not registered for them as well.

I think i should say sorry about that:)

Baertram 01/16/17 07:27 PM
Quote:
Originally Posted by dorrino (Post 29420)
I think i should say sorry about that:)
Netx time just leave the PvP as it is and don't try to build "helper" addons that give advantages, even if the game doesn't block your attempts by broadcasting everything :rolleyes:

dorrino 01/16/17 11:52 PM
Quote:
Originally Posted by Baertram (Post 29421)
Netx time just leave the PvP as it is and don't try to build "helper" addons that give advantages, even if the game doesn't block your attempts by broadcasting everything :rolleyes:
And nevertheless i'll stick to my guns:) This result is unfortunate, but expected.

And really a mild disturbance compared to some other things that can be done with API.

In my opinion PVP in this game needs more transparency, in the end what addons can do, besides presenting the information in easier to understand manner?

Anceane 01/17/17 12:59 AM
This restriction is only for pvp or even now for pve ?

Thinking about the Jgroup that is a great addon that help the leader to check if everyone has food for example

If pve is concerned by this then i am sorry to say that it is really silly to create addons for pvp knowing they will bring problems and limitations for pve as a result, just to help some ego-pvp to feel better ....

timidobserver 01/17/17 02:32 AM
Quote:
Originally Posted by Anceane (Post 29426)
This restriction is only for pvp or even now for pve ?

Thinking about the Jgroup that is a great addon that help the leader to check if everyone has food for example

If pve is concerned by this then i am sorry to say that it is really silly to create addons for pvp knowing they will bring problems and limitations for pve as a result, just to help some ego-pvp to feel better ....
It is not limited to PvP.

dorrino 01/17/17 11:54 AM
Quote:
Originally Posted by Anceane (Post 29426)
This restriction is only for pvp or even now for pve ?
This is not even a restriction. It's a fix. This distinction between <30sec buffs and >30sec buffs originated from the time when the game did not report <30 buffs at all.

They just forgot to apply consistent treatments to all the buffs.

Now they did, and believe me pvp suffered much more than pve from this.

ZOS_ChipHilseberg 01/17/17 12:09 PM
We are looking at some changes to this ruleset before it goes live that still address the PvP concerns but allow PvE buff addons to continue to work.

dorrino 01/17/17 12:28 PM
Quote:
Originally Posted by ZOS_ChipHilseberg (Post 29435)
We are looking at some changes to this ruleset before it goes live that still address the PvP concerns but allow PvE buff addons to continue to work.
While you're here i have a question.

This change obviously severely limits the features of my addon. Can i (we) get an official stance on which parts of the addon are not desirable within ZOS design direction?

Even after the change i have some ideas how to still get the info i need for the addon to work. This will be noticeably more cumbersome and unreliable (probably) though.

In any case my intention is NOT to start an arms race with you guys. And i don't really want to spend hours of developing an intricate system to circumvent this change only to realize you will counter it with some other change:)

So, please, tell me which features are fine to have within your vision and which features will get an active countermeasures from you?

Thank you,

PS. Chip, in 5-10 min i'll PM you an exploit, that i found, that is very much possible with the current API. It technically allows to automate almost any players actions and CONDITIONALLY call protected and PRIVATE functions even when in combat. Cheers:)

ZOS_ChipHilseberg 01/17/17 12:41 PM
Quote:
Originally Posted by dorrino (Post 29436)
While you're here i have a question.

This change obviously severely limits the features of my addon. Can i (we) get an official stance on which parts of the addon are not desirable within ZOS design direction?

Even after the change i have some ideas how to still get the info i need for the addon to work. This will be noticeably more cumbersome and unreliable (probably) though.

In any case my intention is NOT to start an arms race with you guys. And i don't really want to spend hours of developing an intricate system to circumvent this change only to realize you will counter it with some other change:)

So, please, tell me which features are fine to have within your vision and which features will get an active countermeasures from you?

Thank you,

PS. Chip, in 5-10 min i'll PM you an exploit, that i found, that is very much possible with the current API. It technically allows to automate almost any players actions and CONDITIONALLY call protected and PRIVATE functions even when in combat. Cheers:)
I believe that it was anything that allows you to detect the presence or actions of a hostile player without having to see them.

dorrino 01/17/17 01:05 PM
Quote:
Originally Posted by ZOS_ChipHilseberg (Post 29437)
I believe that it was anything that allows you to detect the presence or actions of a hostile player without having to see them.
1. In this case can i expect that ACTION_RESULT_BEGIN directed to the player from a stealthed origin will be patched out as well?

2. What i have as an idea is to somehow get the UnitId to UnitName link from "reticleover", since you patched getting that from EVENT_EFFECT_CHANGED.

Now the question is - if i'll be able to find a way of doing that it, will it technically be within the paradigm of "not allowing you to detect the presence or actions of a hostile player without having to see them" even though the addon will keep track of them by unitId after the initial recognition has happened?

This way for anybody to be tracked by the addon the player will need to manually mouseover them.

So, if i'll be able to perform this, will it still be against the paradigm?:) And if not, will you be able to provide a fucntion to GetUnitIdFromReticleOver() then to make it considerably easier for me?

Thank you!

ZOS_ChipHilseberg 01/17/17 02:18 PM
Quote:
Originally Posted by dorrino (Post 29438)
1. In this case can i expect that ACTION_RESULT_BEGIN directed to the player from a stealthed origin will be patched out as well?

2. What i have as an idea is to somehow get the UnitId to UnitName link from "reticleover", since you patched getting that from EVENT_EFFECT_CHANGED.

Now the question is - if i'll be able to find a way of doing that it, will it technically be within the paradigm of "not allowing you to detect the presence or actions of a hostile player without having to see them" even though the addon will keep track of them by unitId after the initial recognition has happened?

This way for anybody to be tracked by the addon the player will need to manually mouseover them.

So, if i'll be able to perform this, will it still be against the paradigm?:) And if not, will you be able to provide a fucntion to GetUnitIdFromReticleOver() then to make it considerably easier for me?

Thank you!
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. We'll also clean up the case of the heavy attack sending a begin event even though the source is stealthed, but that will come from a server change.

As far as saving off the name of units as you reticle over them, that sounds fine since the player has to target them in some fashion.

What would you need the unit id for in this new system?

Anceane 01/17/17 02:30 PM
Question : so any player you have targeted once, if going stealth, would still be tracked by your addon ?

Quote:
Originally Posted by dorrino (Post 29438)
1. In this case can i expect that ACTION_RESULT_BEGIN directed to the player from a stealthed origin will be patched out as well?

2. What i have as an idea is to somehow get the UnitId to UnitName link from "reticleover", since you patched getting that from EVENT_EFFECT_CHANGED.

Now the question is - if i'll be able to find a way of doing that it, will it technically be within the paradigm of "not allowing you to detect the presence or actions of a hostile player without having to see them" even though the addon will keep track of them by unitId after the initial recognition has happened?

This way for anybody to be tracked by the addon the player will need to manually mouseover them.

So, if i'll be able to perform this, will it still be against the paradigm?:) And if not, will you be able to provide a fucntion to GetUnitIdFromReticleOver() then to make it considerably easier for me?

Thank you!

dorrino 01/17/17 04:02 PM
Quote:
Originally Posted by ZOS_ChipHilseberg (Post 29439)
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.
Now that i know this you can disregard the unitId from reticelover part. It looks like that unless you make a mistake in the implementation all cases of sourceUnitId/targetUnitId in the events will be accompanied by the source/target names.

The only thing that is left is reticleover target buff info. Right now on pts this info is blank. Was that the intended decision or a collateral result of not supplying buff info to addons through the events?

In my mind even though these buffs might not have been cast by you, having this information on reticleover fully falls into the "not allowing you to detect the presence or actions of a hostile player without having to see them" doctrine. After all you can visually see most if not all of those buffs, so it feels consistent to allow addons to get the target buffs information from reticelover target only.

What is your stance on this part?


Quote:
Originally Posted by ZOS_ChipHilseberg (Post 29439)
We'll also clean up the case of the heavy attack sending a begin event even though the source is stealthed, but that will come from a server change.
Thank you for the heads-up! Even those the whole set of these changes essentially disables my addon i do appreciate knowing this beforehand so i had some time perform a proper burial:)


Quote:
Originally Posted by ZOS_ChipHilseberg (Post 29439)
What would you need the unit id for in this new system?
In the light of the additional changes there's no need for this anymore:)

Quote:
Originally Posted by Anceane (Post 29440)
Question : so any player you have targeted once, if going stealth, would still be tracked by your addon ?
This is irrelevant with the new changes. None of this will work.

ZOS_ChipHilseberg 01/17/17 06:12 PM
Quote:
Originally Posted by dorrino (Post 29441)
The only thing that is left is reticleover target buff info. Right now on pts this info is blank. Was that the intended decision or a collateral result of not supplying buff info to addons through the events?

In my mind even though these buffs might not have been cast by you, having this information on reticleover fully falls into the "not allowing you to detect the presence or actions of a hostile player without having to see them" doctrine. After all you can visually see most if not all of those buffs, so it feels consistent to allow addons to get the target buffs information from reticelover target only.

What is your stance on this part?
.
The rule is now that if you are in Cyrodiil and the unit is hostile then you only know about buffs that you cast or target you. Anywhere else you should know about all buffs.

Sorry about breaking your addon.

dorrino 01/17/17 06:26 PM
Quote:
Originally Posted by ZOS_ChipHilseberg (Post 29443)
The rule is now that if you are in Cyrodiil and the unit is hostile then you only know about buffs that you cast or target you.
Quote:
Originally Posted by ZOS_ChipHilseberg (Post 29443)
the unit is hostile
Does that mean that friendly units in cyrodiil (player's faction) will display their buffs to the addons?


Quote:
Originally Posted by ZOS_ChipHilseberg (Post 29443)
Sorry about breaking your addon.
It's all good. This was expected. Would be awesome if you could integrate some parts of it in the base ui, though. If i could make a choice i'd pick the Kill Feed, since it is the least controversial feature there and many people in pvp are enjoying it.

On a side note, please consider posting the results of the investigation of the exploit i PM-ed you, when you find the time. Addon's authors need to know if/that they can't use it in addons, until you fix it (i doubt you will allow it to be like it is now).

ZOS_ChipHilseberg 01/17/17 07:00 PM
Quote:
Originally Posted by dorrino (Post 29444)
Does that mean that friendly units in cyrodiil (player's faction) will display their buffs to the addons?
That is correct.

dorrino 01/17/17 07:00 PM
Quote:
Originally Posted by ZOS_ChipHilseberg (Post 29445)
That is correct.
Thank you:)

ArtOfShred 01/17/17 09:40 PM
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.

code65536 01/18/17 03:35 PM
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 01/19/17 08:53 AM
Quote:
Originally Posted by code65536 (Post 29457)
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.

dorrino 01/19/17 09:50 AM
Quote:
Originally Posted by ZOS_ChipHilseberg (Post 29439)
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:)

ZOS_ChipHilseberg 01/19/17 03:27 PM
Quote:
Originally Posted by dorrino (Post 29470)
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.

dorrino 01/19/17 06:35 PM
Quote:
Originally Posted by ZOS_ChipHilseberg (Post 29474)
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.

Solinur 01/24/17 08:14 AM
Very nice thread. I like having a little insight into those issues.

Quote:
Originally Posted by ZOS_ChipHilseberg (Post 29439)
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.

MagiczneTornado 02/07/17 04:45 AM
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).

ArtOfShred 02/07/17 05:04 AM
Quote:
Originally Posted by MagiczneTornado (Post 29675)
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.

Solinur 02/07/17 07:06 AM
Quote:
Originally Posted by MagiczneTornado (Post 29675)
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)

Anceane 02/07/17 11:07 AM
Post going on the official forums from Gina :

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

ZOS_ChipHilseberg 02/07/17 01:32 PM
Quote:
Originally Posted by decay2 (Post 29678)
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")

Solinur 02/07/17 02:32 PM
Quote:
Originally Posted by ZOS_ChipHilseberg (Post 29691)
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

Solinur 02/07/17 04:10 PM
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.

ZOS_ChipHilseberg 02/07/17 05:10 PM
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 02/07/17 05:27 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.
Sounds brilliant, thanks a lot Chip. Will we see that before Morrowind? :)

ZOS_ChipHilseberg 02/07/17 05:54 PM
Quote:
Originally Posted by decay2 (Post 29698)
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 02/07/17 06:01 PM
Quote:
Originally Posted by ZOS_ChipHilseberg (Post 29699)
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:

ArtOfShred 02/07/17 06:09 PM
\o/ excellent!

sirinsidiator 02/08/17 08:56 AM
Quote:
Originally Posted by ZOS_ChipHilseberg (Post 29699)
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?

ZOS_ChipHilseberg 02/08/17 12:55 PM
Quote:
Originally Posted by sirinsidiator (Post 29708)
Does that mean the event filters will work on it?
That is correct.

Phinix 02/08/17 05:55 PM
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

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:
  1. GetUnitBuffInfo(string unitTag, number buffIndex)
  2.  
  3.     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:
  1. GetUnitBuffInfo(string unitTag, number buffIndex)
  2.  
  3.     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):

Code:
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 02/20/17 11:43 AM
Quote:
Originally Posted by Phinix (Post 29989)
Possible EVENT_EFFECT_CHANGED castByPlayer values (thanks Ayantir):

Code:
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 02/20/17 12:31 PM
Quote:
Originally Posted by Phinix (Post 29989)
Possible EVENT_EFFECT_CHANGED castByPlayer values (thanks Ayantir):

Code:
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 02/20/17 01:12 PM
Quote:
COMBAT_UNIT_TYPE_GROUP 3
so it should be this :)


All times are GMT -6. The time now is 10:42 AM.

vBulletin © 2024, Jelsoft Enterprises Ltd
© 2014 - 2022 MMOUI