Carbonite All in One (Retail & Classic)

v12.0.0-00033 (2026-05-20)

Full Changelog Previous Releases

• Quest: don't record history until server confirms turn-in
  GetQuestReward's post-hook fires when the CLIENT sends the turn-in
  attempt, not when the server accepts it. For an auto-complete quest
  with a full inventory the server rejects the turn-in -- but Carbonite
  had already called SetQuest(qId, "C", ...). That wrote a bogus
  "completed" entry into the History tab and, worse, filtered the
  quest out of the watch list (UpdateList only keeps qStatus == "W"),
  hiding the "?" autocomplete button so the player couldn't retry
  after freeing bag space.
  Defer the SetQuest("C") write to QUEST_TURNED_IN, which only fires
  on confirmed server-side turn-in. Classic Era doesn't fire that
  event, so keep the immediate write there.
  Recovery: on every RecordQuestsLog pass, if a quest is in the live
  log AND has stale "C" history AND C_QuestLog.IsQuestFlaggedCompleted
  says the server has not recorded it as completed, the "C" is a
  ghost from a pre-fix failed turn-in -- restore it to "W".
• Quest: keep ? autocomplete button visible after a failed turn-in
  When ShowQuestComplete is dismissed without finishing the turn-in
  (e.g. inventory full), Blizzard's AutoQuestPopup tracker drops the
  popup and the next RecordQuestsLog pass nils cur.IsAutoComplete in
  Carbonite's cache. The watch list render then stopped stamping
  QuestWatchAC and the ? button vanished even though the quest was
  still pending on the server.
  Mirror the live-API fallback the click handler already does:
  when the cached flag is false, re-check C_QuestLog.IsComplete and
  GetQuestLogIsAutoComplete so the ? stays visible until the quest
  is actually removed from the log.
• Quest: drop debug print from autocomplete click handler
  User-confirmed the fix is working in-game. Remove the diagnostic
  chat print added in 67d403a.
• Fix: ShowQuestComplete takes questID on retail, log index on Classic
  Carbonite called ShowQuestComplete(qIndex) at every site -- the
  QuestWatchAC ("?") button click handler and the AutoTurnInAC path.
  Blizzard's API differs between flavors:
  Classic (Wrath / MoP / etc): ShowQuestComplete(questLogIndex)
  Retail (11.x): ShowQuestComplete(questID)
  Verified in Blizzard sources:
  blizzard/mop/blizzard_uipanels_game/wrath/watchframe.lua:183
  ShowQuestComplete(questIndex)
  blizzard/retail/blizzard_objectivetracker/blizzard_autoquestpopuptracker.lua:69
  ShowQuestComplete(questID)
  On retail, passing the log index made the call silently no-op, so
  clicking the "?" did nothing visible. Now Nx.isRetail passes qId,
  all other flavors pass qIndex.
  Also takes the typ.AutoComplete shortcut from the previous commit:
  the click handler trusts the button type rather than re-checking
  the (often stale) cur.CompleteMerge / cur.IsAutoComplete flags.
  Added a one-time chat print "[Carbonite] AutoComplete ? clicked: ..."
  on the click so the user can verify the click is reaching the
  handler.
