Fighting Game · Guides & deep dives

V2 Loot Table Debugger

1.

3sections1 minread
Markdown source
On this page

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.