Skip to content

📦 Inventory — Documentation Guide

🧭 Where should I start?

🔹 New to Inventory?

Start with:

👉 System Overview (README + Mental Model)

This explains: - What the Inventory system is
- How containers, stacks, and the service layer work together
- How Inventory integrates with Equipment, Use Effects, Crafting, Currency, and Pickups
- Typical setup and usage patterns

🔹 Want to know what you can safely depend on?

Read:

👉 PublicAPI/

This document defines: - The supported runtime surface - Stable types, methods, and events - Guaranteed behaviours and lifecycle ordering - Explicitly unsupported usage

If something is not listed there, it is not supported — even if it appears public in code.

This is the contract.

🔹 Adding gameplay or extending the system?

Start with:

👉 Integration Surfaces/

This shows exactly where logic belongs: - gameplay mutations
- equipment rules
- item usage
- external system integration

Then use:

👉 FAQ/

The FAQ answers questions like: - Should I use the service or a wrapper? - Where should gameplay logic live? - How do I handle multiplayer authority? - Can I replace the host? - What should I avoid?

It focuses on decision-making, not API reference.

🧠 How these documents work together

Document Purpose
Overview Explains the system
Public API Defines what is supported
FAQ Guides correct usage choices
Integration Surfaces Shows where new logic should plug in
Mental Model Explains how to think about the system
Guarantees Matrix Defines behavioural contracts

Each document serves a specific purpose.
You do not need to read everything — start with what matches your task.

🛑 Important support note

RevFramework Inventory is:

  • Service-driven
  • Slot-based
  • Deterministic
  • Authority-aware
  • UI-agnostic
  • Netcode-agnostic

Support is provided for:

  • Behaviour defined in PublicAPI
  • Usage patterns described in Overview, FAQ, and Integration Surfaces
  • Guarantees listed in the Guarantees Matrix

Support is not provided for:

  • Modifying internal services or containers
  • Depending on undocumented behaviour
  • Reflecting into runtime internals
  • Treating public-looking types as supported by default

  • Teaching Panels
    Add debug or teachable panels (Editor / optional tooling) to visualize behaviour live

  • Samples
    See /Samples/Inventory/ for runnable examples

  • MkDocs site
    Mirrors this documentation for web browsing

🧠 System philosophy

Inventory is:

  • A service-controlled system (not component-driven state)
  • A container model (not arbitrary item lists)
  • A result-first API (no silent failures)
  • A replaceable host architecture (no lock-in to our implementations)

Every public API surface exists for a reason.
If something feels unclear, you're likely using the wrong extension seam.

✅ TL;DR

  • Want to understand Inventory → Overview
  • Want to build safely → Public API
  • Want to choose correctly → FAQ
  • Want to extend cleanly → Integration Surfaces

If you stay within these boundaries, Inventory will behave predictably and remain future-proof.