Thread Tools Display Modes
06/18/15, 08:56 AM   #1
ZOS_ChipHilseberg
ZOS Staff!
Premium Member
Yes this person is from ZeniMax!
Join Date: Oct 2014
Posts: 551
Upcoming Combat and Effect API Changes

In patch 1.7 we will be testing some changes to the rules that control which combat events and effects (buffs/debuffs) are communicated to addons. These changes are intended to deliver more reliable information about what is happening to the player and their target without changing what addons know about activities between other players. Here are some of the changes:

Before:
  • No information on effects that last less than 30 seconds.

After:
  • Addons will now receive information on effects shorter than 30 seconds as long as they affect the player or were cast by the player.

Before:
  • The EFFECT_CHANGED event was unit tag based, which means it was only sent if a unit tag existed for the unit with the effect on them. This means that if a player cast an effect on a target and then looked away, the addon would not receive updates about that effect. It also means it was difficult to track which unit the effect was cast on if the player casts the same effect on multiple targets.

After:
  • The EFFECT_CHANGED event now includes a unit name field and will always be sent, even if no unit tag exists. The event will continue to be sent for each applicable unit tag if unit tags do exist.

Before:
  • COMBAT_EVENT was stripped of most of its information if it failed a filtering check. These filtering rules were complex and hard to account for.

After:
  • COMBAT_EVENT is sent for all ability casts if the source or target is the player or their pet.

Our hope is that these changes will give existing combat and effect addons the same information that they were working hard to cobble together before in a more reliable and easy to use format. We are posting them ahead of time to offer a chance for feedback and discussion before the PTS realm goes live.
  Reply With Quote
06/18/15, 09:03 AM   #2
Ayantir
 
Ayantir's Avatar
AddOn Author - Click to view addons
Join Date: Jul 2014
Posts: 1,019
Thank you very much.
  Reply With Quote
06/18/15, 10:51 AM   #3
Atropos
 
Atropos's Avatar
AddOn Author - Click to view addons
Join Date: Feb 2014
Posts: 19
Huge News

Hey Chip,

Thanks a lot for sharing these plans with us ahead of time, I appreciate the advance heads up. I honestly believe this is a step in the right direction and will greatly improve the quality of addons like my own that are trying to re-assemble this information. I'm sure that being able to present this data more efficiently will benefit addon user's gameplay experience.

I do have a number of questions about these changes, if you can answer:

1. Integrated Combat and Effect UI

Recently during an Xbox One Reddit AUA Chris answered the following question:
Tasteh: The lack of Floating Combat Text is hurting this game’s long term potential. I am a player who enjoys optimizing my character. Because floating combat text is missing, it makes it much harder for me to do so. I am left with 2 options: I can choose to rely on the work being done on PC or try to use time to kill tests on some standardized target. Either way this is suboptimal because I must rely on either external sources or relatively rough estimates. One of the things I’ve heard raised against floating combat text is that it would separate the community. I’d like to address this point now. Regardless of what changes are made, the community will remain separate. The PC community has already determined what builds are powerful, and thus acceptable in hardcore endgame groups, and what are not. That knowledge is already available. Therefore, players who choose to make their own builds that are weaker will already be excluded by these players. You can see then that this point is moot. Another point I’ve heard raised to be a negative for some players is that seeing numbers reduces immersion for them. That is a completely fair and valid argument. To negate this, I would propose that this be a toggle. This would result in no changes for more casual players who want to be as immersed as possible and a positive change for players like me who seek to squeeze out every ounce of damage that we can.

Chris Strasz: hey Tasteh, glad to hear you're enjoying the game! We have begun exploring ways to integrate floating combat text and buff/debuffs within the HUD in a way that still keeps the spirit of the UI minimal. There's several challenges with both of these. We'd like to make sure that the combat text feels satisfying and there's some effort involved there when it comes to the aesthetics of it, the accuracy/data setup, and overall iteration on it. With the buff/debuff feedback, many of our effects are not as long term as other games so we're looking into ways to give this feedback while also not making the HUD appear like a blinking casino machine. But both of these are things we have been exploring internally.
I assume this relaxation of the API is both an effort to reduce the amount of acrobatics existing addons need to perform as well as support the development of integrated UI tools. Some questions on this front:
  1. Is this still a current development goal?
  2. Will an ESO integrated buff tracking and/or damage tracking system be included in 1.7?
  3. Would such systems be shared between PC and Console? I ask because several other interface enhancements are thus-far console specific.
  4. If such a system is created, will there be easily accessible API functions to pass additional combat and buff data for effects that may not be tracked natively?

