EVENT_COMBAT_EVENT ActionResults (Wiki)

[Letho]

/edit: Had a stupid question here... sorry

[Letho]

Ok, another question instead:

EVENT_COMBAT_EVENT does not return any sourceName values, it's always empty (even if the source is the player himself). Is this intended, does anybody know why it does not work? I know ZOS has deactivated many events in cyrodiil, but it doesn't work anywhere...

Example:

function AuraMastery.OnCombatEvent(eventCode,result,isError,abilityName,abilityGraphic,abilityActionSlotType,sourceName,sourceType,targetName,targetType,hitValue,powerType,damageType,combatEventLog,sourceUnitId,targetUnitId,abilityId)
	if ACTION_RESULT_EFFECT_GAINED_DURATION == result then
		d(targetName.." got "..abilityName.." from "..sourceName)
	end
	if ACTION_RESULT_EFFECT_FADED == result then 
		d(sourceName.."'s ("..sourceUnitId..") "..abilityName.." faded from "..targetName)
	end
end

It prints
"'s (0) Major Sorcery faded from Letho" where it should actually be "Letho's ([my unitID]) Major Sorcery faded from Letho".

[Kyoma]

Even if it is an effect gained by the player through something he did it might still not have an actual source. ESO can be kinda weird about that, especially when they removed source info from others.

[Letho]

It is even worse... appareantly combat events are not sent for people who are a) not in your group or b) not affected by your actions (buffs/debuffs/etc.). Really don't understand ZOS's policy here (= outside of pvp)

[Phinix]

The biggest trouble I have had with this in working on Srendarr is that there is no way to do reliable multi-source aura tracking.

The best you can do is have auras generated separately for "from the player" or "from something else" but there is no way to track "something else" separately with the current data returned by events. So, if multiple things that are not the player add the same aura, you will just update the same single "from something else" icon and not show multiple instances of buffs/debuffs not from the player, which is either good or bad depending on your goals.

Personally I would LOVE to see sourceUnitID added to the data return from EVENT_EFFECT_CHANGED, EVENT_COMBAT_EVENT, and EVENT_RETICLE_TARGET_CHANGED.

[Letho]

Originally Posted by Phinix (...) Personally I would LOVE to see sourceUnitID added to the data return from EVENT_EFFECT_CHANGED, EVENT_COMBAT_EVENT, and EVENT_RETICLE_TARGET_CHANGED.

I am totally with you here. As I do understand (but not agree to) the reasons ZOS saw for crippling those events by blanking fields in PVP, I simply do not understand why those "dead" fields cannot be activated in pve again...

I'd even go further and say that combat events should provide a level of details that allows to track EVERY single event in combat.

AFAIK the sourceUnitId is sent with EVENT_EFFECT_CHANGED, but only for effects that originate from you and group members?

A statement would be really nice @ChipHilseberg.

[Phinix]

Originally Posted by Letho AFAIK the sourceUnitId is sent with EVENT_EFFECT_CHANGED, but only for effects that originate from you and group members?.

EVENT_EFFECT_CHANGED only sends the ID of the TARGET. EVENT_COMBAT_EVENT also sends the sourceUnitId, but I am not sure either is sending them all the time. Needs testing.

For buff tracking purposes however (like Srendarr), ALL THREE events would have to send the source ID (or some other unique identifier), as moving your mouse off a target with auras active needs to be able to refresh the target buff/debuff window when you mouse back over it or over a new target and to do that properly with separate tracking for each aura source, EVENT_RETICLE_TARGET_CHANGED would have to send this information as well.

[Kyoma]

Originally Posted by Letho I am totally with you here. As I do understand (but not agree to) the reasons ZOS saw for crippling those events by blanking fields in PVP, I simply do not understand why those "dead" fields cannot be activated in pve again... I'd even go further and say that combat events should provide a level of details that allows to track EVERY single event in combat. AFAIK the sourceUnitId is sent with EVENT_EFFECT_CHANGED, but only for effects that originate from you and group members? A statement would be really nice @ChipHilseberg.

It wasn't just because of PvP that these 'source fields' got nuked, originally it was because ZOS deemed it inappropriate to be able to see/track other players' dps.

[Letho]

