How to check for buff timers

[Naifu]

Hi guys

While thinking about how to improve the buff counters for nkThings I became unsure if I'm doing the right thing.

There's an add and a remove event for buffs which I'm using. However the change event only fires if the buff fundamentally changes. Either I'm blind or I didn't find any event which fires if the remaining duration of a buff changes.

This means that I had to implement an event.upate.begin routine which checks for new buff duration and updates the timers. In order to not have a to big impact on performance I throttle these checks. Only once per second the check for updated remaining times is done.

Isn't there any better way to do this? The problem with a fixed check interval is that the remaining starts as soon as a buff is cast. Currently I'm rounding the remaining time to the full second. This of course means therefore it's remaining will always be slighty incorrect.

Anybody got a better idea? I really hope someone can tell me that I missing something fundamentally

Cheers
N.

[Sarim]

I don't know if ZorbasBuffBars (of the example addons by Trion) has the "best practice" approach, but you might take a look at how he does things there?

[Mere]

Do you have an example buff that has this problem? I wasn't aware that the change event wouldn't fire for a change in duration, so I probably need to look at handling this issue as well otherwise I'll end up with timers under/overrunning.

[ZorbaTHut]

Hi guys

While thinking about how to improve the buff counters for nkThings I became unsure if I'm doing the right thing.

There's an add and a remove event for buffs which I'm using. However the change event only fires if the buff fundamentally changes. Either I'm blind or I didn't find any event which fires if the remaining duration of a buff changes.

The important number is the time that the buff will end. The change message won't fire unless that changes, because otherwise it would be firing every frame as fractions of a second are shaved off the buff (which sort of defeats the purpose of having an event). Changes in buff ending time are extraordinarily rare, however, they usually just run until they finish.

Once you've queried the buff details once, you should be able to store the buff ending time - I believe Inspect.Buff.Detail provides this directly, there isn't even extra math involved - then calculate the duration easily and efficiently without going through the addon system. This is what Zorba's Buff Bars does.

[Naifu]

Yes this would solve the need to query Inspect.Buff.Detail and I hadn't thought of that approach. Good thinking.

However still I'd need to update the buff timer with system.update.beginn right?

Cheers
N.

[Credo]

Very nice! I'm going to try that as well!

[ZorbaTHut]

However still I'd need to update the buff timer with system.update.beginn right?

Yes, you would, but this should be a lot speedier than querying every single buff every frame.

[Naifu]

Made the change and works perfectly. I'm more happy with the approach now as it gives a lot more accuracy in buff timer calculationg.

However the addon cpu time didn't change at all. It could even be slightly higher by 0.1 or 0.2%. That is most probably due to a slightly higher update cycle of the text displaying the buff counter. I'm a freak for code optimization and doing as few updates as possible. Before I only did the UI update of buff counter once every second for all buffs / debuffs now each buff / debuff is treated individually.

So I'd say more computations and UI updates with same addon cpu usage = instant winner.

Cheers
N.