Compare commits

..

2 commits

Author SHA1 Message Date
fa79526eb6 Merge pull request 'fix: player-anchored events never got zone-specific resources' (#6) from fix/player-anchored-site-missing-zone-resources into main
Reviewed-on: #6
2026-09-04 18:13:14 -06:00
Claude
c9a6bf5f58 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.
2026-09-05 00:11:05 +00:00

View file

@ -487,7 +487,29 @@ private:
if (!IsEligibleAnchor(player)) if (!IsEligibleAnchor(player))
return {}; 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<GoldRushSite> BuildSites(std::string const& zones) const std::vector<GoldRushSite> BuildSites(std::string const& zones) const