Skip to content

RevFramework – Crafting FAQ

This FAQ answers decision questions about using the Crafting system: how to integrate it, which extension point to use, and what is supported vs. discouraged.

It does not repeat the README content. If you’re looking for APIs, lifecycle details, or behaviour specifics, see the Crafting READMEs.

How do I integrate Crafting into my project?

Minimal runtime setup:

  1. Add CraftingService to the scene.
  2. Provide one inventory adapter (ICraftingInventoryAdapter).
  3. (Optional) Provide a currency adapter (ICraftingCurrencyAdapter).

If you use the built‑in integrations:

  • InventoryCraftingAdapter requires REV_INVENTORY_PRESENT.
  • CurrencyCraftingAdapter requires REV_CURRENCY_PRESENT.

Rule of thumb: Crafting never talks to gameplay systems directly. You integrate by adapters and interfaces, not by modifying the service.

Is this the right extension point?

Use this table to decide where your code belongs.

If you want to… Use this
Allow or block crafting Validator (ICraftingValidator)
Change duration, cost, or outputs Modifier (ICraftingModifier)
Connect inventory or currency Adapter (ICraftingInventoryAdapter, ICraftingCurrencyAdapter)
Route outputs to containers Output Router (ICraftingOutputRouter)
Control multiplayer authority ICraftingAuthority
Drive UI / input Your own UI code

Rule of thumb:
If it changes whether you can craft → Validator.
If it changes what happens when you craft → Modifier.

Can I do X with validators or modifiers?

Can I change input requirements?

No.

Inputs are:

  • validated
  • consumed
  • refunded

as part of a fixed pipeline.

Instead:

  • Use multiple recipes, or
  • Use a validator to block crafting based on inventory state.

Can I refund items or currency in a validator?

No.

Validators:

  • do not consume
  • do not refund
  • do not mutate state

They only adjust the preflight result.

Instead:

  • Use CraftingService’s built‑in refund paths, or
  • React to OnJobFailed / OnJobCancelled lifecycle events.

Can I add bonus outputs conditionally?

Yes.

Use ICraftingModifier and modify:

  • CraftAdjustments.extraOutputs, or
  • CraftAdjustments.chanceOutputs

Remember:

  • Modifiers may run during preflight, accept, and delivery.
  • Output routing and space checks still apply.

Can I bypass space checks?

Not currently.

The Crafting service returns early when a craft fails due to NoSpacePreflight, which means validators are not executed for that preflight result because the service returns immediately.

Because of this, a validator cannot override the space‑preflight failure in the current runtime pipeline.

If your gameplay requires bypassing space checks, you must modify your design, for example by:

  • ensuring sufficient container space before crafting, or
  • routing outputs to a container that can accept them.

How does Crafting behave in multiplayer?

Crafting is netcode‑agnostic.

Typical multiplayer setup:

  • Use ICraftingAuthority to gate mutations (enqueue, cancel, pause, reorder).
  • Execute crafting mutations on the server or host.
  • Replicate job state to clients using your networking solution.

Supported networking approaches include:

  • Unity Netcode for GameObjects
  • Mirror
  • Fusion
  • Custom RPC systems

Important:

  • Authority only decides who may mutate state.
  • Replication, prediction, and reconciliation are your responsibility.

Can I do fully atomic crafting in multiplayer?

Yes — for immediate crafts via the escrow path.

CraftingService exposes an optional strong / escrow execution path (TryCraftImmediateEscrow) for atomic, zero‑duration crafts.

This path:

  • Requires inventory adapters that support reservations
  • Requires currency adapters that support holds (when currency is used)
  • Executes inputs, currency, and outputs as a single atomic operation
  • Refuses to run if required guarantees cannot be met

This path is intended for:

  • server‑authoritative crafting
  • economy‑critical gameplay
  • duplication‑sensitive systems

Is escrow required for multiplayer?

No.

The standard job‑based crafting pipeline works in multiplayer when:

  • crafting mutations are gated by ICraftingAuthority
  • the server performs the mutations

Escrow is an advanced opt‑in feature for systems that require strict atomic guarantees.

Can I use escrow without RevFramework Inventory or Currency?

Yes — if your backend supports reservations.

Escrow relies on these interfaces:

  • ICraftingInventoryReservationAdapter
  • ICraftingCurrencyHoldAdapter

If your inventory or currency system supports reservations and transactional commits, you can implement these adapters without using RevFramework Inventory or Economy.

If those guarantees cannot be met, escrow will refuse to run by design.

Can I use Crafting without Currency?

Yes.

If no currency adapter is assigned:

  • currency checks are skipped
  • recipes craft without currency cost

Can I use Crafting without offline progress?

Yes.

Disable offline progression by setting:

disable offline progression in the CraftingService configuration
(e.g. by setting `enableOfflineProgress` to false in the service inspector).

In that configuration:

  • jobs resume using stored remainingSeconds
  • offline time is ignored

acceptedAtUtc is still recorded to maintain snapshot consistency.

Who is responsible for saving crafting jobs?

You are.

The Crafting system provides APIs for persistence:

  • SaveActiveJobs(...)
  • RestoreJobs(...)

These allow you to:

  • capture active jobs
  • store them in your own save system
  • restore them later

However, Crafting does not provide:

  • a save file system
  • cloud sync
  • player profiles
  • cross-session ID resolution

You must handle:

  • where data is stored (file, cloud, database)
  • how owners and recipes are identified across sessions
  • when save and restore occur in your game lifecycle
  • ensuring identifiers (owner / recipe) are stable across sessions

Rule of thumb:
Crafting defines the job model and snapshot mechanism —
you provide the persistence system.

What should I avoid?

Avoid the following patterns:

  • ❌ Modifying CraftingService
  • ❌ Performing gameplay logic inside adapters
  • ❌ Mutating inventory or currency from validators
  • ❌ Assuming workbenches are required
  • ❌ Expecting networking or replication to be built‑in
  • ❌ Treating RecipeCore as a mutable runtime object

Recipes should be treated as immutable configuration data.

What guarantees does Crafting provide?

The Crafting system guarantees:

  • deterministic behaviour when RNG is seeded, binomial approximation is disabled, and RNG call order remains consistent
  • explicit pipeline execution: preflight → accept → delivery
  • clear extension seams (validators, modifiers, adapters)
  • safe offline restore behaviour (when integrated with your persistence system)
  • authority‑aware mutation gating
  • UI‑agnostic runtime operation

When should I contact support?

Before contacting support, check the following:

  • Is an inventory adapter assigned?
  • Are you using a validator vs modifier correctly?
  • Are you attempting to mutate state from a validator?
  • Is offline progress intentionally enabled?
  • Are you assuming networking behaviour exists inside Crafting?

If you still believe something is incorrect, include:

  • Unity version
  • Active adapters, validators, and modifiers
  • Authority configuration
  • Reproduction steps
  • Relevant CraftFailReason values

Summary

Crafting is designed to be:

  • Modular
  • Explicit
  • Deterministic
  • Authority‑aware
  • UI‑agnostic

If you integrate via adapters, choose the correct extension point, and keep gameplay logic outside the service, you are using the system correctly.