Originally Posted by Phinix EVENT_EFFECT_CHANGED only sends the ID of the TARGET. EVENT_COMBAT_EVENT also sends the sourceUnitId, but I am not sure either is sending them all the time. Needs testing. For buff tracking purposes however (like Srendarr), ALL THREE events would have to send the source ID (or some other unique identifier), as moving your mouse off a target with auras active needs to be able to refresh the target buff/debuff window when you mouse back over it or over a new target and to do that properly with separate tracking for each aura source, EVENT_RETICLE_TARGET_CHANGED would have to send this information as well.

Yes, that is a problem. I tested it shortly after the release of homestead and as far as I remember unitSourceId is ALWAYS void, even if the player is the source, be it inside CYRO or outside, be it in pve or pvp.
I see what you mean though and totally agree: source and target information should be included in ALL appropriate events - I would go further again and request another field: the globald unit id, sending the unique ressource identifier that the native code uses for each instance of an object. (*dreaming of a good server architecture to withstand the pressure* lol)

Originally Posted by Kyoma It wasn't just because of PvP that these 'source fields' got nuked, originally it was because ZOS deemed it inappropriate to be able to see/track other players' dps.

EVENT_EFFECT_CHANGED does not provide enough information for calculating dps. They could have blanked damage/hit notifications for EVENT_COMBAT_EVENT, but events related to buffs/debuffs gained, fading, refreshed provided by either EFFECT_CHANGED or COMBAT_EVENT do not harm anybody.

I am just saying I dont understand why they don't use better filters for unwanted actions or addons resulting from events...

[Kyoma]

Originally Posted by Letho EVENT_EFFECT_CHANGED does not provide enough information for calculating dps. They could have blanked damage/hit notifications for EVENT_COMBAT_EVENT, but events related to buffs/debuffs gained, fading, refreshed provided by either EFFECT_CHANGED or COMBAT_EVENT do not harm anybody. I am just saying I dont understand why they don't use better filters for unwanted actions or addons resulting from events...

I know, I'd like that too in certain situations for Raid Notifier. I already have code to link a unitId to a group tag (and also a boss tag) but that probably won't help you in what you need it for.

[Letho]

Hey guys, there was once a thread in this forum where chip clarified about what has been blanked in EVENT_COMBAT_EVENT and as far as I remember the restrictions were only supposed to be applied in cyrodiil? Can sb. direct me to the appropriate topic for I don't find it anymore :O

Background: I just realized EVENT_COMBAT_EVENT has been deactivated (= only sends info about spells AFFECTING you or COMING from you) in PvE aswell, which is... well... not so fine.

[ZOS_ChipHilseberg]

Originally Posted by Letho Hey guys, there was once a thread in this forum where chip clarified about what has been blanked in EVENT_COMBAT_EVENT and as far as I remember the restrictions were only supposed to be applied in cyrodiil? Can sb. direct me to the appropriate topic for I don't find it anymore :O Background: I just realized EVENT_COMBAT_EVENT has been deactivated (= only sends info about spells AFFECTING you or COMING from you) in PvE aswell, which is... well... not so fine.

Looking at the current code I'm seeing:

Targets Player/Pet or from Player/Pet

Full information.

Doesn't target Player/Pet and isn't from Player/Pet

You get limited information. This hides the ability name, icon, damage type, source name, source unit id, source type, target name, target type, and...not target unit id apparently...maybe that should be gone too. The exception to this case is in Cyrodiil and BGs where you get limited information about DIED, DIED_XP, and KILLING_BLOW results ONLY. This is because the mere presence of a COMBAT_EVENT can be used to detect the presence of other players in the area.

[Kyoma]

Originally Posted by Letho Yes, that is a problem. I tested it shortly after the release of homestead and as far as I remember unitSourceId is ALWAYS void, even if the player is the source, be it inside CYRO or outside, be it in pve or pvp. I see what you mean though and totally agree: source and target information should be included in ALL appropriate events - I would go further again and request another field: the globald unit id, sending the unique ressource identifier that the native code uses for each instance of an object. (*dreaming of a good server architecture to withstand the pressure* lol) EVENT_EFFECT_CHANGED does not provide enough information for calculating dps. They could have blanked damage/hit notifications for EVENT_COMBAT_EVENT, but events related to buffs/debuffs gained, fading, refreshed provided by either EFFECT_CHANGED or COMBAT_EVENT do not harm anybody. I am just saying I dont understand why they don't use better filters for unwanted actions or addons resulting from events...

