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: the whole assembly is constrained to REV_TEACHABLES and REV_CRAFTING_PRESENT.

Teaching content never ships in a player build, and you do not have to remember that yourself. RevTeachablesBuildGuard raises a compile-time #error on any Player build while REV_TEACHABLES is set, so a panel left on a GameObject in a shipped scene does not quietly become a live debug overlay for your players — the build refuses to compile instead. A build failure is a far cheaper way to find out than a review is.

To make a player build, run Tools > RevGaming > RevFramework > Validate > Pre-Build Clean, or delete/move Assets/RevFramework/Teaching. The define follows the Teaching folder and cannot be cleared on its own.

Panel Categories¶

Teaching panels are organised into three groups:

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:

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:

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 — only when a currency adapter is bound
• space
• validators

The service reports the first blocking reason.

With no currency adapter, currency is not a constraint at all: the cost check is skipped, NoCurrency never fires, and a priced recipe crafts for free. That is a supported configuration — crafting without a currency system is explicitly allowed — which is exactly what makes an adapter you meant to bind and forgot so easy to miss. There is no refused craft to notice. Each panel's guard note says so when it finds no adapter.

Adapters Are the Integration Seam¶

Inventory and currency interactions go through adapters configured on CraftingService.

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¶

Teaching/
 └ Crafting/
    ├ README.md
    ├ RevFramework.Crafting.Teaching.asmdef
    │
    ├ HostileConsumers/
    │   ├ README.md
    │   ├ CraftingQuickstartPanel.cs
    │   ├ CraftingWorkbenchBasicsPanel.cs
    │   ├ CraftingValidatorsModifiersPanel.cs
    │   ├ CraftingOfflineProgressPanel.cs
    │   └ CraftingSavePanel.cs
    │
    ├ Demos/
    │   ├ README.md
    │   ├ CraftingRoutingSpaceCurrencyPanel.cs
    │   └ CraftingRealAdaptersPanel.cs
    │
    └ Support/
        ├ README.md
        ├ CraftingRejectFeedback.cs
        ├ TeachingOutputRouter.cs
        └ TeachingOutputRouterConfig.cs

Quick Review¶

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.