Skip to content

01 — Workbench Basics (2D or 3D)

Goal

Learn how crafting workbenches control access to the Crafting system in both 2D and 3D scenes.

This scene teaches the workbench decision model:

Bench gate → Service gate → Runtime state

⚠️ Intentional Validation Warning

This demo scene is intentionally configured to trigger a warning in the Unity Editor.

One of the workbenches has a stationTagFilter that does not match the selected recipe’s required station tag.

Example warning:

[CraftingWorkbench3D] stationTagFilter='MetalBench' does not match selected recipe tag='WoodBench'.
This bench will reject that recipe at runtime.

This is expected behaviour.

It demonstrates:

  • how station tag gating works
  • why a bench may reject a valid recipe
  • how RevFramework surfaces clear setup warnings instead of silent failure

For this demo, leave the warning as-is.

🎓 What This Scene Demonstrates

This scene introduces bench-driven crafting.

A workbench does not replace CraftingService.

It adds an extra access layer before crafting can run.

The three layers are:

  1. Bench gate Checks the selected recipe, station filter, and whether the owner is in range.

  2. Service gate Uses CraftingService preflight to check items, currency, output space, authority, and validators.

  3. Runtime state Exists only after a craft request is accepted and a CraftJob is created.

The key lesson is:

Being near a bench does not mean the craft is valid.

And:

Passing the bench gate does not guarantee the service gate will pass.

🔍 What’s Actually Happening

In this scene, one bench is intentionally configured with a station mismatch.

For example:

  • The bench has a stationTagFilter of MetalBench
  • The selected recipe requires WoodBench

So the recipe is valid, but that bench is not allowed to craft it.

That means the request is blocked at the bench gate, before a valid job is created.

This is not a CraftingService failure.

It is the bench doing exactly what it is configured to do.

🧪 Sample Setup

This scene uses sample/demo helpers so the workbench behaviour is easy to see:

  • sample inventory/currency state
  • fake inventory and currency panels
  • permissive sample authority setup
  • simple 2D/3D bench interaction zones

These are included to keep the scene focused on workbench behaviour.

They are not production gameplay UI.

⚠️ Sample Scope

This scene focuses on:

  • 2D and 3D workbench behaviour
  • station tag filters
  • trigger/range checks
  • service preflight
  • job creation
  • live job progress

It does not focus on:

  • output routing
  • persistence
  • advanced validators
  • modifiers
  • real inventory/economy integrations
  • networking

Those are covered by later specialised scenes.

⚠️ Authority Note

This scene may include a local sample authority binder configured to allow crafting.

That means:

  • crafting behaves permissively in this sample
  • authority is visible as part of the setup
  • this is not a multiplayer or server-authority implementation

To enforce real authority:

  • provide an ICraftingAuthority implementation
  • wire it into CraftingService
  • do not rely on simply adding a component to the scene

🌐 Networking Reminder

RevFramework does not implement:

  • networking
  • replication
  • prediction
  • rollback
  • reconciliation

These samples demonstrate local behaviour only.

All networking behaviour is your responsibility.

🧩 How To Use

  1. Enter Play Mode.
  2. Open or view the CraftingWorkbenchBasicsPanel.
  3. Use the Overview tab to inspect the active bench, selected recipe, station filter, and bindings.
  4. Use the bench selector to switch between the configured benches.
  5. Check whether the bench station filter matches the selected recipe.
  6. Move the player into the bench trigger zone.
  7. Press the craft key, F by default, to attempt crafting through the real workbench path.

  8. Use the Gates tab to inspect:

  9. bench gate

  10. service gate
  11. probe limits
  12. trigger/range state
  13. Use the Runtime tab to observe active jobs and progress.
  14. Change the selected recipe or station filter to test passing and failing bench setups.

The panel also respects the bench interaction zone.

If the owner is outside the bench trigger, bench-style craft actions are blocked.

🔎 Failure Behaviour

Failures are intentional teaching signals in this scene.

Common examples:

  • station tag mismatch → bench gate blocks the recipe
  • owner outside trigger → bench-style actions are blocked
  • missing items → service preflight fails
  • missing currency → service preflight fails
  • no output space → service preflight fails
  • invalid owner/container → service cannot resolve the required state
  • authority blocked → service gate rejects the craft

The important distinction is:

Bench failures decide whether the craft can be attempted here.

Service failures decide whether the craft can actually run now.

Runtime failures happen only after a job exists.

⚙️ Behind The Scenes

CraftingWorkbench2D and CraftingWorkbench3D follow the same teaching model.

Each bench can define:

  • a recipe list
  • a selected recipe index
  • a station tag filter
  • a trigger/range zone
  • an interaction path

When the owner is in range and the bench allows the selected recipe, the craft request can be passed to CraftingService.

The panel uses public APIs and public workbench surfaces only.

It does not use reflection, internal fields, or fake success paths.

💡 Key Takeaway

Workbenches control access to crafting.

They answer:

Can this owner try this recipe here?

Then CraftingService answers:

Can this craft actually run now?

Once a request is accepted, runtime job state answers:

What is happening to the craft now?

That separation is the point of this scene.

Panel: CraftingWorkbenchBasicsPanel Scene Path: Assets/RevFramework/Samples/Systems/Crafting/Scenes/01_Workbench_Basics_2D_or_3D/