Originally Posted by ZOS_ChipHilseberg Looking at the current code I'm seeing: Targets Player/Pet or from Player/Pet Full information. Doesn't target Player/Pet and isn't from Player/Pet You get limited information. This hides the ability name, icon, damage type, source name, source unit id, source type, target name, target type, and...not target unit id apparently...maybe that should be gone too. The exception to this case is in Cyrodiil and BGs where you get limited information about DIED, DIED_XP, and KILLING_BLOW results ONLY. This is because the mere presence of a COMBAT_EVENT can be used to detect the presence of other players in the area.

Please dont remove targetUnitId outside Cyro/PvP!

[Letho]

Originally Posted by ZOS_ChipHilseberg Looking at the current code I'm seeing: Targets Player/Pet or from Player/Pet Full information. Doesn't target Player/Pet and isn't from Player/Pet You get limited information. This hides the ability name, icon, damage type, source name, source unit id, source type, target name, target type, and...not target unit id apparently...maybe that should be gone too. The exception to this case is in Cyrodiil and BGs where you get limited information about DIED, DIED_XP, and KILLING_BLOW results ONLY. This is because the mere presence of a COMBAT_EVENT can be used to detect the presence of other players in the area.

Thanks for the clarification, Chip! From your statement I deduce that using "conditional filters" on the server's side is possible (DIED, DIED_XP, etc. working only in Cyrodiil).

As everybody clearly sees the neccessity of enemy faction's players not being detected by the use of combat_event tracking addons, I have the feeling that you overreacted a bit with killing the whole events in PvP AND PvE. I'd like to make the following suggestion (the list is ordered by increasing restrictivity, so if the 1. suggestion would not suffice to break unwanted addon functionality, move to the 2nd suggestion, and so on...).


But before you look at those suggestions, have a look at this picture, please:





Why not just deactivate combat_events under specific circumstances?

1. stealthed hostile players and npcs do not send combat_events (anti enemy stealth detection)
2. hostile player characters and pets do not send combat_events in pvp environments (anti enemy reaction alerts, e.g. "BEWARE, enemy is casting crystal frags!" -- to be honest, this information can also be gained by looking at the enemy's character, so I can't see any harm in addons doing this)
3. all player characters and their pets do not send combat_events in pvp environments (to prevent any info given about all player actions)
4. players and pets only send combat events when grouped with you (in pvp) - NPCs STILL send all information!
5. players and pets only send combat events when grouped with you (in pve) - NPCs STILL send all information!
6. only blank the damage field in pve settings (preventing dmg meter addons - if you really must..... )
7. at least add a sourceName and sourceUnitId field to EVENT_EFFECT_CHANGED and GetUnitBuffInfo()

So the functionallity would at least be retained in PvE settings

[Solinur]

Originally Posted by ZOS_ChipHilseberg Looking at the current code I'm seeing: Targets Player/Pet or from Player/Pet Full information. Doesn't target Player/Pet and isn't from Player/Pet You get limited information. This hides the ability name, icon, damage type, source name, source unit id, source type, target name, target type, and...not target unit id apparently...maybe that should be gone too.

This would kill the ability of Combat Metrics to calculate the total DPS of a trial group. I guess some people would be sad about that going away. On the other hand, in small groups, said group DPS is a somewhat conclusive indicator of the peformance of individuals.

[manavortex]

I also like the idea of having these kinds of event work differently in PVP situations. I get that you needed to block this out (MIATS was kind of a game changer, everyone without it was instantly at a huge disadvantage... not that I dislike that, because bending the rules of reality with the help of overly elaborate tools is a very Telvanni thing to do, but I get that you wanted to restore fairness), but it would be awesome if you could implement it in a similar fashion to the 3d API (with which I still haven't gotten to play with... *sighs*) and just disable access inside Cyrodiil/arenas? maybe? An IsPVPArea() might help?

[ZOS_ChipHilseberg]

There's probably something we can do to nuance this a bit more. But I'm a bit confused by what changed in PvE. As far back as 2015 the code is stripping information from all things not from you or targeting you in PvE. PvE should not have changed in a long time.

[Kyoma]

Originally Posted by ZOS_ChipHilseberg There's probably something we can do to nuance this a bit more. But I'm a bit confused by what changed in PvE. As far back as 2015 the code is stripping information from all things not from you or targeting you in PvE. PvE should not have changed in a long time.

It's this part that scares me:

Originally Posted by ZOS_ChipHilseberg and...not target unit id apparently...maybe that should be gone too

It would break a large portion of Raid Notifier if you decide to strip the target unit id from the combat event.

[ZOS_ChipHilseberg]

Originally Posted by Kyoma 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?

[Kyoma]

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