Broker: MidnightEvents

v0.7.0-beta (2026-05-23)

Full Changelog Previous Releases

• fix(delves): fuzzy-match story name vs achievement criterion (Levenshtein <=2)
  Shadowguard Point's story annotation stayed grey even after the player
  entered the delve and opened the matching achievement page. Diagnosis:
  Blizzard's widget data has "Captured Widlife" (missing the L) while
  the achievement criterion is the correctly-spelled "Captured Wildlife".
  Exact string match failed, GetAchievementCriteriaInfo lookup returned
  nil, row fell back to the grey "unknown" color.
  Fix: keep exact case-sensitive match as the fast path, fall back to
  case-insensitive Levenshtein distance with threshold 2. Per-delve
  sub-achievements have only 3 criteria and they're always semantically
  distinct (different scenarios per delve), so a 2-edit fuzzy allowance
  can't realistically pick the wrong criterion.
  Net effect: confirmed Blizzard typos in widget text no longer block
  completion lookup. The grey fallback still happens for the legitimate
  "criteria not yet loaded" case (engagement-gated by WoW's per-
  achievement lazy-load).
  Levenshtein implementation is the standard two-row DP; input strings
  are short (~30 chars), so the O(n*m) cost is negligible.
• revert(delves): LoadAddOn doesn't pre-warm criteria; accept grey for unengaged
  Empirically verified that LoadAddOn("Blizzard_AchievementUI") at addon
  init does NOT cause WoW to populate criteria for achievements the
  player has never engaged with (commit 78b48b3 from this session
  didn't fix Shadowguard Point staying grey in the user's tooltip).
  WoW genuinely lazy-loads per-achievement criteria only on engagement
  events — running the relevant content, scrolling to the achievement
  in the UI, server progress pings. There's no documented client-side
  API to force-populate criteria for a never-engaged achievement.
  Reverting to the pre-fix behavior: grey is the honest "unknown" signal
  for delves the character has never run, kept distinct from gold
  "confirmed not done" and green ✓ "confirmed done." Once the player
  engages with that delve at least once (entering it is usually enough)
  the criteria load and subsequent renders show the definite color.
  Leaving a comment in place so future-me doesn't try the same dead-end.
• fix(delves): pre-warm achievement catalog so story colors resolve definitively
  The Bountiful Delves rows show story annotations in three colors:
  green ✓ (completed), warm gold (not done), and dim grey (unknown).
  The "unknown" state isn't a bug — it's WoW's lazy-loading of
  achievement criteria: GetAchievementCriteriaInfo returns nil for an
  achievement until the player has engaged with the relevant content
  (or the Achievement UI has been opened).
  For delves the player has never run, the per-delve "Stories" sub-
  achievement (61724–61733) stays uninitialized and our story-completion
  lookup returns nil, falling back to grey. So Parhelion Plaza renders
  gold (player has engaged with it → criteria loaded → known not done)
  while Shadowguard Point renders grey (never engaged → criteria
  absent → unknown).
  Fix: load Blizzard_AchievementUI at our own addon init. That triggers
  WoW to populate the full achievement catalog, including criteria for
  delves the player hasn't touched. By the time the tooltip first opens
  later in the session, all per-delve sub-achievements are warm and
  GetAchievementCriteriaInfo returns the actual completed boolean for
  every story criterion.
  After this fix the grey fallback should be virtually unreachable —
  every story renders either green ✓ or gold based on real data.
