When UpdateNearestTargets uses ZoneDB:GetAreaIdByUiMapId(946) to verify
player zone, it returns 668 (Northshire) instead of 3430 (Sunstrider).
UiMapIdOverrides[946] was set to 668 for Northshire, so 946 always
resolves to Northshire's areaId even on Sunstrider Isle.
Added direct cache entries for both 1241→3430 and 946→3430 in the
uiMapIdToAreaIdCache (the fast-path lookup table) so GetAreaIdByUiMapId
returns the correct Sunstrider Isle areaId regardless of which map ID
the game returns.
Root cause: creatureLevels entry for 'Uneasy Citizen' was {} (empty table)
instead of {minLevel, maxLevel, rank}, so creatureLevels[name][1] was nil.
Added early-return guard in _GetLevelString: if creatureLevels[name] is
falsy or has no numeric level at index [1], return name unchanged.
Also updated CHANGELOG.md [Unreleased] section with this fix.
- zoneDB.lua: Add [946] = 3430 to UiMapIdOverrides so GetCurrentZoneId()
returns 3430 (Sunstrider Isle areaId) even when the game returns uiMapId 946
(ghost/loading map). Previously 946 had no override, causing zone lookups to
fall through and return 946 instead of the real zone, breaking arrow distance
calculation and target filtering.
- QuestieArrow.lua: UpdateNearestTargets uses QuestiePlayer:GetCurrentUiMapId()
(backed by C_Map.GetBestMapForUnit) for player position. When that returns an
invalid/ghost map (946/947/0), fall back to ZoneDB lookup via the actual
zoneId. This ensures the arrow gets real world coordinates regardless of
whether the world map is open or closed.
Also includes per-frame debug output when debugArrow profile is enabled.
- Tooltip.lua: Add type guard 'if type(objList) ~= table then break end'
before iterating learnedNpc[10] and learnedObj[10] in both m_/NPC and o_/object
paths. Prevents 'attempt to index field questData (a string value)' error
when the questData field is unexpectedly a string instead of a table.
The original loop used 'for questId, objList in next, learnedNpc[10]' which
iterates key-value pairs in insertion order. The _AddToArray helper stores
values as sequential array elements (tbl[key]=value via table.insert), but
the iteration was treating it as a questId->objList map. Fixed to use
ipairs-style iteration with a type check for robustness.
Demote GetQuest/GetQuestObjectives 'quest doesn't exist in QuestLogCache'
messages from Questie:Error to Questie:Debug(DEBUG_DEVELOP). These were
firing repeatedly in chat for quest IDs like 595, 959, 254048 during normal
play. Messages are now only visible when developer debug mode is active.
- Remove Questie-X-Turtle.toc (Turtle WoW shut down)
- Remove skills-lock.json (dev lock file)
- Remove .luarc.json (Lua LSP config)
- Add all three to export-ignore in .gitattributes
- Add all three to .gitignore
- Remove Questie-X-TurtleDB from OptionalDeps in Questie-X.toc
- SetObjectivesDirty: Add missing loop to reset isUpdated on SpecialObjectives
- PopulateObjective: Add completion guard for objectives without Update fn
- Bump version to 1.6.1 across TOC and changelogs
Previous guard only checked LSM30 ~= nil; if Fetch method is absent on
the stub object the call still crashes. Now uses full 3-part check:
(LSM30 and LSM30.Fetch and LSM30:Fetch(...)) or fallback
Matches the pattern already used in QuestieArrow.lua.
- Use LibStub(..., true) silent flag on all LSM acquisition sites
- Guard HashTable() calls in Options files (returns nil if no font type registered)
- Guard all Fetch() call sites with inline 'LSM30 and LSM30:Fetch() or fallback'
- Make font values lazy functions in options dropdowns so LSM has time to register
- Affects: QuestieOptionsTracker, QuestieOptionsArrow, QuestieArrow, QuestieTracker,
TrackerHeaderFrame, TrackerLinePool, TrackerQuestTimers
Root cause: _LoadCorrections writes to QuestieDB.objectData (binary DB companion) but GetObject reads from QueryObject binary handle + objectDataOverrides. Items in Load() path are patching the binary DB so never reach GetObject's override check. Moving 176213 to LoadFactionFixes puts it directly in objectDataOverrides, the path GetObject actually reads.
Xurkon