When UnitReaction returns nil

[Barjack]

So, when a bar has bar.colorReaction set to true, the default health update function can behave a little oddly. The check on that line is simply

elseif(bar.colorReaction) then

which does not guarantee there is a valid reaction for the unit. For instance on a target frame without something like colorClassPet, targeting a partypet in a different instance will return nil. As a result the bar's color is not changed at all and it will just retain the color of the previously targeted unit.

I'm not 100% sure if this would be considered a bug but, the way that if chain works makes it feel like it's supposed to continue falling through until it finds a valid color for the bar. But as long as colorReaction is true it cannot fall through to colorSmooth or colorHealth ever, even if there is no valid reaction for the unit.

Anyway, in my copy I just stuck

and UnitReaction(unit, "player") ~= nil

onto the end of that condition. But I don't know if that was specifically not done for performance reasons, or if it was just an oversight, or if it's intentional design or what, so I thought I'd at least bring it up.

[p3lim]

When would UnitReaction ever be nil?

[Barjack]

Originally Posted by p3lim When would UnitReaction ever be nil?

I gave an example in the post:

For instance on a target frame without something like colorClassPet, targeting a partypet in a different instance will return nil.

Edit: Which is to say, UnitReaction("player", "target") and UnitReaction("target", "player") are both nil when you target a pet in a different instance to you. There may be other cases also, but for certain that is one. Unless I'm experiencing some sort of bug anyway, but that's what it's returning for me.

[haste]

I'll consider it a bug. It would be nice if you had posted it in the bug report section on my portal tho', that way it would actually have been included in the 1.3.12 release.