Skip to content

[Feat] Raid Frames: inverted health bars for raid and party frames - #2061

Open
Irame wants to merge 1 commit into
EllesmereGaming:mainfrom
Irame:feat/raid-frame-inverted-bars
Open

[Feat] Raid Frames: inverted health bars for raid and party frames#2061
Irame wants to merge 1 commit into
EllesmereGaming:mainfrom
Irame:feat/raid-frame-inverted-bars

Conversation

@Irame

@Irame Irame commented Sep 11, 2026

Copy link
Copy Markdown

What does this PR do?

Adds an "Invert Health Fill" toggle to the Health Bar Fill cog on the raid
frames, next to Vertical Fill. With it on, the bar texture paints MISSING
health and current health is left to the background, so a frame reads as "how
much damage has been taken" rather than "how much health is left". Off by
default, so nothing changes for anyone who does not turn it on.

Works on both fill axes and on raid, party, extra and friendly boss frames, in
the live frames and in the options preview. The key sits in the healthBar
party-sync section, so an unsynced party tab keeps its own value.

How was it tested?

In game, on raid and party frames, with the toggle on and off:

  • Both fill axes, and both combined with Vertical Fill.
  • Absorb styles (overlay / blizzardModern), heal prediction, heal absorb, dead and out-of-range states.
  • Party tab synced and unsynced against the raid tab.
  • Options preview in every preview mode, raid and party preview.

While testing I found two seemingly unrelated bugs:

Screenshots

Before:

Raid (preview):

Screenshot_20260911_180928

Party:

Screenshot_20260911_181636

After:

Raid (preview):

Screenshot_20260911_181021

Party:

Screenshot_20260911_181302

Checklist

  • New settings default OFF (no behavior change without opt-in)
  • Zero cost while disabled: no events registered, no polling, no hooks doing work, no frames built
  • Cheap while enabled: event-driven (no polling, no timer-based logic, no per-frame allocations)
  • No writes onto Blizzard-owned frames (weak-table pattern used); HookScript/hooksecurefunc only, never SetScript on Blizzard frames
  • Tested in-game on live; no version gates or pre-Midnight APIs added

Implementation note for review

This is SetReverseFill plus an inverted percent, not a swap of the two textures. The seam -- the current-HP point -- therefore stays at the same coordinate either way and only the side the fill paints on changes. That gives the rule the whole diff follows: every overlay anchored to the fill's LEADING EDGE moves from its RIGHT/TOP to its LEFT/BOTTOM, and every anchor on the health FRAME's edges is left alone. Absorb backfill and forward bars, the filled/missing clip frames, heal absorb, heal prediction and the bar background are re-anchored on that basis. SetReverseFill is owned by RF_ApplyHealthOrientation next to SetOrientation, which now returns both flags so callers take the returns instead of re-reading the setting.

The options health-animation ticker also moves from PvEffectiveProfile to the
new party-aware PvSettings, which fixes smoothBars being resolved raid-side
only in the party preview.

Adds a "Invert Health Fill" toggle to the Health Bar Fill cog, next to
Vertical Fill. When on, the bar texture paints MISSING health and current
health is left to the background, so a frame reads as "how much damage has
been taken" rather than "how much health is left".

Implemented as SetReverseFill plus an inverted percent, not as a swap of the
two textures. The seam -- the current-HP point -- therefore sits at the same
coordinate either way; only which side of it the fill paints changes. That
gives the rule the whole change follows: every overlay anchored to the fill's
leading edge moves from its RIGHT/TOP to its LEFT/BOTTOM, and every anchor on
the health FRAME's edges is left alone. Absorb backfill and forward bars, the
filled/missing clip frames, heal absorb, heal prediction and the bar
background are all re-anchored on that basis, on both fill axes, in the live
and preview paths.

SetReverseFill is owned by RF_ApplyHealthOrientation alongside SetOrientation,
which now returns both flags so callers take the returns instead of re-reading
the setting. Both are applied in the restyle/style passes only; the per-tick
value paths set the value and nothing else.

The key is registered in the healthBar party-sync section, so an unsynced
party tab keeps its own value. Defaults to false; so no migration is needed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant