promotional bannermobile promotional banner

Vamooses Endeavors

Track your Housing Endeavor progress across all characters with a clean, theme-able interface showing tasks, completion status, and season milestones.

File Details

Vamoose's Endeavors v1.18.0

  • R
  • Apr 29, 2026
  • 594.38 KB
  • 14.6K
  • 12.0.5+2
  • Retail

File Name

VamoosesEndeavors-1.18.0.zip

Supported Versions

  • 12.0.5
  • 12.0.1
  • 12.0.0

VERIFIED (live claim, Vamoose-Khaz'goroth, cycle 7, 2026-04-29):
- Chest XP is ADDITIVE: lands directly on house favor (15798→16048) on
  claim. The "available bucket" (GetAvailableHouseXP) is unaffected
  (3232→3232). The "(additivity unverified)" hedge is removed from
  /ve status; the line now reads "tasks: N in available bucket + chest:
  250 direct to favor = total cycle XP".
- HOUSE_LEVEL_FAVOR_UPDATED delta=+chest.xp is the ONLY working detection
  path. QUEST_TURNED_IN(rewardQuestID 93262) was observed NOT to fire on
  a real claim — the chest reward "quest" is implicit (no log entry, no
  turn-in NPC). The QUEST_TURNED_IN handler is kept as belt-and-braces
  but is annotated as known-dead; load-bearing logic is in
  _DetectChestClaimViaFavorDelta.
- Two HOUSE_LEVEL_FAVOR_UPDATED events fire on each claim (~420ms apart):
  a reconciliation event with no delta, then the actual +chest.xp event.
  The `delta <= 0` guard in the favor-delta detector exists specifically
  to skip the dupe; banner comment added so it can't be "optimized" away.
- InitiativeMilestoneRewardInfo.favor still returns 0 on 12.0.5; the
  hardcoded 250 fallback is correct. Chest currency reward = 30 Community
  Coupons via gainSource=67 (CURRENCY_DISPLAY_UPDATE fires ~700ms BEFORE
  the favor event).

ADDED:
- Login active-endeavor message now appends chest status inline:
  "...10 days remaining -- chest READY (+250 XP + 30 coupons)" when
  claimable, or "...10 days remaining -- chest claimed" if already done.
  Silent when the chest is still locked (below 100%) so the message
  stays signal-only.
- /ve armchest [seconds] — opens a raw event-capture window (default 120s,
  max 1800s) so a once-a-month completion-chest claim leaves full forensic
  data in VE_DB.chestObservations even if both detection paths misfire.
  Captures BEFORE the existing OnEvent dispatcher runs, plus baseline +
  final snapshots of: GetAvailableHouseXP, coupon balance, active
  neighborhoodGUID, full initiative info, finalMilestone struct (real
  Blizzard field names: milestoneOrderIndex, requiredContributionAmount,
  rewards[]), and current chest cache state. Pairs with /ve disarmchest
  (close window early) and /ve dumpchest (opens the existing CSV-export
  copy window with a Lua-ish serialization of baseline + every captured
  event + final snapshot, so the full blob is selectable / Ctrl-A +
  Ctrl-C-able rather than chat-truncated).
- Completion-chest awareness. The 100% milestone reward (House XP + coupons)
  is now read live from Blizzard's 12.0.5 InitiativeMilestoneRewardInfo struct
  (favor field + rewardQuestID currency rewards) instead of being hardcoded.
  Surfaces in the House XP tooltip as "From tasks / Completion chest /
  Projected total", and the Info tab line updates with the live values.
- Initiative-bar chest icon pulses when the completion chest is ready to
  claim, freezes (desaturated) once claimed.
- Per-house chest claim history (account-wide). The chest is per-house
  (each house runs its own initiative + chest, claiming on one alt locks
  the chest for the whole account on that house until next cycle). Claim
  is detected via QUEST_TURNED_IN (rewardQuestID match) and persisted
  keyed by neighborhoodGUID + cycleID. Drives the "claimed" state across
  initiative cycles (IsQuestFlaggedCompleted clears each cycle and was
  unreliable). rewardQuestID 93262 is shared across all initiatives so
  the active neighborhood (not the viewed one) is used to disambiguate
  which house's chest was claimed.
- /ve status reports the ACTIVE house (where XP is earned), not whatever
  the addon UI happens to be viewing. House XP line marked "additivity
  unverified" until we observe a real claim -- debug mode now samples
  GetAvailableHouseXP before/after claim to determine empirically
  whether chest XP is additive or comes out of the available bucket.

FIXED:
- _RecordChestClaim called VE.EventBus:Fire (doesn't exist) instead of
  VE.EventBus:Trigger, causing /ve claimed and the auto-detection path
  to throw "attempt to call a nil value" on a real claim. Pre-existing
  typo, only surfaced when an actual claim happened.
- QUEST_TURNED_IN handler corrupted the viewed-house chest cache by
  mutating its neighborhoodGUID in place when the active house had no
  cached snapshot. Now shallow-clones before mutating.
- Stored cycleID = 0 (when the API hadn't yet returned a real cycle)
  could false-match every future ProcessInitiativeInfo and mark the chest
  permanently claimed. cycleID is now nil-or-positive and never persisted
  as 0.
- Removed leftover IsQuestFlaggedCompleted call in chest derivation that
  could set claimed=true between cycle rollover and DB write. VE_DB is
  the sole source of truth.
- BuildGuide function-form lines now run inside pcall with a nil-safe
  text fallback, so a tracker error can't abort the whole guide render.
- Progress bar chest pulse: SetProgress no longer recurses into
  SetChestState with stale cached state (pulse + visibility now share a
  single _ApplyChestVisuals reconciler).
- /ve unclaimed cancels the in-flight post-claim sample timer and clears
  the per-house cached chest snapshot to avoid stale-state writes.
- Combat-deferred SetChestState (PLAYER_REGEN_ENABLED queue) -- belt-and-
  braces guard against any future taint regression even though the
  rewardIcon is addon-owned.
- Replaced unicode arrows/delta in debug print() with ASCII equivalents
  (WoW font renderer doesn't handle them reliably).
- History trim uses ipairs-counted iteration instead of # on a persisted
  table.
- /ve status (alias /ve chest, /ve progress) prints initiative progress,
  XP breakdown, chest state, and claim history.
- Fallback: when Blizzard's API still returns favor=0 on
  InitiativeMilestoneRewardInfo (the 12.0.5 tooltip patch is incomplete
  for some initiatives), we fall back to the observed 250 XP value and
  flag it with a footnote.