Epic Damage Meter

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

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

BINDINGS.XML LOAD FIX
- First build spammed "Unrecognized XML: Binding" warnings (6x per
  line). Cause: Bindings.xml was listed in the .toc files, so the
  UI-XML parser tried to read it as a frame definition. WoW loads
  a file named Bindings.xml from the addon root AUTOMATICALLY —
  it must never appear in the TOC. Removed from all 5 TOCs (with
  a comment so it doesn't get re-added).

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.5.0.

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.

PvP Crash Fix #2: SecretValue spellID as Cast-Count Table Key
- After the cache-key fix above, a SECOND PvP crash surfaced once
  the Casts column shipped: "attempted to index a table that
  cannot be indexed with secret keys" (3x), in GetTooltipSpells.
- Root cause: the new Casts column looked up cast counts via
  resolvedCasts[spellId], where spellId came from C_DamageMeter's
  combatSpells. In PvP that spellID is a SecretValue. The guard
  `spellId and resolvedCasts[spellId]` passed (a secret is truthy)
  but the index threw, because you cannot index ANY table with a
  secret key.
- Fix: new CastCountText(castSpells, spellId) helper checks
  issecretvalue(spellId) BEFORE indexing and returns "" for secret
  or missing ids. Applied to all three cast-count lookups:
  SetBarData cache build, the DB-abilities tooltip path, and the
  C_DamageMeter on-hover 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)