Crafting — Inventory Integration¶

This folder contains optional integration bridges between the Crafting system and the RevFramework Inventory system.

These integrations allow Crafting to:

• resolve inventory containers
• count items
• check available space
• consume inputs
• deliver outputs

All interaction happens through a clean adapter seam, keeping Crafting independent from any specific inventory implementation.

Purpose¶

Inventory integration exists to connect Crafting to an external inventory backend without introducing hard dependencies into the core crafting model.

Key goals:

• Keep Crafting independent of inventory implementation details
• Allow projects to plug in their own inventory systems
• Provide safe, predictable behaviour when inventory systems are missing
• Support both simple and advanced inventory models via adapters

Adapter seam¶

All inventory integrations are built around:

Adapters live in the Adapters/ subfolder and translate Crafting operations into inventory-system calls.

Script defines¶

Inventory integrations are conditionally compiled:

Notes:

• Crafting works without this define
• Inventory-dependent behaviour is unavailable when not present
• Adapters fail safely instead of throwing

Current behaviour (important)¶

Direct inventory support¶

When an inventory adapter is present:

• Crafting can:
• resolve containers
• count items
• check space availability
• consume inputs
• add outputs

All operations are:

• defensive
• non-throwing
• dependent on adapter/service behaviour

Reservation / escrow support¶

Although the adapter interface includes:

• ICraftingInventoryReservationAdapter

The current built-in inventory integration does NOT provide reservation primitives.

This means:

• TryReserveInputs → always fails safely
• TryReserveOutputs → always fails safely
• reservation objects never commit successfully

As a result:

👉 Strong / escrow crafting paths that rely on inventory reservations will refuse to run

This is intentional and prevents partial or undefined state changes.

Design philosophy¶

Inventory integration follows strict rules:

• Adapters are thin bridges, not logic owners
• The inventory system remains authoritative
• Crafting does not assume:
• atomic transactions
• reservation guarantees
• container persistence behaviour
• Space checks are non-reserving
• Mutation success depends on the underlying inventory system

Typical flow¶

When an inventory adapter is present:

1. Preflight:
2. resolve container
3. count inputs

4. check space for outputs

5. Accept:

6. consume inputs via adapter

7. Completion:

8. add outputs via adapter

9. Failure:

10. optional refunds may occur depending on CraftingService configuration
11. success of refunds depends on inventory adapter behaviour

Unity-facing recipe integration¶

When REV_INVENTORY_PRESENT is enabled:

• RecipeDefinition becomes available as a Unity authoring helper
• It allows designers to use ItemDefinition assets
• It converts to RecipeCore at runtime via RecipeResolve

Without this define:

• Only RecipeCore assets are supported
• Unity-facing recipe wrappers are not available

Notes¶

• Inventory integration is optional
• Safe to remove if your project does not use an inventory system
• Fully replaceable with a custom adapter
• Does not affect the core crafting model or recipe evaluation logic

Summary:
Inventory integration connects Crafting to the RevFramework Inventory system through a safe, optional adapter seam.

This is designed for RevFramework system interoperability, not generic third-party inventory support. Direct operations are supported; reservation/escrow behaviour depends on the capabilities of the integrated system.