View Single Post
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