Skip to content

🔌 Inventory — Integrations

The Integrations/Inventory/ folder contains optional integration glue between the Inventory system and other RevFramework systems.

Integrations live at the RevFramework root so optional cross-system code is kept outside the standalone Inventory module.

These integrations are intentionally lightweight, adapter-based, and safe to remove.

They provide:

  • Optional Inventory ↔ other-system behaviour
  • No required dependency from Inventory core to those systems
  • Define-gated compilation where needed
  • Small translation layers instead of shared gameplay logic

Think of this folder as the optional cross-system joinery layer for Inventory.

These integrations are built and supported for RevFramework systems only. They are not intended as a general integration layer for third-party tools.

🎯 Design Goals

Integrations exist to:

  • Keep Inventory fully standalone
  • Avoid circular or hidden dependencies between systems
  • Allow cross-system behaviour only when explicitly installed
  • Ensure removing a system does not break compilation or runtime behaviour

Inventory core code never assumes an integration exists.

📦 Structure

Integrations are organised by target system.

Examples:

  • PickupsIntegration/ → Inventory ↔ Pickups integration
  • CurrencyIntegration/ → Inventory ↔ Currency integration

Each subfolder may contain:

  • Adapters
  • Integration helpers
  • Optional dispatch logic
  • Translation layers
  • Convenience wrappers

These are system-specific integrations — not shared gameplay policy layers.

🧩 Adapter & Define Safety

Most integrations are:

  • Define-gated (for example REV_PICKUPS_PRESENT)
  • Compiled only when the target system is present
  • Stubbed or excluded entirely when dependencies are missing

This guarantees:

  • No compile errors when systems are removed
  • No accidental runtime coupling
  • Clean SKU separation
  • Predictable optional behaviour

🧼 Safe to Remove

If you are not using cross-system integrations:

✅ The integration folders under Integrations/Inventory/ are safe to delete.

Inventory itself will continue functioning normally with:

  • Containers
  • Equipment
  • Item use
  • Snapshots
  • Sorting/searching
  • Inventory UI
  • Runtime services

These folders exist only to support optional interoperability between RevFramework systems.

🧠 When Should I Use Integrations?

Use integrations when:

  • Inventory needs to interoperate with another system
  • You want to translate data or events between systems
  • You want both systems to remain independently removable
  • You want optional behaviour without hard dependencies

Do not use integrations to:

  • Add core gameplay rules
  • Extend Inventory internals directly
  • Share mutable state between systems
  • Bypass public APIs

🌍 Third-Party / Custom System Use

These integrations are designed specifically for RevFramework systems.

If integrating Inventory with external or third-party systems:

  • Treat these integrations as reference examples
  • Build your own adapter layer
  • Consume Inventory through the public APIs

👉 Third-party integrations are not officially supported through this layer.

🔒 Dependency Philosophy

Inventory is intentionally strict about dependency direction.

The Inventory module itself:

  • Does not directly depend on other RevFramework systems
  • Does not require integrations to function
  • Remains removable and standalone

Cross-system behaviour belongs here — not inside Inventory core.

This keeps the framework modular, predictable, and SKU-safe.

🛠 Namespace Consistency

All integration implementations should use the RevGaming.RevFramework.Integrations.* namespace hierarchy.

Example:

namespace RevGaming.RevFramework.Integrations.Inventory.Pickups

Avoid legacy Bridges namespace paths from older architecture revisions.

📘 See Also

  • Inventory Root README
  • Inventory Abstractions
  • Inventory Services
  • RevFramework Public API documentation

🧾 Support Stance

Integrations are intentionally small and narrowly scoped.

If you need deeper coupling or game-specific orchestration:

  • Build it in your gameplay layer, or
  • Create a project-specific adapter consuming public APIs

Inventory itself remains standalone and dependency-light by design.