A table is never validated against your item database

LootEntry.itemGuid and .currencyId are raw strings and nothing checks them — not at author time, not at edit time, not at runtime. This is the price of the decoupling that lets RevFramework.Loot compile with Inventory deleted.

The failure mode is the quiet one: a typo'd id is not an error, it is an entry that never appears. Sample the table in the debugger and check every authored entry shows up. An entry missing from a large sample is telling you its id does not resolve.

The upper-bound case is load-bearing, and it is not theoretical

IRandomProvider.Value01() is documented as inclusive at both ends, and UnityEngine.Random.value really does return 1.0. Scaled onto a weight total that lands exactly on the end of the last bucket.

Handled explicitly and pinned by Weighted_RandomAtUpperBoundStillPicksAnEntry. Crafting never met this because its seeded provider returns [0,1) — so this class of bug has no analogue elsewhere in the framework and would not be found by comparison with it.

Both bounds are handled explicitly, not by comparison

A plain roll <= chance awards at chance 0. A plain roll < chance occasionally refuses at chance 1. Because Value01() is inclusive at both ends, neither comparison alone is correct, and the code special-cases both. Pinned by Independent_ChanceZeroNeverAwardsAndChanceOneAlwaysDoes.

End-to-end odds across nesting are not the product of the printed numbers

A nested entry competes at its parent's level; the nested table then rolls its own weights. The two are independent, so an entry three levels down is not "weight 5 out of the grand total".

There is no arithmetic on this page that will give you the real number. Sample it.

Never store a loot seed as a record of what the player got

A seed is reproducible against a fixed table, not against a table you will keep editing. Storing "seed 4711 gave them the sword" means the sword changes the next time a designer adds a row.

Save the result, not the seed.

RollAndGrant's return value cannot tell you whether anything was delivered

It returns what the table produced whether or not every award could be delivered. Reading it tells you a roll happened and nothing about where the awards went.

Grant returns a bool that does mean delivery; RollAndGrant has no equivalent. Use the events for delivery outcomes. Driving a "you received" message from RollAndGrant's return value is the exact mistake the Granted event exists to prevent.

Drive player-facing UI from Granted, never from Rolled

Rolled fires with everything the table produced, before delivery has been attempted. A toast driven from it announces items a full bag will silently eat.

Granted carries what actually landed, which is what makes it safe. This distinction was a real defect once — the service used to fire Granted with the whole roll — and the nine delivery tests exist to keep it fixed.

This is the system's real ceiling

Modifiers adjust what was won, never what was likely. The reasoning is sound — a table whose printed weights do not describe its behaviour is very hard to reason about — but the consequence is that an entire category of common loot feature cannot be expressed without editing LootRoller.

If your design needs odds-shaping, establish that before building on this system.

The payload must be on the prefab, not added after Instantiate

TriggerRelay3D resolves its IPickupTriggerReceiver during Awake, which has already run by the time Instantiate returns. A payload component added to the instance afterwards is never found, and the pickup silently does nothing on collect.

This is the single most likely mistake when writing a custom spawner.