yrtria/mod-gold-rush
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Compare commits

base: yrtria:28248f0fa72f690e3570772c9d92a87b3a9bc221
Branches Tags
yrtria:main
yrtria:fix/herb-pool-scoping-regression
yrtria:fix/herb-ore-category-lookup
yrtria:fix/player-anchored-site-missing-zone-resources
yrtria:feature/zone-specific-resources-v2
yrtria:docs/zone-specific-resources-spec
yrtria:fix/null-session-broadcast-crash
yrtria:fix/sholazar-area-name
yrtria:fix/review-round-1
...
compare: yrtria:fa79526eb62e5f3d108d3f89dfb3a3f035530664
Branches Tags
yrtria:main
yrtria:fix/herb-pool-scoping-regression
yrtria:fix/herb-ore-category-lookup
yrtria:fix/player-anchored-site-missing-zone-resources
yrtria:feature/zone-specific-resources-v2
yrtria:docs/zone-specific-resources-spec
yrtria:fix/null-session-broadcast-crash
yrtria:fix/sholazar-area-name
yrtria:fix/review-round-1

2 commits
28248f0fa7 ... fa79526eb6

Author SHA1 Message Date
Jess Hallsworth
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
1 changed files with 23 additions and 1 deletions
Download patch file Download diff file Expand all files Collapse all files

24
src/GoldRush.cpp
View file

@ -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<GoldRushSite> BuildSites(std::string const& zones) const