2. EVENT_EFFECT_CHANGED

I have a few questions and concerns about the new behavior of this event.
  1. Adding a unit name field to the event will help a lot. Do you have any internal suggestion or solution, however, for correctly associating effects with targets in encounters where multiple targets share the same unit name?
  2. Have you considered any potential ramifications of triggering events for cases where a unitTag does not exist? I'm envisioning situations in Cyrodiil where large groups are fighting and spamming AoE effects, many of which incorporate buffs or debuffs. Obviously such cases where a unitTag is not reported can be filtered out, but it may impose a lot of checks to determine when unitTag-less data needs to be used and when it can be ignored.

3. EVENT_COMBAT_EVENT

I have a few questions about this one too.
  1. Would you consider adding abilityId to the data returned by this event?
  2. There are several addons (including my own) that have options for visualizing outgoing damage using ability icon textures whether for in-combat display or post-combat review. Would you consider adding the appropriate texture file-path when one is defined?
  3. When you say COMBAT_EVENT will now be sent for ability casts, do you mean that it will be sent with its full information? Particularly for incoming damage, will we be able to see information about the damage source (origin and ability)?

Thanks a lot for sharing with us Chip, much appreciated.
  Reply With Quote
06/18/15, 12:29 PM   #4
sirinsidiator
 
sirinsidiator's Avatar
AddOn Author - Click to view addons
Join Date: Apr 2014
Posts: 1,567
This sounds great!
One question about the COMBAT_EVENTS though. Right now there are different ways for how the death of a unit is reported.

Currently there are three action results that are related to a unit death.
  • ACTION_RESULT_DIED does sometimes get fired when I kill an NPC but I don't see a pattern here
  • ACTION_RESULT_DIED_XP is fired always when I kill a NPC, but not when one dies by the hands of another player after I damaged it
  • ACTION_RESULT_KILLING_BLOW gets fired when I kill a player, and also when a player that I damaged respawns (with empty skill name argument), but not when a player dies at the hands of another player after I damaged them
Maybe you can adjust this so that there is always an event when a unit dies, regardless of who got the killing blow?
I want to add killed and assisted messages to sidWarTools, but currently it is not really possible to do it in a reliable way.
Ideally there would be three separate action results for a killing blow, when I hit the target and someone else killed it and maybe - unless it is a bug and should be removed - when the target respawns.

EDIT: did some more testing and corrected what I wrote about ACTION_RESULT_DIED

Last edited by sirinsidiator : 06/18/15 at 01:58 PM.
  Reply With Quote
06/18/15, 01:58 PM   #5
ZOS_ChipHilseberg
ZOS Staff!
Premium Member
Yes this person is from ZeniMax!
Join Date: Oct 2014
Posts: 551
Is this [default buff and damage tracking] still a current development goal?
Yes. These API changes have been in testing for a while internally and do not reflect a change in the goals the Chris stated in the AMA.

Will an ESO integrated buff tracking and/or damage tracking system be included in 1.7?
The timelines for these systems have not yet been determined, but they will likely be after 1.7.

Would such systems be shared between PC and Console? I ask because several other interface enhancements are thus-far console specific.
We would like to provide these features for both platforms.

If such a system is created, will there be easily accessible API functions to pass additional combat and buff data for effects that may not be tracked natively?
The buff tracking solution will likely be done in lua which means it would be available for addons to modify. Damage tracking is more likely to be done in the client, and we will have to investigate the rammifications of allowing custom information to be submitted at that time. I see no technical problems with doing that though.

Adding a unit name field to the event will help a lot. Do you have any internal suggestion or solution, however, for correctly associating effects with targets in encounters where multiple targets share the same unit name?
We could supply a unique identifier for each unit if that is useful.

