search

oUF-wow / oUF

WoW AddOn - Unit frame framework.
MIT License
222 stars 58 forks source link

Additional aura element overrides/callbacks #620

Closed myzb closed 2 years ago

myzb commented 2 years ago

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 2a2598f4a7011435c8fa3a5b45bebe8f352ee9aa and eb6e77860a2fbee471785e17530e48be413b0dc8.

This is how it looks: image 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- commented 2 years ago

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 commented 2 years ago

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- commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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- commented 2 years ago

@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 commented 2 years ago

@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. 😄