2.7 - Can see other player debuffs now (Tips for Buff/Debuff Frame addon makers)
So with the API changes in 2.7 we can now see debuffs applied onto enemies by other friendly players. This has also led to more NPC self buffs displaying which is great! However, due to the massive increase in number of buffs displayed on the target this can lead to a lot of unnecessary information being broadcast.
I've found a solution that is relatively foolproof for adjusting what is displayed by using EVENT_COMBAT_EVENT to filter incoming buffs/debuffs. EVENT_COMBAT_EVENT will return a nil source or target if the source or target is not the player. This allows us to filter in anything incoming if its not from the player in a rather simple way. Thankfully this event returns information before EVENT_EFFECT_CHANGED. First off you'll want to create 2 local variables in the relevant lua file for your addon which you intend to control buff/display: Code:
local buffSource = nil Code:
buffSource = zo_strformat("<<t:1>>",sourceName) Code:
if buffSource == "" and buffTarget == "" and effectType == 2 then return end Of course instead of returning the function, you could add specific conditions in here to change the way a buff is displayed when its source is not the player (greying it out for example). Now the only issue with this is it will hide some self-applied debuffs NPC's place on themselves that may provide useful information to the player. The counter to this is to create a table of AbilityID's to be listed as an exception to this. I have a table in LUI to create exceptions. Code:
E.DebuffDisplayOverride = { Then you can modify the statement above to something like: Code:
if buffSource == "" and buffTarget == "" and effectType == 2 and not E.DebuffDisplayOverride[abilityId] then return end EDIT: Also note: it is important that we check for both SOURCE and TARGET when determining whether an effect is from a non-player source/target. The reason for this is that EFFECT_COMBAT_EVENT displays buffs and debuffs that are fading with a NIL source and the target as a player. Without checking for both source/target, its possible that an effect that has an unlimited duration (a toggle ability, mundus buff, etc) would never be removed from the buff/debuff display. There's probably other potential problems with it, depending on the method you're using to create buff/debuff displays. With this method, the container is just never created at all which should cause 0 issues. Last thing, consider adding: Code:
if isError then return end |
Nice writeup, just a little bit behind the times. Instead of filtering all combat events in Lua, you should always try to filter them with the built in event filters first, as they offer way better better performance for this task. Afterwards you can filter the remaining events in Lua without much impact ;)
|
Quote:
I'll have to look into it a bit more, I definitely need to optimize some of the custom functions I've put into LUI's event display. Thanks! |
Quote:
You also can not give a list of abilities. Instead you would need to register each ability on its own. (see the custom ability part in CombatMetrics.lua) |
This brings up a new question: Until now I assumed that event data was only sent once to a client per event occurance.
1. Lets assume we have two addons: A and B. 2. B adds a filter for a specific event. 3. A uses this event too. The event is still accessible for A. => events are triggered at a "per addon" basis. Ain't that very unefficient or am I missing sth.? |
The event is triggered internally by the client and add-ons merely request that a callback function is called when that event is triggered. So when it goes off, the client goes through all of the registered callbacks and fires them off. The filter is only applied to that add-on's registered callback and merely just has it checked by the client itself instead of the add-on's code doing the checking.
|
I see, thx for the info!
|
All times are GMT -6. The time now is 11:21 PM. |
vBulletin © 2024, Jelsoft Enterprises Ltd
© 2014 - 2022 MMOUI