Have you considered any potential ramifications of triggering events for cases where a unitTag does not exist? I'm envisioning situations in Cyrodiil where large groups are fighting and spamming AoE effects, many of which incorporate buffs or debuffs. Obviously such cases where a unitTag is not reported can be filtered out, but it may impose a lot of checks to determine when unitTag-less data needs to be used and when it can be ignored.
The machinery for invoking an event's lua callback is pretty fast, but we will also be adding client event filtering in 1.7. This will allow you to modify an event registration but adding a filter to it from one of several types. If the filter fails, the lua callback will not be invoked. The unit tag and unit tag prefix filters might be helpful here.

Would you consider adding abilityId to the data returned by this event?
We should be able to add that pretty easily.

There are several addons (including my own) that have options for visualizing outgoing damage using ability icon textures whether for in-combat display or post-combat review. Would you consider adding the appropriate texture file-path when one is defined?
We should be able to add that to the ability id based APIs.

When you say COMBAT_EVENT will now be sent for ability casts, do you mean that it will be sent with its full information? Particularly for incoming damage, will we be able to see information about the damage source (origin and ability)?
If the source or target is the player then full information will be provided.
  Reply With Quote
06/18/15, 02:22 PM   #6
Atropos
 
Atropos's Avatar
AddOn Author - Click to view addons
Join Date: Feb 2014
Posts: 19
Hey Chip, thanks for the further detail!

Originally Posted by ZOS_ChipHilseberg View Post
The buff tracking solution will likely be done in lua which means it would be available for addons to modify. Damage tracking is more likely to be done in the client, and we will have to investigate the rammifications of allowing custom information to be submitted at that time. I see no technical problems with doing that though.
That makes sense, I assume the position of combat text would be rendered relative to the position of its target on-screen which puts it in the same boat as nameplates, floating health bars, and chevrons in terms of our ability as addon developers to manipulate those elements.

From a user-experience perspective, client side rendered combat text is a vastly superior solution to a simple scroll or cloud window since it visually associates damage with its target. The only downside from an addon development perspective is that we're stuck with whatever information the default UI solution provides.

I think it would be super cool if there were API functionality to register data for client-side rendering associated with a specific target, however. An example use case would be an addon to registering a floating experience gain number anchored to the position of recently deceased enemies to indicate how much XP was earned by defeating them (assuming the default solution does not include this anyways).

Originally Posted by ZOS_ChipHilseberg View Post
We could supply a unique identifier for each unit if that is useful.
I have often wondered why a unit's unique ID is not exposed to the API. Every unit in the world must have a unique identifier for gameplay systems to correctly function. Providing the unique unitId (or whatever you would call it) would be a massive coup for us as addon authors, enabling us to do all kinds of awesome stuff. It would be a big effort, though, as a lot more than just buff and combat functions would need to report it, other interaction functions like targeting, grouping, etc... would ideally also report it. In short, yes, it would be extremely useful.

Originally Posted by ZOS_ChipHilseberg View Post
The machinery for invoking an event's lua callback is pretty fast, but we will also be adding client event filtering in 1.7. This will allow you to modify an event registration but adding a filter to it from one of several types. If the filter fails, the lua callback will not be invoked. The unit tag and unit tag prefix filters might be helpful here.
I'm not sure I totally understand, but the concept seems fairly straightforward. At the moment what myself (and presumably all other addon authors) do is incorporate a lot of filtering logic within the event callback function to bail out if our desired event conditions are not satisfied. What I think you're saying is there will be a way when we register the event to provide a set of filters or possibly a filtering function that would be checked prior to the event callback being invoked?

On a separate, but related note, has there been any ongoing work to evaluate what is causing certain events to be a bit....spammy? For example, when you form a group there seem to be a ton of redundant events that fire. Units are created, then destroyed, then created again in which creates a lot of false triggers. In this case, if you try to set up group frames or use group member data when a new member first joins, it will often fail since in the intervening milliseconds that unit has been destroyed, then re-created. Weapon swapping is another case in which event triggers seem to be a bit hyperactive.

Originally Posted by ZOS_ChipHilseberg View Post
We should be able to add that [ability IDs] pretty easily.
We should be able to add that [get ability texture] to the ability id based APIs.
YES, a function like GetAbilityTexture( abilityId ) would be hugely valuable. That function plus an abilityId returned directly in the combat event would be a godsend.

