Epic Damage Meter

EpicDamageMeter - Changelog
============================

Version 2.4.28
--------------
Key Bindings + Report to Chat Fix + Client Updates

KEY BINDINGS (user request from guino2377)
- New configurable key bindings under
  ESC > Options > Keybindings > AddOns > "Epic Damage Meter":
    * Toggle meter window
    * Show meter window
    * Hide meter window
    * Open settings
  Each player assigns their OWN key, so nothing is hardcoded and
  no existing bind is touched — the same approach Details! uses.
- New "Start Hidden" option (Settings > General): keep the meter
  hidden on login/reload and reveal it only with your toggle key.
  This is the "set display to Never, show via keybind" request.
- Implemented via standard Bindings.xml + Core/Bindings.lua
  (localized labels, enUS + deDE). Works on all clients.

REPORT TO CHAT ("can't post data to chat" — user feedback)

REPORT TO CHAT ("can't post data to chat" — user feedback)
- The chat report now honors the segment your window is actually
  showing (Current / Overall / a past fight) instead of always
  reading the live segment. Look at Overall, click report → you
  get the Overall numbers.
- Retail fallback: when the CLEU database has no rows for the
  shown segment (data only lives in Blizzard's C_DamageMeter),
  the report now reads straight from C_DamageMeter — the same
  source the bars render from. Previously this returned "No data
  to report" and nothing got posted.
- SecretValue-safe: source names/amounts that are tainted in PvP
  are skipped rather than throwing.
- Shared code path: new EDM.UI:BuildReportData() is used by both
  the Retail and Classic report commands.

CLIENT VERSION UPDATES
- Mists of Pandaria Classic: 5.5.3 -> 5.5.4 (Interface 50504)
- TBC Anniversary 2.5.5, Retail 12.0.5, Classic Era 1.15.8
  confirmed current. All .toc Version fields bumped to 2.4.28.

PvP Crash Fix: SecretValue Taint in Tooltip Cache Key

THE BUG
- 26x error spam in PvP: "attempt to compare local 'expectedKey'
  (a secret string value, while execution tainted by
  'EpicDamageMeter')" — fired every time a bar tooltip was shown
  on a Paladin (or any player) during an arena/BG match.
- Root cause: GetTooltipSpells and SetBarData both built a
  composite cache key via string.format("%s|%s|%s|%s", tostring(
  actor.guid), ...). On WoW 12.0+ in PvP, actor.guid can be a
  SecretValue. tostring() on a SecretValue returns a SECRET
  STRING, which then made the whole expectedKey secret. The
  subsequent `bar._cachedKey ~= expectedKey` comparison tainted
  Lua execution, throwing the error 26 times in a row.

THE FIX
- New _plain() helper at both cache-key build sites: returns the
  string form only if the value is NOT secret, otherwise returns
  a fallback. Falls back to bar.plainGUID (set for the local
  player) before giving up on "?".
- Comparison hardened: if bar._cachedKey itself is somehow
  secret, treat as cache miss and reset rather than running the
  `~=` compare. Plain == plain compares are safe; only mixed-
  taint compares throw.
- Both sites fixed in one pass: SetBarData (~line 1973) and
  GetTooltipSpells (~line 2934).

WHY THIS NEVER CAUGHT IT IN PvE
- In PvE, actor.guid is always plain. The bug only triggers
  when CLEU is restricted (arena, BG) so the C_DamageMeter path
  feeds the bar with secret GUIDs/names. SecretValues are a
  12.0+ feature; older clients never had this code path.

Version 2.4.27
--------------
Heal Tooltip: Merge Absorbs

THE BUG
- Side-by-side screenshot from the user — Details! showed nine
  healing entries for a Priest, EDM only five. The missing four
  were: "Schnelle Prognose", "Machtwort: Schild" (Power Word:
  Shield — an absorb), "Kosmische Welle" and "Gebet der
  Besserung". User flagged it as "HPS zeigt net alle Werte
  korrekt an".
- Root cause: when fetching the spell breakdown for the healing
  tooltip we only queried `Enum.DamageMeterType.HealingDone`,
  which returns only the actual-heal spells. Absorb-style
  spells (Power Word: Shield, Sacred Veil, etc.) live under
  `Enum.DamageMeterType.Absorbs` and never showed up.

THE FIX
- The Healing / HPS bar tooltip cache build now queries BOTH
  HealingDone AND Absorbs and merges the two spell lists into
  a single table (keyed by spellID).
- After merging, sort the combined list by `totalAmount`
  descending so a big shield doesn't end up below a small heal
  just because the API returned heals first.
- Damage / DPS mode path untouched (single enum, same as before).

NOTE
- The "Blitzheilung 238K vs 102K" amount discrepancy in the user's
  screenshots is most likely because Details! was on a longer /
  different combat segment when the screenshot was taken — the
  per-cell percentages already diverge (43.5% vs 40.2%), so the
  underlying segment totals were different snapshots, not a bug
  in our number. After this fix the COMPLETENESS of the spell
  list matches Details!; absolute amounts only line up when both
  meters are looking at the same segment at the same moment.

Version 2.4.26
--------------
Restore working math from reference v2.4.15

User uploaded a working reference build (v2.4.15) and pointed out
that my recent "improvements" broke the math everywhere. Compared
both trees and reverted the broken logic while keeping the visual
work intact.

REVERTED TO REFERENCE
- Core/Utils.lua restored byte-for-byte. My AbbreviateNumbers-based
  ResolveNumber (v2.4.21+) was over-engineered and returned 0 for
  some SecretValues — that's why the tracker showed "0 (0 DPS)"
  during combat. The reference's simple two-path is back:
    1. Plain numbers → tonumber, done.
    2. SecretValues → pcall'd string.format("%.0f", val) followed
       by pcall'd #length + string.byte byte-rebuild.
- UI/Graph.lua Update reverted to the reference's Strategy 1
  (Database) → Strategy 2 (tracker-fed values) order. No own
  sliding-window math.
- MainFrame UpdateBarsFromDamageMeter Abbr reverted to the
  reference's Details!-style two-path (SecretValue →
  AbbreviateNumbers, plain → Utils.FormatNumber).
