Hostile Consumer Panels¶
This folder contains hostile-consumer teachable panels for the Status Effects 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 Status Effects 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 components
- 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. The panels that do live in ../Demos/.
Panels in This Folder¶
| Panel | Teaches |
|---|---|
StatusBasicsPanel | The application flow end to end: build an effect through StatusRegistry, submit it to StatusEffectController, then inspect live active effects, timers, stacking type, and stored context. |
StatusStackingPolicyPanel | What happens when the same status id is applied repeatedly — stack caps, per-source matching and refresh, controller queries, and bulk removals. |
Both operate purely through the registry and the controller. Neither adds, removes, or reconfigures a component on any object in the scene.
The Boundary These Panels Hold¶
The Status Effects runtime model is a controller plus a registry, and both are public. That is what makes a hostile-consumer panel possible here: everything these panels need in order to apply, query, and remove effects is reachable from outside the assembly.
Where the system exposes optional receiver-side seams — potency, resistance, immunity — a panel demonstrating them has to put an implementation of that seam onto a target. That is a legitimate thing for a consumer to do, and it is also a change to an object the panel does not own, which is why those panels are classified as demos rather than as proof of the public surface. The seam itself is public either way.
Reading These Panels¶
Copy the registry and controller calls, and the result handling. Ignore the IMGUI layout — it is scaffolding, not a UI recommendation.
StatusStackingPolicyPanel is the more useful of the two if you are deciding how repeated application should behave in your own game: it makes cap and per-source policy visible and testable rather than describing them.