Epic Damage Meter

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

Version 2.24.0
--------------
Change: Uptime Is A Share Of The Fight, And Deaths Are Listed Individually

Both from user feedback, and both checked against the reference meter
first — neither is an invention.

Uptime percentage

The percent column treated uptime like damage: your share of your own
auras, summing to 100%. Five debuffs each held up the entire fight would
read 20% apiece. What the metric is actually for is "how much of the
encounter did I keep this on the boss", so Rake at 98% means 98% of the
fight.

The reference computes uptime percent as uptime divided by combat time,
both in its report lines and in its tooltip, which reads
"1m 23s (98.4%)". Ported: the bar percentage and the per-spell tooltip
rows for Buff Uptime and Debuff Uptime are now relative to the fight,
capped at 100%.

Deaths listed individually

A player who died three times was one bar reading x3, which loses what
killed them the first time and where in the fight each death happened.
The reference lists deaths one per row, ordered first to last, with the
time of death on the row. Ported:

- One bar per death, in chronological order.
- The row shows when it happened rather than a meaningless "1".
- The tooltip recaps THAT death, not whichever was most recent.

This needed a wall-clock anchor on the segment: combat-log timestamps
and the existing start time use different clocks and cannot be
subtracted from each other. Fights recorded before this update have no
anchor, so their rows fall back to showing the death's ordinal.

Version 2.23.0
--------------
Fix: Tooltips And Clicks Answered "Damage Done" In Other Categories

Reported from MoP: switch to a category like Potions, hover a bar or
click a name, and you get that player's damage breakdown — as if the
window were still on Damage Done, with nothing saying so.

Both halves had the same shape. The bar tooltip branched on the display
mode for Deaths, Interrupts, Dispels, Enemy Damage Taken and Casts, and
everything else fell through to the damage/healing summary. The
breakdown browser's mode table had entries for most modes and a final
"else" returning the damage view, which every unlisted mode landed in.

- The browser's mode table gained the missing entries: Potions, CC
  Breaks, Resurrects, Deaths, Friendly Fire, Healing Received, Enemy
  Damage Taken, Threat and Activity. Each now ranks by its own field
  instead of by damage.
- The bar tooltip reports the metric that is actually on screen for
  every remaining mode, with per-spell rows where the data exists
  (potions used, defensive cooldowns, buff and debuff uptime). Labels
  reuse the already-translated mode names, so all six languages are
  covered without new strings.

Potions is the one the report named; it was one of nine, not one of
four or five.

One deliberate omission: the potion list stores a bare count per spell
rather than a row table, so the browser ranks it by total potions used
without a sub-list. The tooltip does show the per-potion rows, since it
can handle both shapes.

Version 2.22.1
--------------
Change: Combat End Is A One-Shot, And Retail Had The Same Bug

Read the reference meter's combat-end routine after shipping 2.22.0. Two
things it does that are worth having, and one bug it exposed here.

- Its whole leave-combat routine is guarded by a single flag: if the
  combat is already closed it returns immediately, otherwise it marks it
  closed and proceeds. That is one authority for "this fight is over"
  rather than the scattered checks 2.22.0 added, and it protects
  everything in the routine, not just the duration. Adopted.
- It also locks every actor's timer at combat end, so nothing can extend
  a finished fight's clock. Same intent as freezing the duration here.
- Dropping the per-actor event buffer at combat end, which 2.22.0 did
  for memory, turns out to be exactly what the reference does — it hands
  its equivalent buffer to the garbage collector at the same point. Ours
  simply never did.

The bug: the Retail combat path had the same double-count as Classic and
in a less guarded form — it re-stamped the segment's start on every
combat start with no conditions at all, and added the Core-level combat
span to the segment on every combat end without checking whether the
fight was already finished. Both now behave like the Classic path.

One correction to 2.22.0: freezing the clock on endTime was wrong.
endTime is stamped at every combat end, including trash that resumes
inside the same segment, so it would have stopped a running fight's
timer mid-pull. Only the closed flag freezes it now.

Version 2.22.0
--------------
Fix: DPS Collapsing At The Moment The Boss Dies

Reported from Siege of Orgrimmar: DPS tracks Warcraft Logs for the whole
fight, then drops by roughly two thirds the instant the boss dies —
everyone at once, proportionally. That is the signature of the divisor
changing, not the damage, and the fight time was being counted twice.

The sequence, which is why it only happened sometimes:

- ENCOUNTER_END closes the segment and finalizes its duration.
- Combat usually has not actually ended — leftover adds, pets, dots — so
  PLAYER_REGEN_DISABLED fires again moments later.
- That re-entry stamped the segment with self.combatStartTime, which
  still held the ORIGINAL pull time, not the current moment.
- When combat finally dropped, the end handler added "now minus pull
  time" on top of the already-final duration: the entire fight, counted
  a second time. Twice the duration, half the DPS. With two such
  re-entries, a third of it.

If nothing re-engaged after the kill, none of this happened and the
number stayed correct — hence "sometimes".

Three changes, all pushing toward how the reference meter models time
(one span, start to end, fixed once the fight is over):

- A re-entry stamps the current moment, never a stale pull time, and
  never onto a segment that has already ended.
- The combat-end handler only accumulates while the segment is still
  open. A boss that is already dead keeps its final number.
- GetSegmentDuration returns the stored duration outright once the
  segment has an end time, so no leftover state can make a finished
  fight's clock keep running.

Fix: Memory Growth Across A Raid Night

Also reported: a few MB when idle, 10-20 MB in dungeons, but 200 MB+
deep into a raid. Every actor carries a rolling buffer of recent
damage/heal events, kept only so a death recap can be snapshotted from
it — and RecordDeath already copies what it needs into the death entry.
The buffer was never released, and up to 25 finished fights stay in
memory. In a 25-player raid that is 25 fights times 25+ actors times a
full event buffer each, almost all of it unreachable by any UI (nothing
reads the buffer after the fight; the recaps read their own copies).

Those buffers are now dropped when a fight finishes — both at
ENCOUNTER_END and when a new pull supersedes the previous segment, since
trash pulls never produce an encounter event and a raid night is mostly
trash. If memory still runs high, lower "Max Segments" under Combat;
that is the setting that decides how many finished fights are retained.

Version 2.21.4
--------------
Fix: The Real Cause Of The Stuck "Waiting For Combat"

/edm dm settled it: the API was fine all along. Current/DamageDone had a
source, Overall had five, and every name came back secret — a normal PvP
situation. So the data was there and the render was throwing.

The throw was mine, from 2.21.0. Splitting the bar text into three parts
assembled the result with table.concat. Two lines above it sits a
comment stating that AbbreviateNumbers returns a ConditionalString for a
SecretValue and that string.format handles those — table.concat does
not, it raises. I replaced the safe assembly with the unsafe one and did
not read the note explaining why it was written that way.

- The Retail value text is assembled through string.format again, one
  part at a time. Bars render in PvP again.
- The pcall around the render no longer swallows the failure into a
  debug channel that is off by default. It goes to the error log, which
  always records and shows up in /edm diag. That silence is why this
  looked like an API problem for three releases: a crash and "no data"
  both end in the empty state, and nothing distinguished them.

The other combination in that dump is correct and not a bug:
Current/HealingDone has no sources, so the healing window is legitimately
empty for a character that is not healing.