Hostile Consumer Panels¶
This folder contains hostile-consumer teachable panels for the Loot system.
These panels are intentionally written as if they lived in a completely separate Unity project consuming RevFramework from the outside.
They verify that the Loot public API surface is complete, stable, and usable without internal access.
What "Hostile Consumer" Means¶
Panels in this folder are restricted to using only:
- Public APIs
- Documented runtime types
- Supported extension seams
- Teaching UI utilities
They may not:
- reference
.Internalnamespaces - use reflection to access private state
- call undocumented
.Corehelpers - depend on sample/demo utilities
- attach teaching-only helper components to targets they do not own
If a panel requires any of those behaviours, the panel must not live in this folder.
Panels in This Folder¶
| Panel | Teaches |
|---|---|
LootRollPanel | Rolling: the two roll models, relative weights, seeds and reproducibility, and sampling a table enough times to prove its real drop rates rather than trusting the authored numbers. |
LootDeliveryPanel | Delivery: which adapters are bound, the difference between rolling and granting, and which of the three outcomes — granted, spawned, undelivered — each award actually reached. |
Neither adds, removes, or reconfigures a component on any object in the scene.
Loot Has No Demos Folder, And Neither Panel Needs One¶
A Demos/ folder holds the panels that have to attach a helper or rewire a service to demonstrate an optional seam. Four systems have one — Crafting, Currency, Health and StatusEffects. Loot does not, and neither do Inventory or Pickups: none of their panels needs to do either.
LootRollPanel is the strongest case of that in the framework. Rolling is pure: it calls LootRoller directly and needs no service, no owner and no scene at all. That is not a simplification for the demo — it is the actual design, and it is why drop rates can be verified without entering Play Mode, and why the Loot assembly keeps compiling when Inventory has been deleted.
LootDeliveryPanel is where a service, an owner and real state come in, and it still reaches them through bound adapters rather than by reconfiguring anything. Both panels declare that contract in their own XML: nothing shown is faked, and the distribution is measured from real rolls rather than computed from the weights.
The Boundary These Panels Hold¶
The split between the two panels is the boundary, and it is deliberate.
Rolling produces a result. Delivering that result is a separate operation against a separate system, and it can fail on its own — which is exactly why an award can be rolled and never arrive. Keeping the two panels apart is what lets the first one teach purity honestly and the second one teach failure honestly, instead of one panel blurring them into "loot works".
If you are integrating Loot, read LootRollPanel first. If you are debugging loot that a player never received, LootDeliveryPanel is the one that will tell you why.
Reading These Panels¶
Copy the roller and adapter calls, and the result handling. Ignore the IMGUI layout — it is scaffolding, not a UI recommendation.