# mod-shared-gathering-nodes — Plan

Fun/QoL project: make herbalism/mining (and possibly other) gathering nodes non-competitive —
true post-Cataclysm behavior, where a node stays available to every nearby player and each of
them gets their own harvest, instead of the first person to click it consuming the node for
everyone else.

## Target behavior (explicitly what we want)

**True simultaneous per-player harvesting**, matching retail WoW since Cataclysm: a herb/ore
node never visibly disappears just because someone else looted it first. Every nearby player who
hasn't harvested it yet can still open it and get their own materials (subject to their own
profession skill roll), until either everyone eligible has harvested it or it naturally
times out/despawns.

This is **not** the same as, and should not be quietly downgraded to, the "fast-cycle shared
node" idea (non-consumable chest + short restock timer) that was considered and explicitly
rejected in favor of this. That approach is still one shared pool drained sequentially — closer
to a treasure chest with a short respawn than real node sharing. Don't build that instead of this
without checking back in first.

## Key technical finding: this is not achievable as a hook-only module

Researched alongside [[project_mod-quest-loot-share]] and [[project_mod-shared-kill-credit]] in
the same session. Those two worked because AzerothCore already has the right extension point
(`OnPlayerBeforeFillQuestLootItem` for creature quest loot, `OnDamage`/`OnUnitDeath` for kill
credit). Gathering nodes don't have an equivalent.

- Gathering nodes (herb/mining/etc.) are `GAMEOBJECT_TYPE_CHEST` gameobjects with **one shared
  `Loot` object** per spawned instance (`GameObject::loot` member, `src/server/game/Entities/
  GameObject/GameObject.cpp`). Whoever loots it first drains that single `Loot` object; there is
  no per-player instancing for regular (non-quest) gameobject loot anywhere in core.
- Contrast with creature quest loot, which already has exactly the per-player instancing we'd
  want here: `Loot::FillQuestLoot()` / the `PlayerQuestItems` map in `LootMgr.h`/`.cpp` generates
  an independent, filtered view of quest items for each player. No equivalent `FillGatheringLoot`
  -style path exists for gameobjects.
- There IS an existing "restock" mechanism (`GameObjectTemplate::chest.consumable == 0` +
  `chest.chestRestockTime`, handled around `GameObject.cpp` line ~780) that refills a chest's
  loot pool on a timer instead of fully despawning it. This is the "fast-cycle shared node"
  fallback mentioned above — real but not what we want as the primary design.
- Confirmed no scriptable hook lets a module intercept gameobject loot generation the way
  `OnPlayerBeforeFillQuestLootItem` does for quest items.

**Conclusion:** true per-player node sharing needs an actual core change, not just a module —
comparable in scope to the old-world-flying idea that got shelved earlier this session. It means
adding a genuinely new per-player loot-instancing path for gathering-type chests, modeled on how
`Loot::FillQuestLoot` already works for creature quest items.

## Rough shape of the real fix (not started)

1. Identify gathering nodes specifically (not all `GAMEOBJECT_TYPE_CHEST` — treasure/quest chests
   should keep today's behavior). Likely keyed off `GameObjectTemplate::chest.lockId` mapping to
   a profession-skill `Lock.dbc` entry (Herbalism/Mining/etc.), same way the client already gates
   who can even attempt to open one.
2. Add a per-player "already harvested this spawn" set on `GameObject` (mirrors
   `Loot::PlayerQuestItems`/`QuestItemList` machinery in `LootMgr.h`), instead of the single
   shared `Loot`.
3. Change the loot-fill path so each qualifying player who opens the node gets their own
   generated loot roll, independent of whether someone else already looted it.
4. Change despawn/respawn state handling (`GameObject::SetLootState` / the `GO_JUST_DEACTIVATED`
   transition) so the node doesn't disappear the moment the first player finishes — needs a
   policy for when it *does* go away (e.g., a timeout after first harvest, or once every
   currently-nearby eligible player has had a turn) to avoid nodes lingering forever.
5. Gate the whole thing behind a config flag so it's an opt-in behavior change, not a silent
   core-behavior swap.

## Status

- **v0 (2026-08-21): hello-world scaffold only**, matching the same pattern as `mod-hirelings`/
  `mod-eternal-bond`/`mod-personal-isle` v0s. Module loads, config flag reads, no gathering logic
  yet — this session's job was capturing *why* it's hard and *what* the real fix looks like, not
  building it. Deliberately shelved past this point per explicit user instruction.

## Open questions for whoever picks this up next

- Exact scope: herbalism + mining only, or also skinning/fishing/gas clouds/anything else that
  uses the same chest-loot path? User's original ask was specifically "flowers and mining etc." —
  "etc." not yet clarified.
- Despawn/lifetime policy for a node once it's been fully or partially harvested (timeout vs.
  "everyone nearby has had a turn" vs. something else) — affects both server load (nodes lingering
  longer than today) and how it feels in practice.
- Whether the skill-up roll and rare-node chance (e.g. Fel Lotus, Black Lotus) should be
  recalculated independently per player or shared/fixed per spawn — retail's actual per-player
  fairness here is worth checking before assuming "just roll independently for everyone."