fix(minimap): use live Minimap:GetViewRadius() API + corrected pixel math

- Use 3.3.5a-native Minimap:GetViewRadius() (instance method) instead of
  C_Minimap.GetViewRadius (nil on 3.3.5a) with C_Minimap fallback. Returns
  116.67 at zoom 5 instead of the hardcoded 125 from the broken lookup table.
- Replace minimapWidth = (GetWidth()/2) * (mapRadius/155.52) with
  minimapWidth = GetWidth() * GetScale() / 2. The new formula yields the
  actual half-width of the visible minimap in screen pixels, the correct
  multiplier for diffX*minimapWidth when diffX is normalized by mapRadius.
- Comment out (do not delete) all QDMATH / UPDATE entering / ICON debug
  blocks as --[[ DEBUG: ... --]] for future regression investigation.
- Remove loaded debug scripts from Questie-X.toc and add to .gitignore
  (drift_test, radius_debug, spawn_calibration, etc.). Scripts preserved
  in tests/ for reference.
- Add .gitignore entries for tests/ lowercase variant (case-sensitive
  on Linux/macOS) and additional debug script patterns.
- Update CHANGELOG.md and docs/changelog.html with fix entry.
- Refresh handoff.md to reflect RESOLVED status and iteration 4 history.

Verified: pins now stay anchored to world positions across all zoom levels
on both Stock UI and ElvUI. Per-frame diffX ~0.35 yards during walking
translates to ~0.21 pixels of pin movement (correct for 1 yard of world
movement).
This commit is contained in:
Xurkon
2026-06-01 17:52:21 -05:00
parent 27c1bd6889
commit 5a112d731b
5 changed files with 188 additions and 150 deletions
+13
View File
@@ -4,6 +4,19 @@
### Bug Fixes
- **[Fix — Minimap Pin Drift: Live View-Radius API + Corrected Pixel Math]** Resolved the long-running minimap pin drift bug where quest pins appeared to "follow" the player or jump on every frame. Pins now stay anchored to their world positions across all minimap zoom levels (0-5+) and across both Stock UI and ElvUI.
- **Root Cause 1 — Hardcoded lookup table used on 3.3.5a**: `Compat/HBD.lua` was reading `mapRadius` from a hardcoded `minimap_size` lookup table calibrated for stock WoW zoom levels. The API check `C_Minimap and C_Minimap.GetViewRadius` evaluated to `nil` on 3.3.5a (and Ascension), so the broken lookup table was always used. The lookup value `minimap_size.outdoor[5] = 250` produced `mapRadius = 125`, but the actual live minimap view radius at zoom 5 is `116.67` yards (from `Minimap:GetViewRadius()`). This 6.7% error compounded across all pin offsets.
- **Root Cause 2 — Factor-of-2 in pixel math**: `minimapWidth` was computed as `(GetWidth() * mapRadius / 155.52) / 2`, mixing pixel-half-width with a yards-based scale factor. The `/ 155.52` constant was a hardcoded normalization that did not match the live API value. The math was self-inconsistent: ratio `minimapWidth / mapRadius` was `0.56` (off by ~7% from the correct `0.6`).
- **Root Cause 3 — Scale not applied to pixel dimensions**: `minimapWidth` was based on `GetWidth()` alone, ignoring `GetScale()`. When UI scale changed, the pixel dimensions reported by `GetWidth()` would diverge from the actual on-screen size, while `mapRadius` (in yards) stayed fixed. This caused drift to worsen at higher zoom levels where the ratio was most sensitive.
- **Fix (`Compat/HBD.lua` lines 337-339)**: Changed the radius API detection to use the 3.3.5a-native `Minimap:GetViewRadius()` (instance method), with `C_Minimap.GetViewRadius` as secondary fallback. The new line:
```lua
local MinimapRadiusAPI = (C_Minimap and C_Minimap.GetViewRadius) or Minimap.GetViewRadius
```
- **Fix (`Compat/HBD.lua` line 528 and line 639)**: Replaced `C_Minimap.GetViewRadius()` with `MinimapRadiusAPI(Minimap)` in both call sites, so the live API is invoked through the resolved function reference.
- **Fix (`Compat/HBD.lua` lines 536-540 and lines 653-656)**: Replaced the `minimapWidth = (GetWidth() / 2) * (mapRadius / 155.52)` formula with `minimapWidth = GetWidth() * GetScale() / 2`. The new formula yields the actual half-width of the visible minimap in screen pixels, which is the correct multiplier for `diffX * minimapWidth` when `diffX` is normalized by `mapRadius` (yards in viewport).
- **Fix (debug code preserved as comments)**: All `QDMATH` / `UPDATE entering` / `ICON` debug prints and `_G.QuestieDebugPinMath` global state in `Compat/HBD.lua` are now wrapped in `--[[ DEBUG: ... --]]` block comments. The drift bug is fixed; debug output is silent in production. The commented-out blocks are preserved for future regression investigation — to re-enable, remove the `--[[` and `--]]` markers and reload.
- **Verification**: Live `Minimap:GetViewRadius()` returns `116.67` at zoom 5. `minimapWidth = 70` (from `GetWidth()=140 * GetScale()=1.0 / 2`). `diffX * minimapWidth / mapRadius` = `diffX * 0.6`, matching the expected 0.6 pixels-per-yard scaling. Pins now stay anchored to their world positions as the player moves; the per-frame `diffX` of ~0.35 yards during walking translates to ~0.21 pixels of pin movement per frame (correct for 1 yard of world movement).
- **[Fix — Sunstrider Isle: 5 Mana Wyrm Pins Now Show Correctly]** Resolved two interacting bugs that caused only 2 pins (instead of 5) to appear for the "Slay Mana Wyrm" kill objective on Sunstrider Isle, and caused pin data to corrupt on subsequent mob kills.
- **Root Cause 1 — Learner bypassed AscensionDB protection in isSunstrider block**: `_MergeSpawnEvidence` in `QuestieLearner.lua` had an `isSunstrider` special case (lines 11061134) that wrote learner kill-evidence coords directly to `npcDataOverrides[npcId][7][3431]` WITHOUT checking `IsAscensionProtected`. This is the same bypass guard that the live-injection path (line 864) correctly checks. The result: after AscensionDB injected 5 clean coords at zone 1241, each kill event added zone 3431 learner coords that competed with (or replaced) the AscensionDB data, leaving `dbSpawns={z3431=2}` instead of `{z1241=5}`.