Thread Tools Display Modes
01/16/17, 01:25 PM   #1
MagiczneTornado
Guest
Posts: n/a
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?
  Reply With Quote
01/16/17, 01:47 PM   #2
timidobserver
Join Date: Mar 2014
Posts: 37
I was honestly expecting a lot more collateral damage from their attempt to nerf Miat's addon. Hopefully they don't do anything else.
  Reply With Quote
01/16/17, 02:10 PM   #3
MagiczneTornado
Guest
Posts: n/a
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...
  Reply With Quote
01/16/17, 06:19 PM   #4
dorrino
AddOn Author - Click to view addons
Join Date: Mar 2015
Posts: 50
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
  Reply With Quote
01/16/17, 07:27 PM   #5
Baertram
Super Moderator
 
Baertram's Avatar
WoWInterface Super Mod
AddOn Author - Click to view addons
Join Date: Mar 2014
Posts: 4,912
Originally Posted by dorrino View Post
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
  Reply With Quote
01/16/17, 11:52 PM   #6
dorrino
AddOn Author - Click to view addons
Join Date: Mar 2015
Posts: 50
Originally Posted by Baertram View Post
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?
  Reply With Quote
01/17/17, 12:59 AM   #7
Anceane
 
Anceane's Avatar
AddOn Author - Click to view addons
Join Date: Feb 2014
Posts: 306
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 ....
  Reply With Quote
01/17/17, 02:32 AM   #8
timidobserver
Join Date: Mar 2014
Posts: 37
Originally Posted by Anceane View Post
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.
  Reply With Quote
01/17/17, 11:54 AM   #9
dorrino
AddOn Author - Click to view addons
Join Date: Mar 2015
Posts: 50
Originally Posted by Anceane View Post
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.
  Reply With Quote
01/17/17, 12:09 PM   #10
ZOS_ChipHilseberg
ZOS Staff!
Premium Member
Yes this person is from ZeniMax!
Join Date: Oct 2014
Posts: 551
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.
  Reply With Quote
01/17/17, 12:28 PM   #11
dorrino
AddOn Author - Click to view addons
Join Date: Mar 2015
Posts: 50
Originally Posted by ZOS_ChipHilseberg View Post
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
  Reply With Quote
01/17/17, 12:41 PM   #12
ZOS_ChipHilseberg
ZOS Staff!
Premium Member
Yes this person is from ZeniMax!
Join Date: Oct 2014
Posts: 551
Originally Posted by dorrino View Post
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.
  Reply With Quote
01/17/17, 01:05 PM   #13
dorrino
AddOn Author - Click to view addons
Join Date: Mar 2015
Posts: 50
Originally Posted by ZOS_ChipHilseberg View Post
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!
  Reply With Quote
01/17/17, 02:18 PM   #14
ZOS_ChipHilseberg
ZOS Staff!
Premium Member
Yes this person is from ZeniMax!
Join Date: Oct 2014
Posts: 551
Originally Posted by dorrino View Post
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?
  Reply With Quote
01/17/17, 02:30 PM   #15
Anceane
 
Anceane's Avatar
AddOn Author - Click to view addons
Join Date: Feb 2014
Posts: 306
Question : so any player you have targeted once, if going stealth, would still be tracked by your addon ?

Originally Posted by dorrino View Post
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!
  Reply With Quote
01/17/17, 04:02 PM   #16
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.
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?


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


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

Originally Posted by Anceane View Post
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.

Last edited by dorrino : 01/17/17 at 04:05 PM.
  Reply With Quote
01/17/17, 06:12 PM   #17
ZOS_ChipHilseberg
ZOS Staff!
Premium Member
Yes this person is from ZeniMax!
Join Date: Oct 2014
Posts: 551
Originally Posted by dorrino View Post
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.
  Reply With Quote
01/17/17, 06:26 PM   #18
dorrino
AddOn Author - Click to view addons
Join Date: Mar 2015
Posts: 50
Originally Posted by ZOS_ChipHilseberg View Post
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.
Originally Posted by ZOS_ChipHilseberg View Post
the unit is hostile
Does that mean that friendly units in cyrodiil (player's faction) will display their buffs to the addons?


Originally Posted by ZOS_ChipHilseberg View Post
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).
  Reply With Quote
01/17/17, 07:00 PM   #19
ZOS_ChipHilseberg
ZOS Staff!
Premium Member
Yes this person is from ZeniMax!
Join Date: Oct 2014
Posts: 551
Originally Posted by dorrino View Post
Does that mean that friendly units in cyrodiil (player's faction) will display their buffs to the addons?
That is correct.
  Reply With Quote
01/17/17, 07:00 PM   #20
dorrino
AddOn Author - Click to view addons
Join Date: Mar 2015
Posts: 50
Originally Posted by ZOS_ChipHilseberg View Post
That is correct.
Thank you
  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