fix(DB/Loot): Fix incorrect loot pool structure for 9 Naxxramas 25-man bosses

[espkk]

Changes Proposed:

This PR proposes changes to:

• Database (SAI, creatures, etc).

Fixes incorrect loot pool structure for 9 Naxxramas 25-man bosses.

Wowhead/wowdb 25-man drop data shows a clear bimodal distribution for all 24-item bosses:

• 15 boss-specific items cluster around ~20% (= 1/5 per pool)
• 9 shared items cluster around ~11-13% (= 1/9 per pool)
  This is only possible if boss items and shared items are in separate pools of different sizes. A single flat pool of 24 with 4 picks gives 16.7% uniform.

chromiecraft/chromiecraft#9131 provided kill-by-kill co-occurrence data for Anub'Rekhan, revealing an asymmetric 5+4+5+9 structure. For all other bosses 5+5+5+9 pools are used:

Boss	Entry	Reference	Pools	Shared Pool Type
Anub'Rekhan	29249	34137	5+4+5+9	Jewelry
Grand Widow Faerlina	29268	34138	5+5+5+9	Jewelry
Maexxna	29278	34139	5+5+5+9	Cloaks/Trinkets
Noth the Plaguebringer	29615	34147	5+5+5+9	Jewelry
Heigan the Unclean	29701	34148	5+5+5+9	Cloaks/Trinkets
Instructor Razuvious	29940	34144	5+5+5+9	Jewelry
Gothik the Harvester	29955	34145	5+5+5+9	Cloaks/Trinkets
Patchwerk	29324	34140	5+5+5+9	Jewelry
Grobbulus	29373	34141	5+5+5+9	Cloaks/Trinkets

Effectively, this increases the drop rate of non-shared items and decreases that of shared items.

AI-assisted Pull Requests

• AI tools (e.g. ChatGPT, Claude, or similar) were used entirely or partially in preparing this pull request. Please specify which tools were used, if any.
• Copilot to make a script to fetch wowhead/wowdb data and reconstruct pools, then tidy up final migrations file.

Issues Addressed:

• Closes [Naxx25 Loot Tables] Anub'Rekhan chromiecraft/chromiecraft#9131

SOURCE:

The changes have been validated through:

• Live research (checked on live servers, e.g Classic WotLK, Retail, etc.)
• Sniffs (remember to share them with the open source community!)
• Video evidence, knowledge databases or other public sources (e.g forums, Wowhead, etc.)
• The changes promoted by this pull request come partially or entirely from another project (cherry-pick). Cherry-picks must be committed using the proper --author tag in order to be accepted, thus crediting the original authors, unless otherwise unable to be found

Tests Performed:

This PR has been:

• Tested in-game by the author.
• Tested in-game by other community members/someone else other than the author/has been live on production servers.
• This pull request requires further testing and may have edge cases to be tested.

How to Test the Changes:

• This pull request can be tested by following the reproduction steps provided in the linked issue
• This pull request requires further testing. Provide steps to test your changes. If it requires any specific setup e.g multiple players please specify it as well.

0. Patch cs_debug.cpp to increase iteration limit from 100 to 10000 (100 is too low for statistical inference)
1. .debug loot creature 29249 10000
2. .debug loot creature 29268 10000
3. .debug loot creature 29278 10000
4. .debug loot creature 29615 10000
5. .debug loot creature 29701 10000
6. .debug loot creature 29940 10000
7. .debug loot creature 29955 10000
8. .debug loot creature 29324 10000
9. .debug loot creature 29373 10000

Known Issues and TODO List:

• Evidence for Anub'Rekhan was taken from [Naxx25 Loot Tables] Anub'Rekhan chromiecraft/chromiecraft#9131 (+ validated against wowhead data). For all other bosses only 1 pool (9 jewelry items) is reliably validated. For the remaining 3 the split is arbitrary but harmless since it does not affect individual drop rates.

How to Test AzerothCore PRs

When a PR is ready to be tested, it will be marked as [WAITING TO BE TESTED].

You can help by testing PRs and writing your feedback here on the PR's page on GitHub. Follow the instructions here:

http://www.azerothcore.org/wiki/How-to-test-a-PR

REMEMBER: when testing a PR that changes something generic (i.e. a part of code that handles more than one specific thing), the tester should not only check that the PR does its job (e.g. fixing spell XXX) but especially check that the PR does not cause any regression (i.e. introducing new bugs).

For example: if a PR fixes spell X by changing a part of code that handles spells X, Y, and Z, we should not only test X, but we should test Y and Z as well.

[Copilot]

Pull request overview

This PR updates the World database loot definitions for several Naxxramas 25-man bosses to match expected retail WotLK “multi-pool” behavior, separating boss-specific drops and shared drops into distinct loot groups.

Changes:

• Updates creature_loot_template reference rows for 9 bosses to roll their reference table once (MinCount/MaxCount set to 1) instead of multiple times.
• Re-structures each boss’s reference_loot_template by splitting the previously single GroupId into multiple GroupId pools (e.g., 5+5+5+9 or 5+4+5+9).

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[espkk]

Providing a bit more context, as this appears to be non-trivial to review:

The current loot table appears to be based on wotlk classic wowhead data, but it uses a single pool with uniformly distributed drop rates, which clearly doesn't match any of the available data.

Looking at the classic wotlk drop rate data, there is a clear multimodal split. Assuming 4 buckets and judging purely by SSE exhaustive testing points to a 5+6+6+7 split. However, on closer inspection, the distribution is biased towards the grand mean (16.7%) and converges towards 5+5+5+9 as the number of observed drops increases. This implies the dataset was originally aggregated under a uniform distribution (very likely to be early wotlk classic bug), but the loot system was later changed to use proper pooling.

This is implicitly confirmed by the fact that 9 is exactly the number of shared items in each boss's loot table, and the unique items consistently follow a uniform distribution within their buckets. Cross-checking against archived (web.archive.org circa 2013) wowhead data (which btw has fewer items per boss loot table) further confirms the pattern, with bucket splits depending on total item count (22-24): 5+5+5+9, 4+5+5+9, 4+4+5+9 - always with a fixed shared bucket of 9.

The core problem with the current single-pool approach is that shared items not only appear on multiple bosses but each boss rolls for them independently. Under uniform distribution, a shared item present on 6 bosses effectively gets 6 chances to drop per raid clear, while already having an inflated per-boss drop rate (since the pool treats all items equally regardless of how many bosses share them). Not to mention a boss can drop, say, 4 rings per kill, because of them being in the same uniform pool. Proper pooling corrects this by placing shared items in a larger bucket, giving them a lower individual drop rate (1/9 = ~11.1%) compared to unique items (1/5 = 20%), and a single roll per bucket, which offsets their inherent multi-boss advantage.

To sum up, this change restores the original (and correct) pooling system. The items in the pool are left as-is (matching the current DB rather than archived wotlk, which has fewer items), and the bucket split doesn't affect individual drop rates other than lowering them for shared items relative to unique ones. While the exact assignment of unique items to specific buckets is undetermined (except for Anub'Rekhan, which is confirmed by video evidence), this has no practical impact since the unique buckets for each boss are equal in size. The change strictly improves broken behavior with no downsides, while leaving room for a minor follow-up to restore exact loot pool assignments or remove a few extra items to restore wotlk retail behaviour.