# V2 Loot Table Debugger

`V2LootTableDebugger` is the economy debugging surface for validating loot table
behavior before a balance change ships. It repeatedly rolls a `V2LootTable`
definition, preserves pity counters between simulated rolls, and reports
observed distribution rows by pool, entry, and item.

## Workflow

1. Build a `FV2LootTableDebugConfig` with the number of rolls, seed start, seed
   advancement mode, sample-drop limit, and default tolerance.
2. Provide the same `FV2LootTableRollRequest` context tags and starting pity
   counters that the live reward source will use.
3. Add `FV2LootTableExpectedRate` rows for entries or items that need a balance
   gate.
4. Run `SimulateLootTableDrops`.
5. Review `DistributionRows`, `SampleDrops`, `FinalPityCounters`, and the
   `FormatLootTableDistributionSummary` text output.

## Expected Rates

Expected rates use drops per successful roll. A guaranteed item that appears
once per roll should be `1.0`. A weighted entry expected to appear once every
four rolls should be `0.25`. Use `ToleranceDropsPerRoll` per expected row, or
the debug config default tolerance when a row tolerance is zero.

`bExpectedRatesWithinTolerance` fails closed when any observed row is outside
the allowed tolerance. The result records
`LootTableDebugger.ExpectedRateMismatch` with the entry/item that failed.

## CI

Run `python3 V2/ue/Tools/check-v2-loot-table-debugger.py` after changing the
debugger, loot table runtime, contract, docs, or CI/Horde wiring. The checker
verifies N-drop simulation, distribution output, expected-rate validation,
context-sensitive drops, pity counter carryover, and summary formatting.