v8.1.5-13-alpha1

Specifically, this portion is causing weird behavior:

                    if start == 0 then
                        start = rec.exact_time - max( state.gcd.max, ability.cooldown )
                    end

Removing it fixed the problem.

What were you trying to fix with this? Were some abilities not functioning properly?

I think I'd probably go with the last GCD's start time.

Even before I knew the issue I was thinking about suggesting that all Icon 1 cooldown sweeps use the last occurring GCD's start time. For example, often times Tiger's Fury will be the next suggested ability when it's coming off cooldown. But since its cooldown is 30 seconds, that can mean that it's 1-2 seconds away from being able to be used and that makes the cooldown sweep progress from around 95% to 100%. That's not particularly useful in terms of visibility. It's even worse when it's a long cooldown like Berserk.

In terms of code, I was thinking something like:

1. store gStart somewhere persistent (something like state.gcd.start)
2. always use that as the start of the cooldown sweep for Icon 1 (duration stays as you have it duration = rec.exact_time - start).
3. If you think a fallback is needed (don't think it really would be) then just use similar to what you have rec.exact_time - state.gcd.max

So, here's what I'm trying in v8.1.5-14-alpha1 (45747e2).

It's basically exactly what you've recommended here.

Yes, your proposed version would work for an ability that was on-cooldown (or waiting on resources) and had an additional delay, but it would double-dip the delay -- you could see this with Ferocious Bite's timer not ending until energy was well past 50.

Additionally, if there were a delay for an ability that is not on cooldown, the cooldown spiral wouldn't account for it properly.

Basically, if an ability isn't really on cooldown and its usage is delayed for another reason (i.e., waiting for a buff/debuff to fall w/in pandemic range), your solution wouldn't display account for this effectively.

This solution was seeking to come up with default behavior for a delay timer in the absence of cooldown + delay, but obviously isn't ideal either. Basically, there needs to be a consistent start for delayed entries that are not on cooldown (or regenerating energy), and I haven't settled on something that'll be consistent yet.

I'm pretty satisfied with this implementation so far, going to close this ticket unless something new comes up.