Skip to content

🛠️ 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.