Nameplates: let the tank has-aggro color reach bosses that have mana - #1995
Open
dfrisone wants to merge 1 commit into
Open
Nameplates: let the tank has-aggro color reach bosses that have mana#1995dfrisone wants to merge 1 commit into
dfrisone wants to merge 1 commit into
Conversation
The caster step returns before the tank has-aggro step, and "caster" is just whether the unit has a mana pool. Step 6b already defers boss units to step 9 on purpose, so that a boss is governed by "Override Boss colors" -- but the caster return sits between the two and fires first for any boss carrying mana. The option defaults on and has never been able to reach one. Reported on Coiled Altar Malacrass, whose plate stayed on the caster color while the tank held it; the same profile colors correctly on mobs without mana. Step 8 now defers when step 9 will claim the unit, testing the same two settings step 9 tests, so a profile with the feature off takes the old path unchanged. Tank Has Aggro defaults off, so default profiles are unaffected.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What does this PR do?
A tank holding a boss saw the boss stay on the Spell Casters color instead of the Tank "Has Aggro" color, and no combination of settings could change it.
GetReactionColorresolves in numbered priority steps. Step 6b promotes has-aggro above the mini-boss/caster colors and deliberately excludes boss units, with a comment saying why: bosses are meant to be governed by "Override Boss colors" at step 9. But step 8 returns the caster color unconditionally, and it sits between the two."Caster" is
UnitHasPowerType(unit, Enum.PowerType.Mana), so it covers every boss carrying a mana pool, not just mobs that cast. For those bosses step 8 always returned first and step 9 was unreachable, which means "Override Boss colors" has never done anything for them despite defaulting on.Step 8 now defers when step 9 will claim the unit. The new guard tests the same two settings step 9 tests, so a profile with Tank Has Aggro off takes the old path unchanged. That setting defaults off, so default profiles see no difference.
How was it tested?
Reported by @Tomfoolery against Coiled Altar Malacrass: the plate stayed on the caster color while actively tanking, and the same profile colored correctly on mobs without mana. Fix confirmed in game on live by the reporter.
Also checked: losing threat still goes to no-aggro, off-tank coloring is unaffected, and turning Tank Has Aggro off reproduces the previous behavior exactly.
Non-boss casters are unchanged by design. Those are governed by "Override Mini-Boss and Caster colors", which works as documented.
Screenshots
Not included. The change moves one existing color between two existing swatches, both already user-configurable, so a screenshot shows a boss plate in whichever two colors that profile has set. Happy to add a before/after if review wants one.
Checklist
HookScript/hooksecurefunconly, neverSetScripton Blizzard frames -- N/A, no frame code touched