Narcasung/Questie-X
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

fix(map): unload completed-objective pins deterministically

Browse Source 
Completed objectives could leave their map/minimap pins on screen until
turn-in. Pin removal relied solely on _UnloadAlreadySpawnedIcons, which
walks objective.AlreadySpawned; that table desyncs from the live frames
after learner spawn-list invalidation or complete->abandon->reaccept
cycles, so when reset to {} the frames leaked.

Add QuestieMap:UnloadQuestFramesForObjective(questId, objectiveIndex)
which unloads frames off the map's own questIdFrames registry by matching
frame.data.ObjectiveIndex, and call it from every completion path in
PopulateObjective. Restricted to positive standard-objective indices;
SpecialObjectives (sentinel index 0) keep using AlreadySpawned.
This commit is contained in:
Xurkon
2026-06-09 17:01:34 -05:00
parent bd16c59681
commit 8137d90ff6
3 changed files with 26 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
CHANGELOG.md
+1
View File
@@ -22,6 +22,7 @@
### Bug Fixes
- **[Map - Completed Objective Pins Linger]** Added `QuestieMap:UnloadQuestFramesForObjective(questId, objectiveIndex)` and call it from every completion path in `QuestieQuest:PopulateObjective` (objective completed, hidden by `ShouldHideObjective`, and static no-`Update` objectives). Previously, removing a completed objective's map/minimap pins relied solely on `_UnloadAlreadySpawnedIcons`, which walks `objective.AlreadySpawned`. That table desyncs from the frames actually on screen after learner spawn-list invalidation or complete→abandon→reaccept cycles, so when it was reset to `{}` the live frames leaked and pins for fully-completed objectives (e.g. 6/6 kills, a collected item objective) stayed on the map even though tooltips updated correctly. The new function unloads frames deterministically off the map's own `questIdFrames` registry by matching `frame.data.ObjectiveIndex`, so completed-objective pins are removed regardless of `AlreadySpawned` state. Restricted to positive standard-objective indices; SpecialObjectives (sentinel index 0) keep using `AlreadySpawned` to avoid cross-unloading siblings.
- **[QuestieLib - GetColoredQuestName Nil Guard]** Added a nil guard in `QuestieLib:GetColoredQuestName` so a synthetic `questId` (e.g. one used in a chat link on servers that do not have a real quest entry) no longer crashes with `attempt to index a nil value`. The function now checks `QuestieDB.GetQuest(questId)` before reading its `isComplete` flag.
- **[Tooltip - Item Flicker on ElvUI Refresh]** Simplified the `AddItemDataToTooltip` redraw check to key purely on `itemId`. The previous condition also re-keyed on tooltip name, line count, and frame name — all of which ElvUI's tooltip-frame recycling transiently resets, so every refresh cycle looked like a new item and caused Questie's lines to flicker repeatedly. The new condition only re-adds when the actual itemId changes, so the tooltip stays stable across ElvUI's refresh ticks.
- **[Tooltip - First-Hover Resize Pop]** Removed the unconditional `QuestieTooltips:ResizeTooltip(self)` call from `AddItemDataToTooltip`. With the flicker fix in place, the resize pass still fired once per item hover and triggered ElvUI's smooth-resize animation, causing a visible frame pop on first hover. ElvUI already manages tooltip sizing correctly, so the Questie resize call is no longer needed for item tooltips.