Skip to content

feat(resource bars): opt-in extended Brewmaster stagger bar - #1807

Draft
diEBirne wants to merge 3 commits into
EllesmereGaming:mainfrom
diEBirne:feat/resource-bars-extended-stagger
Draft

feat(resource bars): opt-in extended Brewmaster stagger bar#1807
diEBirne wants to merge 3 commits into
EllesmereGaming:mainfrom
diEBirne:feat/resource-bars-extended-stagger

Conversation

@diEBirne

@diEBirne diEBirne commented Aug 28, 2026

Copy link
Copy Markdown

What does this PR do?

Adds an opt-in display mode for the Brewmaster stagger bar, off by default.

Stagger can already exceed 100% of max health, but the bar stops filling there, so everything above that point looks identical. With Brewmaster Monk Extended Stagger Bar enabled, the bar spans Scale steps of 100% max health (Scale 2-6, default 4). Each step gets its own fill color, and optional divider lines mark the step boundaries. The bar text still shows the real percentage of max health.

New rows in Class Resource (Brewmaster only):

  • Brewmaster Monk Extended Stagger Bar toggle
  • Scale slider (2-6), with a Scale Dividers cog for line visibility, thickness and color
  • Scale Colors multi-swatch, one color per 100% step. Steps above the current Scale are locked.

Relationship to the existing Stagger Full % (staggerCeilingPercent): both decide how far the bar fills, so they must not fight each other. While Extended Stagger is on, Scale supplies the effective ceiling and Stagger Full % in Threshold Settings is locked with an explanatory tooltip. The stored value is never written to, and it applies again unchanged the moment the toggle goes off.

Interaction with existing stagger coloring while enabled: the step colors replace threshold and multi-band coloring, since the steps already define the color bands. Dark Theme behaves exactly as it does today.

How was it tested?

Client 12.1.0.69497, EllesmereUI 9.0.7, Brewmaster Monk.

In game:

  • Default off: bar, threshold coloring, Stagger Full % and hash lines behave exactly as before.
  • On: Scale 2 / 4 / 6, divider count and positions, per-step colors, divider thickness and color, Show Divider Lines off.
  • Horizontal, Vertical Up and Vertical Down orientation; UI scale change.
  • Stagger Full % locks while on, unlocks live when the toggle flips with the Threshold Settings popup open, and its stored value is unchanged afterwards.
  • Off after on: ceiling, threshold, band and hash behavior return unchanged.
  • /reload and relog persistence.
  • Dark Theme on and off.
  • No Lua errors with /console scriptErrors 1.

Screenshots

Options with the feature on at Scale 4. Steps 5 and 6 are locked because they sit above the current Scale:

extended-stagger-options

Bar at 260% of max health, Scale 4. The fill uses the 200-300% step color and the dividers sit at 100 / 200 / 300%:

extended-stagger-bar-260

Checklist

  • New settings default OFF (no behavior change without opt-in) - brewExtendedStaggerBar defaults to false. With it off, the bar, Stagger Full %, threshold/band coloring and hash lines behave exactly as they do on 9.0.7.
  • Zero cost while disabled: no events registered, no polling, no hooks doing work, no frames built - the runtime registers no event, adds no OnUpdate and no timer. The stagger branch reads one boolean; while it is false no divider texture is ever created and the color path is untouched.
  • Cheap while enabled: event-driven (no polling, no timer-based logic, no per-frame allocations)
    The divider layout is memoized on scale, width, color, bar size, orientation, reverse fill and pixel multiplier, so UNIT_POWER_FREQUENT does not rebuild it. That memo is deliberately separate from the shared sb._tickState: the hash-line call overwrites that one, and both pools would otherwise rebuild several times a second. Divider textures use their own pool inside the existing tick overlay, so the user's hash lines keep their own color and width.
  • No writes onto Blizzard-owned frames (weak-table pattern used); HookScript/hooksecurefunc only, never SetScript on Blizzard frames - no Blizzard or secure frame is touched; every frame and texture here is EUI-owned. Secret values keep the existing handling: the step color reuses the same staggerPct the current threshold path already computes, including its last-known-good cache.
  • Tested in-game on live; no version gates or pre-Midnight APIs added.

Opening as a draft: I know feature requests are halted until a few weeks after 12.1 launch. The concept was discussed with Ellesmere on Discord beforehand, so this is here for whenever the freeze lifts, with no expectation of a merge before then.

diEBirne added 3 commits August 28, 2026 16:42
The stagger bar stops at max health (or the Stagger Full % ceiling), so a
Brewmaster cannot tell 120% stagger from 400%. Behind a Brewmaster-only toggle
that is off by default, the bar now spans a configurable Scale of 100% steps,
each step gets its own fill color, and optional divider lines mark the
boundaries.

The feature lives in the existing class-resource paths: the bar ceiling is
derived from Scale where staggerCeilingPercent was read, the step color slots
into the stagger color chain behind the buff / dark theme / recolor-text
priorities, and the divider lines reuse ApplyResourceBarTicks and the bar's
tick overlay with their own texture pool. No new runtime file, frame, event or
OnUpdate, and while the toggle is off nothing in the feature is read.

Scale never writes staggerCeilingPercent, so the stored ceiling applies again
unchanged once the toggle goes off; the Stagger Full % input is locked, not
cleared, while Extended Stagger is on.
Keep each Lua 5.1 color swatch bound to its own scale step, refresh the stock ceiling lock immediately, and invalidate divider layout when orientation or UI scale changes.
Update the shared threshold context when its frame is built so Extended Stagger can lock or unlock Stagger Full % immediately while the popup is open.
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