Thanks for continuing this discussion. I look forward to seeing what some other authors have to say. Speaking of which:

Originally Posted by sirinsidiator View Post
This sounds great!

Currently there are three action results that are related to a unit death.
  • ACTION_RESULT_DIED does sometimes get fired when I kill an NPC but I don't see a pattern here
  • ACTION_RESULT_DIED_XP is fired always when I kill a NPC, but not when one dies by the hands of another player after I damaged it
  • ACTION_RESULT_KILLING_BLOW gets fired when I kill a player, and also when a player that I damaged respawns (with empty skill name argument), but not when a player dies at the hands of another player after I damaged them

Maybe you can adjust this so that there is always an event when a unit dies, regardless of who got the killing blow?
My experience with this is that _DIED_XP fires when the slain unit grants an XP reward, and _DIED fires instead if the target grants no XP.

I would agree that it would be awesome to have an action result reported (or even separate event) for target death even if the player did not directly generate the killing blow.
  Reply With Quote
06/19/15, 07:52 AM   #7
ZOS_ChipHilseberg
ZOS Staff!
Premium Member
Yes this person is from ZeniMax!
Join Date: Oct 2014
Posts: 551
What I think you're saying is there will be a way when we register the event to provide a set of filters or possibly a filtering function that would be checked prior to the event callback being invoked?
Here is an example:
Lua Code:
  1. control:AddFilterForEvent(EVENT_POWER_UPDATE, REGISTER_FILTER_UNIT_TAG_PREFIX, "boss")
The advantage is that we can filter very cheaply in C++ and we don't have to pay the price of going into the VM only for it to early out.

On a separate, but related note, has there been any ongoing work to evaluate what is causing certain events to be a bit....spammy?
We can look into it. Are there any other examples you have?
  Reply With Quote
06/19/15, 08:32 AM   #8
ZOS_ChipHilseberg
ZOS Staff!
Premium Member
Yes this person is from ZeniMax!
Join Date: Oct 2014
Posts: 551
For the unique ID we're looking at providing a number to identify each instance with the same name. Players will always be 0 (since their name should be unique anyway) and non-players will have an arbitrary number that will be the same as long as that unit exists.
  Reply With Quote
06/19/15, 10:24 AM   #9
Atropos
 
Atropos's Avatar
AddOn Author - Click to view addons
Join Date: Feb 2014
Posts: 19
Hey Chip, thanks again for all the discussion, I really appreciate the insight.

Originally Posted by ZOS_ChipHilseberg View Post

Here is an example:
Lua Code:
  1. control:AddFilterForEvent(EVENT_POWER_UPDATE, REGISTER_FILTER_UNIT_TAG_PREFIX, "boss")

The advantage is that we can filter very cheaply in C++ and we don't have to pay the price of going into the VM only for it to early out.

We can look into it. Are there any other examples you have?
Very interesting. So, in the POWER_UPDATE example, if I'm understanding this correctly: if we are doing unit frames, and we have several different controls (player, target, group, boss, etc..) it would be "best practice" in 1.7+ to :RegisterForEvent() each control separately, and :AddFilterForEvent() each control for its relevant unit tag prefix.

Hopefully the 1.7 API documentation can have a list of allowable filters per event, but this sounds promising for both addons and default UI. Do you guys already use these filters, or is this a new logic that will benefit the default UI as well?

I have a more "big-picture" question, if you can indulge me. Suppose 10 controls all register for a certain event. When the event-triggering action occurs, does C++ issue 10 parallel calls to the LUA VM, or does it just send the event to LUA which distributes it to the 10 registered controls? It sounds to me like what you are saying is that the C-side filtering would allow us to reduce the number of calls to the VM, so I'm guessing it's parallel threads. Given the amount of filtering that I do in FTC alone I could easily see how this could have a performance impact. I filter out maybe 7/10 events that I am registered for.

Originally Posted by ZOS_ChipHilseberg View Post
For the unique ID we're looking at providing a number to identify each instance with the same name. Players will always be 0 (since their name should be unique anyway) and non-players will have an arbitrary number that will be the same as long as that unit exists.
Sounds super helpful, I hope this can happen!
  Reply With Quote
