A table is never validated against your item database, and sampling will not catch it

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

The failure mode is not an entry that never appears. LootRoller refuses only a blank id, so a typo'd one is rolled at its authored rate, tallied by the debugger — which prints raw id strings and resolves nothing — and spawned as a pickup if a spawner is bound. The first component in the chain that consults a database is the inventory adapter, at delivery.

So an entry present in a sample of any size proves nothing about its id. Grant the table once in Play Mode with your real adapters bound, and watch Granted against Undelivered: an entry that rolls every time and never reaches the container is the one whose id is wrong. A typo'd currency id does not even fail — it credits a wallet key created on demand, so Granted fires for money no UI is reading.

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.

Undelivered reports what the service could not place, which is not always a loss

The service is saying it found nowhere to put the award. That normally means the player has lost it — but not when the caller kept hold of the award itself, and the shipped pickup flow does exactly that: a collector with a full bag walking over a LootPickupPayload fires Undelivered, Grant returns false, and the pickup is not consumed. It stays in the world carrying its award and can be collected again once there is room.

Pinned by OnEnter_WhenDeliveryFails_LeavesThePickupCollectable. If you mail, queue or re-grant from this event, check first whether the award still exists somewhere — otherwise a full-bag collect hands the player the same drop twice.

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 delivery suite in LootServiceDeliveryTests exists 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.