• Fix: super-track on left-click swallowed "?" autocomplete button clicks
  Follow-up to ec7d9a5 — the previous patch fixed the stale-state check
  in the watch-list click handler but missed a higher-up code path:
  OnListEvent unconditionally drove C_SuperTrack.SetSuperTrackedQuestID
  on any left-click on a button row (anything except WatchError).
  That super-track call fires first, toggling the waypoint-arrow on/off
  for the clicked quest. Once it has run, the click is effectively
  "consumed" as a tracking-toggle — the user sees the quest objective
  arrow flip on and off in the world (the "switches to quest objective
  back and forth" symptom) and never gets the autocomplete completion.
  Fix:
  * Add AutoComplete = true marker to Nx.Button.TypeData["QuestWatchAC"].
  * Skip the super-track block when typ.AutoComplete is set so the
  click falls through to the existing ShowQuestComplete branch.
  User-reported on retail. MoP Classic was unaffected because it lacks
  C_SuperTrack.SetSuperTrackedQuestID and didn't enter that block.
• Perf: throttle map title SetTitle calls from 60 hz to 15 hz with dedup
  The map title-bar XY / speed display ran every frame, allocating
  several format() strings and calling map.Win:SetTitle twice per
  frame. Player position updates from the server at ~10 hz, so 60 hz
  title refresh is wasted work and string allocation.
  Now gated to Nx.Tick % 4 == 0 (15 hz, same cadence as the nearby
  tip-throttle at Nx.Tick % 3 == 0) AND skipped when the built string
  matches the previous frame (saves work when only the cursor over-map
  changes, not the player position).
  Force-update on first call (LastTitle1 / LastTitle2 nil) so the
  title doesn't render blank during the first frames after map open.
• Perf: pool POI fetch fallbacks (or -> POI_EMPTY) and outer vPOIs
  The POI fetch path runs on every cache miss (~twice per second when
  the map is open). Two allocators trimmed:
  1. Empty-fallback tables. Patterns like:
     local areaPOIIds = C_AreaPoiInfo.GetAreaPOIForMap(rid) or
     local delvePOIIds = C_AreaPoiInfo.GetDelvesForMap(rid) or
     ...
     allocated a fresh empty table every time the Blizzard API returned
     nil (common on maps without that POI category). With 6-7 such
     fallbacks per refresh that's ~12-14 empty tables/sec.
     Replaced with a module-level POI_EMPTY sentinel protected by a
     __newindex metatable so a future bug can't accidentally mutate it.
  2. Vignette outer array. local vPOIs = {} allocated a fresh outer
     array every refresh. Pooled as POI_Pool.vPOIs. The per-vignette
     entry tables stay fresh because Blizzard's C_VignetteInfo returns
     new info tables per call and reusing them across refreshes would
     risk stale data — pooling the OUTER array is the main win.
• Perf: stop allocating two pcall closures per frame in tooltip scan
  The NXOnUpdate tooltip-scan branch wrapped #s and s ~= last in
  two inline pcall(function() ... end) calls to defend against
  secure-value taint raised on GameTooltip strings sourced from
  spell / aura tooltips. The pcall protection is correct and stays.
  What changes:
  * The wrapped operations are now file-scope helpers (_tt_lenOf,
  _tt_neq) allocated once at file load.
  * The pcall calls reference those helpers and pass args
  explicitly: pcall(_tt_lenOf, s) / pcall(_tt_neq, last, s).
  Inline function() ... end closures were being allocated every
  frame the tooltip was visible (60 / sec at typical fps) — a real
  contributor to Carbonite's per-frame allocation rate. Hoisted
  helpers preserve the secure-string taint guard with zero per-frame
  closure allocation.
• Fix: Nx.Map:GetContinentMapID re-walked the parent chain on every
  cache miss
  The zoneMapIDtoContinentMapID cache used nil to mean both "not yet
  looked up" and "looked up, no continent answer", so any mapID whose
  parent chain ended in cosmic/world (battlegrounds, the cosmic map,
  some seasonal phasings) had to walk through C_Map.GetMapInfo +
  parent recursion on every call.
  Disambiguate: store false for "looked up, no continent" so a true
  "not yet cached" entry stays distinct. Also cache the recursive
  result up the chain so deeper-than-one-level lookups also benefit.
• Fix: instance teleport snaps map to maximum zoom
  User-reported: teleporting into a dungeon / raid / scenario / garrison
  wiped whatever zoom level the user had selected and snapped the map to
  maximum zoom-in.
  Root cause: Nx.Map:GotoCurrentZone's instance branch hard-coded
  self:Move(self.PlyrX, self.PlyrY, 20, 15). Scale = 20 is "very zoomed
  in" on most modern instance maps.
  Fix:
  * Nx.Map:SetScaleOverTime (the path mouse-wheel zoom + minimap
  zoom buttons take) now captures the resulting scale into
  self._userScale.
  * GotoCurrentZone's instance branch uses self._userScale when set,
  else falls back to a sane INSTANCE_DEFAULT_SCALE of 5 instead
  of the legacy 20.
• Fix: quest "?" autocomplete click sometimes toggled tracking instead of completing
  User-reported: clicking the "?" autocomplete button on a watched quest
  sometimes toggled tracking instead of submitting the autocomplete.
  Root cause in the QuestWatch click handler: both cur.CompleteMerge
  (quest is complete) AND cur.IsAutoComplete (quest is auto-completable)
  had to be true to reach ShowQuestComplete. The existing code had a
  stale-state fallback only for IsAutoComplete; CompleteMerge had none.
  When the player turned in the last objective and clicked "?" before
  the next RecordQuestsLog pass, CompleteMerge was still false and the
  click fell through to the tracking toggle.
  Fix: at click time, when C_QuestLog is available, refresh both flags
  via C_QuestLog.IsComplete(qId) + GetQuestLogIsAutoComplete(logIdx).
  The "?" now reliably calls ShowQuestComplete whenever the live API
  agrees the quest is auto-completable, regardless of cached state.