a0a3574b14
Live-tested in Durotar after the herb/ore categorization fix merged and rebuilt: spawned Mageroyal almost exclusively, which is not in Durotar's configured pool (verified the live config is correct and uncorrupted -- Peacebloom/Silverleaf/Earthroot/Copper Vein). No ore appeared either, despite Copper Vein being in the list and containing the word 'vein' -- which should have matched even the pre-PR-#7 keyword heuristic, suggesting this isn't purely a categorization issue. Hypothesis: herb/ore pool building may now filter against the full set of IDs the lookup table knows about, rather than the current site's own configured entries. Flagged for direct verification against the merged code rather than assumed.
56 lines
2.6 KiB
Markdown
56 lines
2.6 KiB
Markdown
# 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.
|