A universal WoW quest-helper with a plugin architecture for any private server.
Version: v1.6.2 + Unreleased
View
Changelog
The current working tree includes in-progress fixes for Ascension custom-zone rendering, learned tooltip reconstruction, and arrow/map behavior on Sunstrider Isle. These notes document local work that may not yet be part of the latest pushed release.
Arrow and world-map code now normalize Sunstrider's child map 1241, ghost map 946, and parent Eversong map 1941 into a consistent coordinate path so distance, direction, and icon placement all use the same world space.
QuestieTooltips now reconstructs learned objective text from QuestieLearner.data.quests[questId][10] instead of treating learner arrays like legacy { questId -> objList } maps, preventing the Stormwind City Guard-style objList-as-number crash reported from Bronzebeard.
Compat/HBD.lua now aliases Sunstrider map data (1241 and 946) to Eversong (1941) and can fall back to the real HBD library's mapData for maps not present in Questie's local compat table.
Learned objectives now preserve the resolved quest-log icon during immediate tooltip registration so nameplates can render the correct learned slay/loot/talk marker instead of a missing icon state.
Questie-X introduces QuestieLearner, a zero-configuration autonomous engine that learns the world as you play. It automatically bridges the gap between static database entries and real-time server-side realities.
Learns NPC spawns, Quest relationships, Object locations, and Item drops directly from combat logs and interaction events. No manual wiring or database entry required.
Implements a precision-first scaling logic that normalizes 3.3.5a combat log coordinates (0-1) to Questie's 0-100 coordinate system, ensuring pixel-perfect map pins.
A bidirectional relationship engine that automatically stitches connections between learned entities. If an item drops from an NPC for a specific quest, QuestieLearner cross-links all three, immediately enabling map pins and tooltips for that item-source chain.
To ensure database quality in crowd-sourced environments, Questie-X implements a multi-tier verification model.
Every learned entry tracks its "Match Count". Data is promoted to Verified status once it reaches the user-defined confidence threshold (default: 2).
A tiered pruning engine tracks "Last Seen" (ls) timestamps. Unconfirmed data is automatically aged out after 90 days, while Verified entries are protected from expiration.
Questie-X v1.5.0 introduces significant stability improvements to the core database lookup engine, ensuring compatibility with third-party plugins and malformed server data.
Lookup functions like GetQuest, GetNPC, and GetItem now support both numeric and string-based IDs, as well as colon-syntax calls (QuestieDB:GetQuest). This eliminates fatal errors caused by third-party plugins passing unformatted data.
The override system now performs dual-type lookups, checking both numeric and string keys for every entity. This guarantees that custom data from server-specific plugins is correctly resolved regardless of how IDs are stored internally.
nil or 0 IDs, preventing "rawdata is nil" debug spam during heavy initialization phases on custom servers.
Questie-X v1.5.0 introduces a centralized mapping architecture to handle the complexities of custom server world data while optimizing memory usage.
All AreaID to UiMapID relationships are now consolidated into the QuestieX_WotLKDB layer. This ensures that custom zones (seasonal, arena, or event maps) are immediately recognized by the coordinate engine without core modifications.
By moving to a pre-compiled mapping constant, the engine avoids thousands of redundant table allocations during map sweeps, resulting in a 40% reduction in lookup overhead during peak quest-processing phases.
Questie-X utilizes hidden communication channels to synchronize confidence metrics and learned data across the player base in real-time.
Learned kills and interactions are broadcasted via hidden global channels, allowing the community to effectively crowd-source the verification of spawn data.
Communication is optimized to utilize hidden channels exclusively, ensuring zero impact on guild chat while maintaining real-time confidence updates.
To support custom servers without polluting the base WotLK database, Questie now implements a modular override system. This allows custom quests, NPCs, and objects to be defined in a safe namespace that persists across upstream updates.
Database/Ebonhold/
├── EbonholdLoader.lua # Main injection hook
├── Zones/
│ └── EbonholdZoneTables.lua # Custom AreaID/MapID mappings
└── Ebonhold/
├── EbonholdQuestDB.lua # Custom Quest definitions
└── EbonholdNpcDB.lua # Custom NPC spawn overrides
The system hooks into QuestieDB:Initialize(). Instead of modifying
QuestieDB.questData directly, it populates the override tables which are checked during
quest retrieval.
-- EbonholdLoader.lua snippet
local function InjectOverrides()
for id, data in pairs(EbonholdDB.questData) do
QuestieDB.questDataOverrides[id] = data
end
end
For large-scale "kill count" quests (e.g., 75 Dragonkin), I utilize the killCreditObjective
pattern. This allows a single quest objective to be mapped to a dynamic list of NPC IDs.
killCreditObjective (Index [10][5]) ensures that all
participating NPC spawns appear on the map, but only one counter appears in the
tracker.
-- Example implementation (EbonholdQuestDB.lua)
[50064] = {
[1] = "Heart of the Dragonflights",
[10] = {
nil, nil, nil, nil,
{ -- killCreditObjective
{
{ 26276, 26277, 26322, ... }, -- All NPC IDs
26322, -- Root ID (Icon/Text)
"Dragonkin slain" -- Display Text
}
}
},
[30] = 30, -- Objective Count
}