04/09/17, 01:15 PM | #1 |
|
EVENT_COMBAT_EVENT ActionResults (Wiki)
/edit: Had a stupid question here... sorry
Last edited by Letho : 04/09/17 at 01:42 PM. |
04/09/17, 02:32 PM | #2 |
|
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". Last edited by Letho : 04/09/17 at 02:36 PM. |
04/09/17, 02:46 PM | #3 |
|
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.
|
04/09/17, 03:36 PM | #4 |
|
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)
|
04/25/17, 03:13 PM | #5 |
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. |
|
04/25/17, 03:54 PM | #6 | |
|
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. Last edited by Letho : 04/25/17 at 03:59 PM. |
|
04/26/17, 03:20 AM | #7 | |
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. |
||
04/26/17, 05:04 AM | #8 | |
|
|
|
04/26/17, 07:02 AM | #9 | ||
|
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)
I am just saying I dont understand why they don't use better filters for unwanted actions or addons resulting from events... Last edited by Letho : 04/26/17 at 07:17 AM. |
||
04/27/17, 08:32 AM | #10 | |
|
|
|
04/27/17, 04:27 PM | #11 |
|
Nop, sadly not. Sounds like a matter of creating some data storage. Only additional information from the native code can help me.
|
05/15/17, 10:00 AM | #12 |
|
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. |
05/15/17, 03:03 PM | #13 | |
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. |
||
05/15/17, 04:38 PM | #14 | ||
|
|
||
05/16/17, 01:16 AM | #15 | |
|
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 Last edited by Letho : 05/16/17 at 05:30 AM. |
|
05/16/17, 02:48 AM | #16 |
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?
|
|
05/16/17, 03:59 AM | #17 | |
|
|
|
05/16/17, 08:49 AM | #18 |
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.
|
|
05/16/17, 10:06 AM | #19 | |
|
It would break a large portion of Raid Notifier if you decide to strip the target unit id from the combat event. |
|
05/16/17, 10:33 AM | #20 |
|
@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. Last edited by Letho : 05/16/17 at 10:37 AM. |
ESOUI » Developer Discussions » Lua/XML Help » EVENT_COMBAT_EVENT ActionResults (Wiki) |
«
Previous Thread
|
Next Thread
»
|
Display Modes |
Linear Mode |
Switch to Hybrid Mode |
Switch to Threaded Mode |
|
|