06/19/15, 12:15 PM   #10
ZOS_ChipHilseberg
ZOS Staff!
Premium Member
Yes this person is from ZeniMax!
Join Date: Oct 2014
Posts: 551
I have a more "big-picture" question, if you can indulge me. Suppose 10 controls all register for a certain event. When the event-triggering action occurs, does C++ issue 10 parallel calls to the LUA VM, or does it just send the event to LUA which distributes it to the 10 registered controls? It sounds to me like what you are saying is that the C-side filtering would allow us to reduce the number of calls to the VM, so I'm guessing it's parallel threads. Given the amount of filtering that I do in FTC alone I could easily see how this could have a performance impact. I filter out maybe 7/10 events that I am registered for.
For each event registered we invoke the supplied lua closure and then return back to C++.
  Reply With Quote
06/19/15, 12:50 PM   #11
sirinsidiator
 
sirinsidiator's Avatar
AddOn Author - Click to view addons
Join Date: Apr 2014
Posts: 1,567
Originally Posted by ZOS_ChipHilseberg View Post
For the unique ID we're looking at providing a number to identify each instance with the same name. Players will always be 0 (since their name should be unique anyway) and non-players will have an arbitrary number that will be the same as long as that unit exists.
Does this mean they will have consecutive ids or can the same id appear multiple times during a play session?

Originally Posted by ZOS_ChipHilseberg View Post
We can look into it. Are there any other examples you have?
When I look at some players I get flooded with ~40 EVENT_RETICLE_TARGET_PLAYER_CHANGED events.
I just need to look around in Belkarth for a bit and get thousands of these.
My guess is this happens when there are multiple players standing close to each other.

I also get hundreds of EVENT_COMBAT_EVENT when I just stand around inside the city and do nothing.


EDIT1: After I open the campaign window for the first time, I also get 2 EVENT_KEEP_RESOURCE_UPDATE for each existing resource per second which makes this the most spammy event so far.

EDIT2: This is what I get after I stay near a sieged keep in Cyrodiil and participate in one short fight.

ABILITY_COOLDOWN_UPDATED and ACTION_UPDATE_COOLDOWNS are thrown quite a lot for me only fighting for 10 seconds. The rest of the time I was just staying hidden.

EDIT3: The previous screenshot has a bug where the detail view does not sort the entries correctly, so here is another one of a fight for a keep.

Last edited by sirinsidiator : 06/19/15 at 01:42 PM.
  Reply With Quote
06/22/15, 06:47 AM   #12
sirinsidiator
 
sirinsidiator's Avatar
AddOn Author - Click to view addons
Join Date: Apr 2014
Posts: 1,567
I was wondering if you could add a method to fire events for testing purposes in the next major update.
More than once did I want to try what happens when a certain event gets thrown, but there is often no easy way to achieve this in a controlled way.

Something like
Lua Code:
  1. DebugFireEvent(eventId, ...)
would be really nice.
  Reply With Quote
06/22/15, 09:59 AM   #13
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 sirinsidiator View Post
I was wondering if you could add a method to fire events for testing purposes in the next major update.
More than once did I want to try what happens when a certain event gets thrown, but there is often no easy way to achieve this in a controlled way.

Something like
Lua Code:
  1. DebugFireEvent(eventId, ...)
would be really nice.
I definately would like to have this one too!
  Reply With Quote
06/22/15, 10:31 AM   #14
Atropos
 
Atropos's Avatar
AddOn Author - Click to view addons
Join Date: Feb 2014
Posts: 19
Originally Posted by sirinsidiator View Post
I was wondering if you could add a method to fire events for testing purposes in the next major update.
More than once did I want to try what happens when a certain event gets thrown, but there is often no easy way to achieve this in a controlled way.

Something like
Lua Code:
  1. DebugFireEvent(eventId, ...)
would be really nice.
I think every addon author would absolutely love to have this functionality. Please consider it!
  Reply With Quote
06/22/15, 10:37 AM   #15
XanDDemoX
AddOn Author - Click to view addons
Join Date: May 2015
Posts: 28
You can make your own

