Crafting — Currency Integration¶

This folder contains optional integration bridges between the Crafting system and the RevFramework Currency / Economy systems.

These integrations allow Crafting to:

• read currency balances
• debit currency during craft acceptance
• credit currency during refunds

They do this without introducing a hard dependency on the Currency or Economy modules.

Purpose¶

Currency integration exists to connect Crafting to a currency system through a clean, replaceable adapter seam.

Key goals:

• Keep Crafting independent of currency implementation details
• Allow projects to implement their own currency adapters against the public interfaces
• Support simple (direct debit/credit) and extensible (hold/escrow-ready) models
• Fail safely when currency systems are not present

Adapter seam¶

All currency integrations are built around:

These adapters are designed for RevFramework Currency / Economy systems.
They are not intended as a universal integration layer for third-party currency solutions.

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

Script defines¶

Currency integrations are conditionally compiled:

Notes:

• Crafting works without these defines
• Currency-dependent behaviour is simply unavailable when not present
• Adapters fail safely rather than throwing

Current behaviour (important)¶

Direct currency support¶

When a currency adapter is present:

• Crafting can:
• read balances
• debit currency during acceptance
• credit currency during refunds

All operations are:

• validated
• non-throwing
• safe-failing when services are missing

Escrow / hold support¶

Although the adapter interfaces include:

• ICraftingCurrencyHoldAdapter

The built-in adapters do NOT implement working hold/capture/release behaviour.

This means:

• TryHold → always fails safely
• TryCapture → always fails
• ReleaseHold → no-op

As a result:

👉 Escrow crafting paths that require currency holds will refuse to run

This is intentional and avoids partial or undefined behaviour.

Design philosophy¶

Currency integration follows strict rules:

• Adapters are thin bridges, not logic owners
• Currency systems remain authoritative
• Crafting does not assume:
• persistence
• transaction guarantees
• hold semantics
• Strong/atomic behaviour depends entirely on adapter capabilities

Typical flow¶

When a currency adapter is present:

1. Preflight

2. Crafting queries balance via adapter

3. Accept

4. Currency is debited via adapter

5. Completion

6. Outputs are delivered

7. Failure (if applicable)

8. Currency may be refunded via adapter

Notes¶

• Currency integration is optional
• Safe to remove entirely if your game has no currency system
• Fully replaceable with your own adapter implementation
• Does not affect core crafting logic or recipe evaluation

Summary¶

Currency integration connects Crafting to the RevFramework Currency system through a safe, optional adapter seam.

This integration is built and supported for RevFramework Currency / Economy systems only.

Custom or third-party currency integrations are not supported by these adapters.
If you are using a different system, implement your own adapter using the public interfaces.

Direct debit/credit is supported by the built-in adapters.
Escrow/hold behaviour is implemented, by CurrencyHoldCraftingAdapter. It requires an escrow-composed currency service; without one TryHold refuses and reports the refusal. This line previously said the opposite — that no provided adapter implements it and a custom one was required.