[Atropos]

Hey Chip, thanks for the further detail!

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