Additional aura element overrides/callbacks

[myzb]

In SL I was using a combination of callbacks and overrides to display dispellable debuffs nice and big in the middle of my raid frames. I've also used this to display defensive buffs in the top right of my raid frames

The available callback/override points in the aura element for SL were enough to implement this. With the aura element changes for DF (which are great btw :)) the only option I see to reimplement this somewhat cleanly is by the proposed changes in 2a2598f and eb6e778.

• commit eb6e778
  Allows me to do some cleanup on my internal variables if the update is going to be a full update

• commit 2a2598f
  Allows me to temporarily modify the debuffs that will be displayed. I can remove the one debuff I'll be displaying in my own special frame via instanceID and add it back to .active in PostUpdate().

This is how it looks:

Bottom left: Normal debuffs (space for 3 total)
Center: Special debuffs (currently only dispellable)
Top Right (Bonus): Using the logic to display blizzard dispell debuf icon

Any thoughts on this?

[ls-]

I'm still not sure why you'd need PreSort for what you described. You have FilterAura and a bunch of Sort* methods... You use FilterAura to influence what goes in and out of the .active* tables, it can be as complex as you need it to be. I really wanna see what you're actually doing with this code...

[myzb]

I originally tried doing most of the stuff with FilterAura but there are few issue. Maybe I'm overcomplicating.

It's a bit hard to explain, and I don't think my code will make it easier, but here it goes: https://github.com/myzb/oUF_Nine/blob/dragonflight/common/auras.lua#L355.

The thing is that FilterAura is now only called when a new aura instance is applied. So I can only influence what goes in (or out) once for the same aura instance Id.

Ideally I'd filter it out so it doesn't appear with the normal debuffs. Then I'd display it in a self made button in my own center frame. If I do this however I lose the ability for oUF to keep this aura updated for me, since it's gone from .active* .

updateInfo.updatedAuraInstanceIDs could say "nope" auraInstanceId is not in .active* -> debuffsChange = false. And after this there is no other callback I could use since PostUpdate() requires *Change = true.

[ls-]

I'll look into it tomorrow after work. It's already 3am in Thailand 😴 Just telling you so you don't wait for my reply right away, haha 😅

[myzb]

Thank you. Aim of my pull request is mostly to present a real world scenario where having a tiny extra amount of callback options could be of actual benefit. I was debating on just writing a feature request, but opted for being more participative. 😄

[myzb]

So basically I'm trying to use blizzards logic for raid frame buff/debuff filtering and add some extras to it. I was stealing the filtering logic from their code and realized a few things that seem to complicated me further 😢

They seem to not use a a logic to limit the amount of buffs they will process like oUF does eg, here. The thing with oUF is that if you say aura.num = 3 then as soon as you hit 3* any new auras will be dropped and ignored. And if one of those 3 buffs is removed then the 1 empty slot isn't filled up by another aura. Test:

    -- set this for your player
    local Buffs = CreateFrame('Frame', nil, self)
    Buffs:SetPoint('RIGHT', self, 'LEFT')
    Buffs:SetSize(16 * 2, 16 * 16)
    Buffs.num = 3 -- make it 1 more than the amount of passive buffs you currently have

    -- Register with oUF
    self.Buffs = Buffs

Now try to proc or put some buffs on yourself. Since you have 3 passives on you, there is only room for 1 more buff. Check which buff is and click it off. The spot you just freed up wont get filled by another buff.

*) it's 4 actually. apparently setting aura.num = 3 set's the cap to 1 more -> =4. Probably this should be count < num.

I think I'm better of by creating my own aura element version for now 👍

[ls-]

@myzb I'm sorry, I didn't have time to test it. A bit stressed out due to RL stuff and my own addons T_T

The thing with oUF is that if you say aura.num = 3 then as soon as you hit 3* any new auras will be dropped and ignored. And if one of those 3 buffs is removed then the 1 empty slot isn't filled up by another aura.

This is actually something I didn't even consider during my rewrite. I guess I'll need to track all (or something similar) auras on top of active and sorted, so when a slot frees up for in active, I'll rescan all to see if we have something in there. I'll try looking into it tomorrow. I also need to fix Blizz unit frame hiding, that new layout editor is a massive pita, I'm losing my mind because of it 😒🔫

As for that count <= numBuffs check, it looks normal to me because we start with 1 and not 0.

[myzb]

@myzb I'm sorry, I didn't have time to test it. A bit stressed out due to RL stuff and my own addons T_T

The thing with oUF is that if you say aura.num = 3 then as soon as you hit 3* any new auras will be dropped and ignored. And if one of those 3 buffs is removed then the 1 empty slot isn't filled up by another aura.

This is actually something I didn't even consider during my rewrite. I guess I'll need to track all (or something similar) auras on top of active and sorted, so when a slot frees up for in active, I'll rescan all to see if we have something in there. I'll try looking into it tomorrow. I also need to fix Blizz unit frame hiding, that new layout editor is a massive pita, I'm losing my mind because of it 😒🔫
As for that count <= numBuffs check, it looks normal to me because we start with 1 and not 0.

Hey no worries, it's an hobby after all.

I'm experimenting with this atm. Well more like copying blizzards ideas into oUF. So far the only thing I'm missing is how to not be forced to use Blizzards TableUtil.lua within oUF. But it looks promising.

Joined ur Discord server btw. 😄