From a0a3574b142fcf4a17f998372fe2b53090c78b84 Mon Sep 17 00:00:00 2001 From: Claude Date: Thu, 10 Sep 2026 01:45:19 +0000 Subject: [PATCH 1/2] docs: report wrong-zone resource spawning after PR #7 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. --- docs/herb-pool-scoping-regression.md | 56 ++++++++++++++++++++++++++++ 1 file changed, 56 insertions(+) create mode 100644 docs/herb-pool-scoping-regression.md diff --git a/docs/herb-pool-scoping-regression.md b/docs/herb-pool-scoping-regression.md new file mode 100644 index 0000000..977d22c --- /dev/null +++ b/docs/herb-pool-scoping-regression.md @@ -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. -- 2.49.1 From 5ffac92934a7bcf6f9d8766871d1e99e495f803f Mon Sep 17 00:00:00 2001 From: "Troll (Hermes Agent)" Date: Thu, 10 Sep 2026 02:15:44 +0000 Subject: [PATCH 2/2] fix: zone pool parser truncated every zone to its first entry GoldRush.ZonePool separates zones with '; ' (semicolon + space) but the node/bonus entry IDs within a zone with a bare ';'. BuildSites() split on the bare ';', so each zone's entry list was cut down to its first ID -- which is always a herb. That is why events spawned a single wrong-zone herb and no ore at all (PR #8). Split on the two-character '; ' zone delimiter instead, so every zone keeps its full node and bonus pools. --- CHANGELOG.md | 7 +++++++ src/GoldRush.cpp | 29 ++++++++++++++++++++++++++++- 2 files changed, 35 insertions(+), 1 deletion(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 7421500..f86e6bd 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -17,6 +17,13 @@ All notable changes to `mod-gold-rush` will be documented in this file. global `GoldRush.NodeEntries` pool exactly as before. ### Fixed +- Zone pool parsing no longer truncates every zone to its first resource entry. + `GoldRush.ZonePool` separates zones with `"; "` (semicolon + space) but the + node/bonus entry IDs within a zone with a bare `";"`. `BuildSites()` split on + the bare `";"`, so each zone's entry list was cut down to its first ID — which + is always a herb. That is why events spawned a single wrong-zone herb and no + ore at all (reported in PR #8). The parser now splits on the two-character + `"; "` zone delimiter, so every zone keeps its full node and bonus pools. - Herb/ore categorization no longer guesses from display-name keywords. The old `SplitByCategory()` matched "lotus"/"clover"/"thorn"/"bloom" for herbs and "vein" for ore, which only worked for the original Northrend default pool and diff --git a/src/GoldRush.cpp b/src/GoldRush.cpp index 99f94ce..e8837a0 100644 --- a/src/GoldRush.cpp +++ b/src/GoldRush.cpp @@ -196,6 +196,33 @@ static AreaTableEntry const* ResolveAreaEntry(std::string const& areaName) return nullptr; } +// The GoldRush.ZonePool value separates zones with "; " (semicolon + space) and +// the node/bonus entry IDs within a zone with a bare ";". Acore::Tokenize only +// splits on a single character, so splitting on ';' cut every zone's entry list +// down to its first ID -- the bug behind the wrong-zone/incomplete resource +// spawning reported after PR #7 (every zone's first entry is a herb, so ore +// never appeared and only one herb type spawned). Split on the two-character +// zone delimiter instead. +static std::vector SplitZonePool(std::string_view zones) +{ + std::vector result; + size_t start = 0; + while (start < zones.size()) + { + size_t end = zones.find("; ", start); + if (end == std::string_view::npos) + { + result.push_back(zones.substr(start)); + break; + } + + result.push_back(zones.substr(start, end - start)); + start = end + 2; // skip the "; " delimiter + } + + return result; +} + class GoldRushManager { public: @@ -568,7 +595,7 @@ private: // area labels, change this parser to expect 4 segments and adjust // BuildLocationText/FormatLocationForAnnouncement accordingly. std::vector sites; - for (std::string_view zoneToken : Acore::Tokenize(zones, ';', true)) + for (std::string_view zoneToken : SplitZonePool(zones)) { std::string token = Trim(std::string(zoneToken)); if (token.empty()) -- 2.49.1