Skip to content

Report absolute HPS for specs that model it - #1790

Open
DIzosimov wants to merge 1 commit into
Voulk:devfrom
DIzosimov:absolute-hps-reporting
Open

DIzosimov wants to merge 1 commit into
Voulk:devfrom
DIzosimov:absolute-hps-reporting

Conversation

@DIzosimov

Copy link
Copy Markdown

Third of three, split out of #1787 following review. Independent of the other two.

Noting up front: the review raised a preference not to emphasise overall HPS numbers, since the model produces one but in-game results vary a lot. That's a fair product call and this PR is the one to reject or trim if you'd rather not surface it — the other two don't depend on it. Posting it because there's a real bug underneath regardless (see below).

The bug that exists today

The competitive alternatives list prints a hardScore delta labelled "HPS". hardScore is an intellect-equivalent ranking number, not healing, so that label is simply wrong. It predates this change. Even if the HPS display isn't wanted, that label should be corrected.

What this adds

Sets evaluated through a cast model or a ramp sim now carry setHPS, a genuine healing figure from the same evaluation that ranks them. It's shown on the stat panel with an upgrade percentage over currently-equipped gear, and per alternative alongside the healing and percentage given up. The percentage is derived from the HPS figures themselves, so the two can't disagree.

The stat weight path deliberately reports nothing rather than a fabricated number. baseHPS there is a hardcoded placeholder, and that path pre-applies raid buffs which the cast models also apply internally, so anything derived from it would be wrong. Those specs keep the existing relative display.

Design notes

  • The equipped set is evaluated through the same evalSet as the candidates, so the two figures are comparable rather than one being modelled and the other a baseline constant.
  • It runs outside the ranking loop and can never influence which set wins.
  • It's wrapped so a malformed equipped set costs the upgrade percentage, not the whole run.
  • A dead-on 0% — which happens when Top Gear is run without adding any candidate items, so the best set is simply the player's current gear — now says so instead of reading like the comparison failed.
  • The percentage renders negative correctly, for the case where the built set is worse than what's equipped.

Testing

41 suites / 204 tests passing, production build clean. The suite asserts the figure is throughput rather than the ranking score, that alternatives never out-heal the chosen set, and that the derived percentage is consistent with the raw healing gap.

hardScore is an intellect-equivalent ranking number, so the report could only ever show relative differences - and
the competitive alternatives list was printing a hardScore delta labelled "HPS", which it isn't.

Sets evaluated through a cast model or a ramp sim now carry setHPS, a genuine healing figure. It's shown on the
stat panel with an upgrade percentage over currently equipped gear, and per alternative alongside the healing and
percentage given up. The percentage is derived from the HPS figures themselves so the two can never disagree.

The stat weight path deliberately reports nothing rather than a fabricated number. baseHPS there is a hardcoded
placeholder, and that path pre-applies raid buffs which the cast models also apply internally, so anything derived
from it would be wrong. Those specs keep the existing relative display.

The equipped set is evaluated through the same evalSet as the candidates so the two figures are comparable, and
deliberately outside the ranking loop so it can never influence which set wins. It's wrapped so that a malformed
equipped set costs the upgrade percentage rather than the whole run. A dead-on 0% - which happens when the player
runs Top Gear without adding any candidate items, so the best set is simply their current gear - now says so
instead of reading like the comparison failed.

41 suites / 204 tests passing.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E5STi454aLVN1cAsYyba3J
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