ColorGradient Question

[kitkeh]

Hi. I'm currently one of the coders on LUI and I've spent most of today upgrading the oUF version we use from 1.5.16 (yes, I know, shush) to 1.6.4. Love your work btw.

So anyway, as part of this upgrade I tested the ColorGradient setting we have for various bars through the UI as I noticed that the code hadn't changed and we've had people submitting bug reports regarding LUA errors about b2 being undefined or an "integer overflow attempting to store 1.#INF". Changing to a non gradient colour seems to fix it for them.

After much trial and error I found that all I needed to do was change a 3 to a 2 on line 77 of colors.lua as follows:
Old: local r1, g1, b1, r2, g2, b2 = select((segment*3)+1, ...)
New: local r1, g1, b1, r2, g2, b2 = select((segment*2)+1, ...)

This is the way we're calling it:

r, g, b = oUF.ColorGradient(min/max, unpack(module.colors.smooth()))

Now that I think about it, I didn't actually try sending min and max through separately but I probably should have.

Anyway, after making this change the ColorGradient calls worked OK (at least the b2 undefined error went away). Is this actually a bug in the ColorGradient function or could it just be the way we're using it?

[haste]

The arguments to ColorGradient was changed in 1.6.x. It's now ColorGradient(cur, max, ...).

[kitkeh]

Ah OK, easy enough to change all the ColorGradient calls then. Cheers.

[e] So yep, it was the way we were using it. After changing it to be ColorGradient(cur, max, ...) and changing the 2 back to a 3 it works very well.