- MainFrame graph-publishing reverted: writes `total` (cumulative)
  to _graphDPS like the reference, not a pre-divided rate.

KEPT FROM RECENT WORK
The following visual additions don't touch the math logic and
stay in place:
- Detail Window hero header + stat pills + ranked spell rows
- Settings hero logo + tagline banner + arena theme + version
  footer + ESC menu button
- Tracker title-bar mini hero logo
- Tracker bar gloss + shadow + edge highlight overlays
- Status bar combat-time icon + warm-gold colour + accent stripes
- Empty-combatSources bail (matches reference + Details! pattern;
  removed the synthesis hack)

Lesson learned: when the reference works, copy first, modify
second.

Version 2.4.25
--------------
Revert to Details! reference pattern

User feedback: stop inventing math, follow Details! exactly. I
sourced the relevant Details! code (parser_nocleu1.lua, boot.lua
in Tercioo/Details-Damage-Meter) and reverted the divergences:

  PER-SPELL DPS (was 2.4.24 amount / session.durationSeconds)
- Details reads spell.amountPerSecond DIRECTLY from
  C_DamageMeter (parser_nocleu1.lua:760-770). No own division.
- DetailWindow.ShowSpellList, MainFrame UpdateBars cache build,
  and MainFrame GetTooltipSpells lazy path all reverted to
  reading sp.amountPerSecond and feeding it through Abbr() like
  before.

  EMPTY combatSources (was 2.4.23 local-player synthesis)
- Details bails silently when session.combatSources is nil or
  empty (parser_nocleu1.lua:1859-1866). No synthesised local
  player row, no CLEU fallback.
- UpdateBarsFromDamageMeter reverted to the same behaviour. The
  "tracker shows no data during the SecretValue phase" is a
  Blizzard API artefact — every other meter on 12.0 has the
  same brief gap, and synthesising fake data created downstream
  consistency issues (math mismatches between bar and tooltip).

What this means:
- Numbers will match Details! exactly (since we use the same
  API fields).
- If Blizzard's stock meter shows different numbers, that's
  Blizzard's UI using a different formula — not a bug we should
  paper over with our own derivation.
- Brief no-data window at combat start (under arena/BG
  SecretValue restriction) is expected behaviour now.