bug: wrong-zone resources spawning after PR #7 #8
1 changed files with 56 additions and 0 deletions
56
docs/herb-pool-scoping-regression.md
Normal file
56
docs/herb-pool-scoping-regression.md
Normal file
|
|
@ -0,0 +1,56 @@
|
||||||
|
# Bug: events spawning resources from the wrong zone entirely
|
||||||
|
|
||||||
|
## Observed, live-tested after PR #7 merged and rebuilt
|
||||||
|
|
||||||
|
`.goldrush teststart` in **Durotar** spawned **Mageroyal** almost
|
||||||
|
exclusively. Mageroyal is not in Durotar's configured pool at all —
|
||||||
|
Durotar's `GoldRush.ZonePool` entry is:
|
||||||
|
|
||||||
|
```
|
||||||
|
Durotar|1618;3724;1617;3725;1619;3726;1731;2055;3763
|
||||||
|
```
|
||||||
|
|
||||||
|
(Peacebloom, Silverleaf, Earthroot, Copper Vein — verified directly
|
||||||
|
against the live config file, not corrupted.) Mageroyal (1620/3727)
|
||||||
|
belongs to a different zone's list entirely (The Barrens). No ore
|
||||||
|
(Copper Vein) appeared either, despite being in Durotar's list and
|
||||||
|
containing "vein" — a keyword that should have matched even under the
|
||||||
|
*old*, pre-PR-#7 categorization logic, which is a strong hint this isn't
|
||||||
|
purely a categorization problem.
|
||||||
|
|
||||||
|
Same no-ore symptom was also observed in Zangarmarsh (Outland) before
|
||||||
|
this Durotar test — so it isn't zone-specific.
|
||||||
|
|
||||||
|
## Hypothesis — check this first, don't assume
|
||||||
|
|
||||||
|
The live config data is confirmed correct, and the herb that *did* spawn
|
||||||
|
is a real herb from the correct global category, just from the **wrong
|
||||||
|
zone's list**. That points at a scoping bug: somewhere in how
|
||||||
|
`herbEntries`/`oreEntries` get built, the code may now be filtering
|
||||||
|
against the *entire universe* of IDs the lookup table (from PR #7) knows
|
||||||
|
about as herbs, rather than filtering `_currentSite`'s own configured pool
|
||||||
|
by category. That would explain a wrong-zone herb appearing in Durotar,
|
||||||
|
and — if there's an analogous issue on the ore side, or the ore bucket
|
||||||
|
ends up empty/never selected due to how the fix restructured the
|
||||||
|
category-split logic — could also explain the missing ore.
|
||||||
|
|
||||||
|
**Please verify directly against the actual merged code** (I haven't
|
||||||
|
re-opened the PR 7 diff for this report) exactly how the herb/ore split
|
||||||
|
is being built post-fix:
|
||||||
|
- Is it `SplitByCategory(_currentSite.NodeEntries or siteNormalPool, ...)`
|
||||||
|
— filtering the *site's own* entries by category — or did the fix
|
||||||
|
change this to build from some broader/global set?
|
||||||
|
- If the lookup table itself is being used correctly for
|
||||||
|
categorization, but something else changed which *pool* it's applied
|
||||||
|
to, that's the actual regression to find and fix.
|
||||||
|
|
||||||
|
## Testing once fixed
|
||||||
|
|
||||||
|
- Durotar: only Peacebloom/Silverleaf/Earthroot/Copper Vein should
|
||||||
|
appear, nothing from any other zone.
|
||||||
|
- Confirm ore (Copper Vein) actually shows up in Durotar, and Fel
|
||||||
|
Iron/Adamantite show up in Zangarmarsh — both were absent in testing
|
||||||
|
so far.
|
||||||
|
- Spot-check one more zone on a different continent (e.g. Sholazar
|
||||||
|
Basin) to confirm it isn't pulling in entries from unrelated zones
|
||||||
|
either.
|
||||||
Loading…
Add table
Add a link
Reference in a new issue