(pseudo code)

Code:
local function DebugFireEvent(events,eventId,...)

    local func = events[eventId]
    if func ~= nil then
         
           func(...)

    end

end

-- Usage 

local function Event1Fired(eventCode)

end

-- lookup 
local _events = {

   [EVENT_ID_1] = Event1Fired,

   [EVENT_ID_2] = function(eventCode)

   end

}

-- register handlers any way you like with EVENT_MANAGER:RegisterForEvent 
-- as long as the function address is also in a lookup

-- Test fire events
DebugFireEvent(_events,EVENT_ID_1,...)

DebugFireEvent(_events,EVENT_ID_2,...)
  Reply With Quote
06/22/15, 11:08 AM   #16
sirinsidiator
 
sirinsidiator's Avatar
AddOn Author - Click to view addons
Join Date: Apr 2014
Posts: 1,567
Originally Posted by XanDDemoX View Post
You can make your own
This only works for addon event handlers, which is something I already do whenever it is possible.
But there is no way - at least I know of none - to access the ingame event handlers, so in order to test how the GUI reacts to a specific event, I need to find a situation in the game where the event will get triggered and do that over and over again.

For example I built a feature into sidWarTools that reacts to EVENT_RESURRECT_REQUEST and also is linked to the behavior of the default UI. In order to test what happens when I get resurrected I had to let myself get killed and have someone revive me over and over.
I could add some extra code to call the handler in my addon manually, but it is only one part of the functionality and the handler in the default UI is not exposed, so I can't do the same with that.
With a DebugFireEvent function I could simply fire that event and the event manager handles the rest.
  Reply With Quote
06/22/15, 11:40 AM   #17
XanDDemoX
AddOn Author - Click to view addons
Join Date: May 2015
Posts: 28
Originally Posted by sirinsidiator View Post
This only works for addon event handlers, which is something I already do whenever it is possible.
But there is no way - at least I know of none - to access the ingame event handlers, so in order to test how the GUI reacts to a specific event, I need to find a situation in the game where the event will get triggered and do that over and over again.

For example I built a feature into sidWarTools that reacts to EVENT_RESURRECT_REQUEST and also is linked to the behavior of the default UI. In order to test what happens when I get resurrected I had to let myself get killed and have someone revive me over and over.
I could add some extra code to call the handler in my addon manually, but it is only one part of the functionality and the handler in the default UI is not exposed, so I can't do the same with that.
With a DebugFireEvent function I could simply fire that event and the event manager handles the rest.
Oh yes not saying it would help in that circumstance
  Reply With Quote
06/22/15, 03:50 PM   #18
ZOS_ChipHilseberg
ZOS Staff!
Premium Member
Yes this person is from ZeniMax!
Join Date: Oct 2014
Posts: 551
We've added a new function called GetAbilityIcon which takes the ability id and returns its icon path. We've also modified COMBAT_EVENT to pass numerical identifiers for the source and target so units with the same name can be separated. This ids are good for as long as the unit exists on the client. The same is true of EFFECT_UPDATED and its unit.
  Reply With Quote
06/22/15, 04:08 PM   #19
Atropos
 
Atropos's Avatar
AddOn Author - Click to view addons
Join Date: Feb 2014
Posts: 19
Originally Posted by ZOS_ChipHilseberg View Post
We've added a new function called GetAbilityIcon which takes the ability id and returns its icon path. We've also modified COMBAT_EVENT to pass numerical identifiers for the source and target so units with the same name can be separated. This ids are good for as long as the unit exists on the client. The same is true of EFFECT_UPDATED and its unit.
Oh yes, this is great. Any word on abilityId getting included in COMBAT_EVENT?
  Reply With Quote
06/23/15, 07:31 AM   #20
ZOS_ChipHilseberg
ZOS Staff!
Premium Member
Yes this person is from ZeniMax!
Join Date: Oct 2014
Posts: 551
Originally Posted by Atropos View Post
Oh yes, this is great. Any word on abilityId getting included in COMBAT_EVENT?
I forgot to mention that part. It's included in the event now.
  Reply With Quote

ESOUI » Developer Discussions » General Authoring Discussion » Upcoming Combat and Effect API Changes

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