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

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]

I was honestly expecting a lot more collateral damage from their attempt to nerf Miat's addon. Hopefully they don't do anything else.

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]

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]

Originally Posted by dorrino 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

[dorrino]

Originally Posted by Baertram 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

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]

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]

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

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

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]

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

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

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

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

Question : so any player you have targeted once, if going stealth, would still be tracked by your addon ?

Originally Posted by dorrino 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!

[ArtOfShred]

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.

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]

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

Originally Posted by MagiczneTornado 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)

[ZOS_ChipHilseberg]

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