ESOUI

ESOUI (https://www.esoui.com/forums/index.php)
-   Lua/XML Help (https://www.esoui.com/forums/forumdisplay.php?f=175)
-   -   EVENT_COMBAT_EVENT ActionResults (Wiki) (https://www.esoui.com/forums/showthread.php?t=6955)

Letho 04/09/17 01:15 PM

EVENT_COMBAT_EVENT ActionResults (Wiki)
 
/edit: Had a stupid question here... sorry :(

Letho 04/09/17 02:32 PM

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:
Code:

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 04/09/17 02:46 PM

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 04/09/17 03:36 PM

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 04/25/17 03:13 PM

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 04/25/17 03:54 PM

Quote:

Originally Posted by Phinix (Post 30714)
(...)

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 04/26/17 03:20 AM

Quote:

Originally Posted by Letho (Post 30718)
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 04/26/17 05:04 AM

Quote:

Originally Posted by Letho (Post 30718)
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 04/26/17 07:02 AM

Quote:

Originally Posted by Phinix (Post 30734)
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)

Quote:

Originally Posted by Kyoma (Post 30738)
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 04/27/17 08:32 AM

Quote:

Originally Posted by Letho (Post 30740)
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 04/27/17 04:27 PM

Quote:

Originally Posted by Kyoma (Post 30756)
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. :(

Nop, sadly not. Sounds like a matter of creating some data storage. Only additional information from the native code can help me.

Letho 05/15/17 10:00 AM

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 05/15/17 03:03 PM

Quote:

Originally Posted by Letho (Post 30943)
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 05/15/17 04:38 PM

Quote:

Originally Posted by Letho (Post 30740)
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...

Quote:

Originally Posted by ZOS_ChipHilseberg (Post 30945)
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 05/16/17 01:16 AM

Quote:

Originally Posted by ZOS_ChipHilseberg (Post 30945)
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..... :D)
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

manavortex 05/16/17 02:48 AM

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?

Solinur 05/16/17 03:59 AM

Quote:

Originally Posted by ZOS_ChipHilseberg (Post 30945)
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.

ZOS_ChipHilseberg 05/16/17 08:49 AM

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 05/16/17 10:06 AM

Quote:

Originally Posted by ZOS_ChipHilseberg (Post 30957)
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:
Quote:

Originally Posted by ZOS_ChipHilseberg (Post 30945)
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.

Letho 05/16/17 10:33 AM

@ChipHilseberg: Oh, frankly I thought the blanked fields were introduced recently :O Doesn't change anything though, some nuances would be very appreciated!

Like Kyoma, I am especially interested in developing addons that help players with raiding.


Let me give you an example:
The 2nd boss in Maw of Lorkahj (the twins) place an effect on you that makes you to belong to the "holy/golden" or "shadow/dark" side. If two players of opposite sides meet, they detonate and die. Many boss mechanics like this one are not communicated by EVENT_EFFECT_CHANGED, they are not shown as buffs/debuffs. So my only chance is using combat events here. I would really love EVENT_COMBAT_EVENT giving full information for NPCs, at least in PvE settings, to make boss actions trackable.


You might ask what the purpose of those addons is:
Well, ESO is very overloaded with visual effects in larger grps in my oppinion, so always looking for your character's body parts glowing is nearly impossible without suffering from stimulus satiation after a short time - IF you can see anything at all. Same goes for PvP in large groups. The approach of "players keeping an eye on their own characters and on enemy characters" does only work out in small scale combat situations, so I develop my addons to compensate.
Additionally players (especially healers) might want to coordinate their actions, but they need information about who put what and how many healing effects on whom. This is where source information would come in VERY handy.


All times are GMT -6. The time now is 03:50 AM.

vBulletin © 2024, Jelsoft Enterprises Ltd
© 2014 - 2022 MMOUI