Merge pull request 'bug: wrong-zone resources spawning after PR #7' (#8) from fix/herb-pool-scoping-regression into main

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

@@ -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

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.

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<std::string_view> SplitZonePool(std::string_view zones)
+{
+    std::vector<std::string_view> 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<GoldRushSite> 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())