Loot — Runtime¶
Drop tables: authored odds, rolled into awards.
Overview¶
A LootTable is inert data. Rolling one produces a LootResult describing what was won — nothing is granted to anybody until an adapter is asked to grant it.
That separation is deliberate. It means drop rates can be verified without a scene or Play Mode, and it means this assembly keeps compiling when Inventory, Currency, Pickups or Health have been removed.
Two roll models¶
| Mode | Behaviour |
|---|---|
Weighted | Each roll picks exactly one entry by relative weight. A table always yields as many awards as it has rolls. |
IndependentChance | Every entry is tested against its own chance. A table may yield nothing, everything, or anything between. |
Weights are relative, so 1/1/2 behaves identically to 50/50/100. Use a Nothing entry to express "sometimes no drop" in a weighted table.
Items are GUIDs, not assets¶
Entries reference items by GUID string, the same choice Crafting.Core.ItemRef makes and for the same reason: it keeps this assembly free of any dependency on Inventory. Turning a GUID into a real item is the integration adapter's job.
Nesting¶
A Table entry rolls another table and folds its awards into the parent. Depth is capped and a table that reaches itself is detected and stopped, so a circular reference is a warning rather than a hang.
Determinism¶
LootService.UseDeterministicRng(seed) replaces the random source with a seeded one. The same seed replays the same rolls exactly, which is what makes a drop-rate check meaningful and a bug report reproducible.
Note that determinism is per call-sequence: changing how many values a roll consumes changes everything after it.