Quantcast EVENT_COMBAT_EVENT ActionResults (Wiki) - Page 2 - ESOUI
Thread Tools Display Modes
05/16/17, 01:06 PM   #21
ZOS_ChipHilseberg
ZOS Staff!
Premium Member
Yes this person is from ZeniMax!
Join Date: Oct 2014
Posts: 407
Originally Posted by Kyoma View Post
It's this part that scares me:
It would break a large portion of Raid Notifier if you decide to strip the target unit id from the combat event.
Can you provide some specific examples?
  Reply With Quote
05/16/17, 02:19 PM   #22
Kyoma
AddOn Author - Click to view addons
Join Date: Apr 2014
Posts: 17
Originally Posted by ZOS_ChipHilseberg View Post
Can you provide some specific examples?
Hmmm, well posting all the relevant code would be a bit messy but in short I use some code with EVENT_EFFECT_CHANGED to link a target unit id to a group unit tag and then in EVENT_COMBAT_EVENT I pair it back and display certain alerts based on conditions. The other target parameters are indeed empty so I suppose from a developer perspective you might actually have intended to NOT allow such things. I understand that in pvp this kind of stuff might allow unfair foresight but I do not believe it hurts anybody in pve.
  Reply With Quote
05/17/17, 08:01 AM   #23
ZOS_ChipHilseberg
ZOS Staff!
Premium Member
Yes this person is from ZeniMax!
Join Date: Oct 2014
Posts: 407
I've opened a dialogue with some of the game design teams about what we want to allow for combat addons like this. I'll post back when I hear something.
  Reply With Quote
05/18/17, 12:53 AM   #24
dorrino
AddOn Author - Click to view addons
Join Date: Mar 2015
Posts: 42
Originally Posted by Kyoma View Post
Hmmm, well posting all the relevant code would be a bit messy but in short I use some code with EVENT_EFFECT_CHANGED to link a target unit id to a group unit tag and then in EVENT_COMBAT_EVENT I pair it back and display certain alerts based on conditions. The other target parameters are indeed empty so I suppose from a developer perspective you might actually have intended to NOT allow such things. I understand that in pvp this kind of stuff might allow unfair foresight but I do not believe it hurts anybody in pve.
I used pretty much this in my PvpAlerts before Homestead changes

Currently i wasn't able to find a way to link anonymous events by targetUnitId to EVENT_EFFECT_CHANGED ids to any benefit, since, at least in pvp the code seems only to send the later about allies.

I'm curious what is left in pve, that you built an addon feature out of it?
  Reply With Quote
05/19/17, 12:10 PM   #25
ZOS_ChipHilseberg
ZOS Staff!
Premium Member
Yes this person is from ZeniMax!
Join Date: Oct 2014
Posts: 407
After talking to the dungeon team they are willing to put in a buff for the light/dark state on the 2nd boss in Maw of Lorkahj which should allow tracking by addon. In the future we could open COMBAT_EVENT up a bit more but it would take a large audit of all the spells being cast by NPCs since there are a number that should not be known to a player client (this is also true of buffs and debuffs). This would be at a later date, but is something we want to clean up anyway.
  Reply With Quote
05/19/17, 03:56 PM   #26
Letho
AddOn Author - Click to view addons
Join Date: Apr 2016
Posts: 135
Thanks for your amazing work, chip, that's really good news! As a "rule of thumb" I feel that every effect that has a duration and is communicated by changing the visual appearance of your character (glowing hands, heads, etc.) should be communicated via EVENT_EFFECT_CHANGED for the sake of visibility in large scale combat situations. If you could add the fields sourceName and sourceUnitId or at least combatUnitType to EVENT_EFFECT_CHANGED it would make it absolutely perfect

Just out of curiosity: What type of buffs/debuffs/combat vvents shall not be visible to the client and why?

Last edited by Letho : 05/19/17 at 03:59 PM.
  Reply With Quote
06/12/17, 07:17 AM   #27
decay2
AddOn Author - Click to view addons
Join Date: Aug 2014
Posts: 37
Originally Posted by Letho View Post
Thanks for your amazing work, chip, that's really good news! As a "rule of thumb" I feel that every effect that has a duration and is communicated by changing the visual appearance of your character (glowing hands, heads, etc.) should be communicated via EVENT_EFFECT_CHANGED for the sake of visibility in large scale combat situations. If you could add the fields sourceName and sourceUnitId or at least combatUnitType to EVENT_EFFECT_CHANGED it would make it absolutely perfect

Just out of curiosity: What type of buffs/debuffs/combat vvents shall not be visible to the client and why?
sourceUnitType is already in EVENT_EFFECT_CHANGED.
  Reply With Quote

ESOUI » Developer Discussions » Lua/XML Help » EVENT_COMBAT_EVENT ActionResults (Wiki)

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