🛠️ Crafting — Teaching Panels¶
The Teaching folder contains a set of lightweight IMGUI panels used for learning, debugging, and hands-on testing of the Crafting System directly inside your scenes.
These panels demonstrate how preflight checks, enqueue flow, job state/progress, workbenches, routing behaviour, inventory/currency adapters, validators/modifiers, and offline persistence behave via the public Crafting APIs.
Each panel is intentionally minimal and code-first — ideal for understanding behaviour, copying patterns, and wiring your own production UI later.
Status: Development / Teaching UI — intended for editor or testing scenes only.
These panels are not meant to ship in production scenes.Define Guard:
REV_CRAFTING_PRESENT
⚠️ If a Teaching panel is present on a GameObject in a shipped scene, it will be visible and interactive at runtime.
Shipping with Teaching panels attached is a developer error, not a framework bug.
🧩 Panel Categories¶
Teaching panels are organised into three groups:
| Folder | Purpose |
|---|---|
| HostileConsumers | Panels that verify the Crafting public API by behaving like external consumers |
| Demos | Sandbox panels demonstrating optional seams or runtime behaviour |
| Support | Teachables-only helper utilities used by panels |
This separation keeps API verification panels distinct from teaching sandboxes.
🧪 Hostile Consumer Panels¶
Panels in HostileConsumers are written as if they lived in a separate project consuming the framework from the outside.
They:
- use only public APIs
- use documented runtime types
- do not attach teaching helpers
- do not modify runtime wiring
If these panels compile and run, the Crafting public API works correctly.
Examples:
| Panel | Focus |
|---|---|
| CraftingQuickstartPanel | Core crafting flow |
| CraftingWorkbenchBasicsPanel | Workbench-driven crafting |
| CraftingValidatorsModifiersPanel | Validator & modifier behaviour |
| CraftingOfflineProgressPanel | Offline persistence & restore |
🎮 Demo Panels¶
Panels in Demos are sandbox tools used to demonstrate behaviour that normally requires additional runtime wiring.
They may:
- attach teachables-only helpers
- temporarily modify runtime configuration
- simulate routing or policy behaviour
- mutate adapter-backed runtime state
Examples:
| Panel | Focus |
|---|---|
| CraftingRoutingSpaceCurrencyPanel | Routing + space + currency behaviour |
| CraftingRealAdaptersPanel | Real inventory/currency adapter sandbox |
Even though these panels are not hostile-consumer panels, they still interact with the framework through public APIs only.
🎯 Learning Goals¶
Across the teaching panels you’ll learn how to:
- Run preflight checks using
CanCraftDetailed() - Read Max Now + first blocking reason
- Safely enqueue crafting jobs
- Observe job states and progress
- Understand workbench gating and station tags
- Debug routing and space behaviour
- Test chance-output space policies
- Compare currency cost vs balance
- Toggle validators and modifiers
- Verify offline progress behaviour
💡 Example: Preflight → Enqueue¶
Teaching panels demonstrate the same call patterns used in production code:
var check = crafting.CanCraftDetailed(owner, recipe, count, options);
if (check.maxCrafts > 0)
{
var job = crafting.Enqueue(new CraftRequest(owner, recipe, count, container, stationTag));
}
No mock logic.
No hidden shortcuts.
The panels simply display what the runtime systems decide via public APIs.
🧠 Key Concepts the Panels Teach¶
Preflight Is the Source of Truth¶
Preflight evaluates:
- inputs
- currency
- space
- validators
The service reports the first blocking reason.
Adapters Are the Integration Seam¶
Inventory and currency interactions go through adapters configured on CraftingServiceCore.
Panels never bypass adapters.
Routing Behaviour¶
Output routing may be influenced by an ICraftingOutputRouter.
Demo panels may attach a teachables-only router helper to demonstrate routing behaviour.
Production projects should implement their own router instead.
Offline Progress¶
Offline progress is applied when job snapshots are restored.
Panels simulate this by restoring snapshots with adjusted timestamps.
🧰 Integration Tips¶
- Teaching panels use IMGUI and are intended for development scenes only
- They are safe to keep in development scenes
- They do not affect runtime systems unless buttons are pressed
- Copy service calls and data flow, not the IMGUI scaffolding
Panels will display warnings when required services or adapters are missing.
🧱 Folder Layout¶
Crafting/
└ Teaching/
├ HostileConsumers/
│ ├ CraftingQuickstartPanel.cs
│ ├ CraftingWorkbenchBasicsPanel.cs
│ ├ CraftingValidatorsModifiersPanel.cs
│ └ CraftingOfflineProgressPanel.cs
│
├ Demos/
│ ├ CraftingRoutingSpaceCurrencyPanel.cs
│ └ CraftingRealAdaptersPanel.cs
│
└ Support/
├ CraftingRejectFeedback.cs
└ TeachingOutputRouter.cs
🧠 Quick Review¶
| Attribute | Summary |
|---|---|
| Audience | Developers integrating or exploring the Crafting system |
| Goal | Teach preflight, enqueue, jobs, routing behaviour, benches, validators, adapters, and persistence |
| Style | Code-first, readable, dependency-light |
| Location | Assets/RevFramework/Teaching/Crafting/ |
| Safety | Development-only panels |
| Theme | IMGUI — consistent with all RevFramework teaching panels |
TL;DR¶
The Teaching folder is an in-engine classroom for Crafting.
Use it to:
- debug crafting behaviour
- understand preflight results
- explore routing and adapter behaviour
- validate offline progress
- copy production-ready usage patterns.