From c9a6bf5f582a81aa22447038028c81da012d6fa7 Mon Sep 17 00:00:00 2001 From: Claude Date: Sat, 5 Sep 2026 00:11:05 +0000 Subject: [PATCH] fix: player-anchored events never got zone-specific resources SelectSiteForPlayer() tries to anchor an event on a live player's current position FIRST (BuildEligibleSiteFromPlayer -> BuildSiteFromAnchor), only falling back to a random pick from _sites when no eligible player is available. Since there is almost always an eligible player online, this is the common path in practice -- but BuildSiteFromAnchor only reads the player's live zone/area IDs from the world state; it has no access to the NodeEntries/ BonusEntries that BuildSites() parsed from GoldRush.ZonePool into _sites. Every player-anchored event therefore got an empty NodeEntries/BonusEntries regardless of ZonePool configuration, and SpawnHotspot()'s (correct, intentional) fallback-to-global-pool logic silently kicked in every time. This is why testing in Un'Goro Crater after the v2 zone-resources feature shipped still produced Titanium Vein and Northrend herbs -- the module correctly identified the player's zone as Un'Goro (ZoneId/ZoneLabel were right), it just never looked up Un'Goro's configured resource pool to attach it to that site. Fix: after building the site from the player's live position, look up a matching entry in _sites by ZoneId and inherit its NodeEntries/ BonusEntries. A zone that's an eligible anchor but has no configured entry in _sites still correctly falls through to the global pool -- that fallback path was never the problem, only the missing lookup for zones that ARE configured. --- src/GoldRush.cpp | 24 +++++++++++++++++++++++- 1 file changed, 23 insertions(+), 1 deletion(-) diff --git a/src/GoldRush.cpp b/src/GoldRush.cpp index 782c530..9e7e873 100644 --- a/src/GoldRush.cpp +++ b/src/GoldRush.cpp @@ -487,7 +487,29 @@ private: if (!IsEligibleAnchor(player)) return {}; - return BuildSiteFromAnchor(player); + GoldRushSite site = BuildSiteFromAnchor(player); + + // BuildSiteFromAnchor only knows the player's live zone/area IDs -- it has + // no access to the per-zone NodeEntries/BonusEntries parsed from + // GoldRush.ZonePool into _sites. SelectSiteForPlayer() tries a player + // anchor FIRST and only falls back to picking randomly from _sites when no + // eligible player is available, so without this lookup, the common case + // (a live player standing in a configured zone) silently lost its + // zone-specific resources and fell back to the global pool every time -- + // exactly the bug reported after the v2 zone-resources feature shipped: + // events kept spawning the default Northrend-flavored global pool + // regardless of which zone they were actually anchored in. + for (GoldRushSite const& configured : _sites) + { + if (configured.ZoneId == site.ZoneId) + { + site.NodeEntries = configured.NodeEntries; + site.BonusEntries = configured.BonusEntries; + break; + } + } + + return site; } std::vector BuildSites(std::string const& zones) const