• polish(weeklies): color-tiered annotations + static hints for opaque names
  Two-axis change to make "This Week" easier to scan at a glance:
  1. Static hints on rows whose label doesn't immediately reveal the
     tied event. New hint field on ns.weeklies entries:
     • Stand Your Ground → (Stormarion Assault)
     • A Nightmarish Task → (Prey Hunts)
     • Lost Legends → (Legends of the Haranir)
       Other rows already self-describe (Abundant Offerings, World Boss,
       Lady Liadrin's Weekly etc.) so no hint added there.
  2. Color hierarchy for everything in parentheses:
     • Row name (white, unchanged) — the actionable label
     • Static hint + dynamic-annotation text + parens themselves
       (#909090 grey) — context / disambiguation, recedes so the
       row name reads first
     • Progress N/M (#d9c97f warm gold) — variable data the eye
       should land on within the grey wrapper
       So a Liadrin row reads as "Lady Liadrin's Weekly (Abundance
       picked, 0/2)" with the parens + "Abundance picked," in grey and
       the "0/2" popping in gold. Void Assault zone shows "(Zul'Aman)"
       in grey. Static hints render in grey throughout.
       Annotation precedence (single rule, exclusive):
     1. picks present + picksFormat = "zoneOnly" → grey "(<zone>)"
     2. picks present (default) → grey "(<choice>
        picked" + gold ", N/M" + grey ")"
     3. hint present (no picks) → grey "(<hint>)"
        Inline color codes use explicit |r close + reopen on each transition
        since WoW's |r resets to the line color rather than popping a stack.
• fix(weeklies): self-heal picks cache when quest completed before feature deployed
  Shatanaris's screenshot showed the Void Assault row reading just "Void
  Assault ✓" without the (Zul'Aman) zone annotation, despite the picks
  feature being live. Root cause: DetectWeeklyPicks's "preserve cached
  pick if still flagged complete" branch needed something to preserve —
  but Shatanaris turned in 94386 BEFORE we added the picks map to the
  voidAssaultZone entry, so the cache was never populated in the first
  place. The preserve-branch had nothing to lift forward.
  Same gap would have hit any character that completed a pool member
  between sessions where the picks schema for that entry didn't yet
  exist.
  Fix: detection is now fully self-healing — re-derives from current game
  state every refresh, with no reliance on the previous cached value.
  Adds a second-pass scan that, for any picks-flagged entry with no
  match in the active quest log, checks IsQuestFlaggedCompleted on each
  pool member. Pool members are mutually exclusive per weekly cycle (the
  player can only have/complete one), so the first complete-flagged
  member is authoritative.
  Net effect:
  * Active-in-log case: unchanged (first pass picks it up).
  * Completed-this-week case: now caught even if cache was never
  populated (no migration / no re-acceptance needed).
  * Post-weekly-reset case: cache clears correctly (neither in log nor
  flagged complete).
• polish(weeklies): show active Void Assault zone name instead of "(active zone)"
  The Void Assault row was a fixed "Void Assault (active zone)" string —
  informative-ish but didn't tell you WHICH zone is active. Same picks
  mechanism that powers Liadrin / Bonus Event detection already knows the
  active questID (94385 Eversong / 94386 Zul'Aman); just need to surface
  it.
  Add a picksFormat = "zoneOnly" switch on the entry. When set, the
  render omits the " picked" suffix and the N/M progress slot, leaving
  just the bare label — so the row reads "Void Assault (Zul'Aman)" /
  "Void Assault (Eversong Woods)" tracking whichever 94385/94386 quest
  is in the player's log or this-week-completed.
  Falls back to "Void Assault" without parentheses when neither variant
  is in the log (between weeks / hasn't picked up yet) — DetectWeeklyPicks
  preserves the cached pick across the active→completed transition so
  the zone annotation stays visible until the weekly reset clears it.
• feat(voidforge): match Void Incursion overrides by event name, not POI ID
  Sampled Shatanaris's /mediag in Zul'Aman with Void Incursion firing on
  Speakers' Rest. The Zul'Aman variant uses areaPoiID 8717 — distinct from
  the 8718 we'd hardcoded for Eversong. With no override, our progress
  probe found no StatusBar in 8717's tooltipWidgetSet (2041, text-only),
  its iconWidgetSet was nil, and the row collapsed to a muted "active"
  grey because secondsLeft (3+ days) exceeded the long-timer cap.
  Generalize by adding a by-name fallback for both overrides. The
  underlying widget set (2042) is the same across zone variants; only
  the POI ID changes. Lookup chain:
  1. ev.tooltipWidgetSet (POI's own)
  2. ev.iconWidgetSet (POI's icon overlay)
  3. ns.eventProgressWidgetSet[ev.areaPoiID] (per-POI override)
  4. ns.eventProgressWidgetSetByName[ev.name] (new — name-keyed)
  Same chain for ns.IsEventFiring: per-POI table, then name table.
  ns.IsEventFiring signature changes from (areaPoiID, progPct) to
  (ev, progPct) so the helper can introspect both ID and name. Keeps
  backward compat by detecting whether the first arg is a number or a
  table.
  Caveat documented in the firing-heuristic comment: this commit covers
  the "we missed Zul'Aman because POI ID wasn't mapped" case, but does
  NOT solve the related issue exposed by the same sample — bar at 17.2%
  during confirmed firing exceeded our < 10% lowProgress threshold. That
  firing pattern (server-triggered mid-build, no prior 100%→reset)
  isn't reliably distinguishable from a normal build cycle on bar value
  alone. Would need a separate signal (bar-value-decrease detection or
  similar) to catch reliably. Left as known limitation for now.
• fix(liadrin): add Midnight: Abundance (93890) to the pool
  Shatanaris picked "Midnight: Abundance" from Lady Liadrin this week and
  the addon failed to detect it — quest ID 93890 wasn't in our hardcoded
  pool. Confirmed via harvest data: frequency=3 (Liadrin pattern). Quest
  ID slots between Saltheril's Soiree (93889) and Stormarion Assault
  (93892), consistent with the pool's numeric clustering.
  Pool now has 9 confirmed members (was 8 after the Prey fix in dd1cbf1).
  Wowhead's documentation appears to be incomplete here — the agent
  research surfaced 8, the live harvest data has at least 9.
  Label: "Abundance" — distinct from the existing ns.weeklies "abundance"
  row (89507 Abundant Offerings, the standalone weekly event); these
  share a name but track different quests in different contexts.