Skip to content

Pickups → Inventory Integration

This folder provides an optional integration bridge between the Pickups system and the RevFramework Inventory system.

It allows pickup effects to grant items into an inventory without making the Pickups system itself depend on Inventory. The dependency lives in this folder's own assembly, which only compiles when both systems are installed.

This integration is built and supported for RevFramework systems only. It is not intended as a general integration layer for third-party inventory solutions.

What This Integration Does

This integration includes:

  • An item-grant pickup effect (GiveItemEffect)
  • A runtime integration example scene
  • Supporting scene content for testing and learning

It demonstrates how pickups can:

  • Grant items into an inventory container
  • Specify a target container (e.g. "Backpack")
  • Grant through whichever Inventory service the actor resolves to

👉 The RevFramework.Pickups assembly never references Inventory. This folder's assembly is the only place the two systems meet.

Integration Scene

This folder also includes a demo scene that shows:

  • World pickups granting items into Inventory
  • The same pickup flow working alongside non-Inventory behaviour
  • InventoryQuickstartPanel used to visualise results

👉 This scene exists to demonstrate integration — not to define how Pickups must be used.

How It Works

The Inventory API is called directly. This folder's assembly references RevFramework.Inventory, so every call is checked at compile time.

Resolution

The effect resolves a service from the actor that triggered the pickup:

  • InventoryResolve.ServiceFrom(GameObject)

ServiceFrom returns the concrete SceneInventoryService. If one is found, the effect builds an ItemStack from its itemDefinition and quantity and calls:

InvOpResult GiveExact(GameObject owner, ItemStack stack, ContainerId container)

The containerKey you type in the inspector is a string; ContainerId converts from one implicitly, and trims and lower-cases it, so casing does not decide which container is used. The effect returns whatever the inventory returned — see Refusals are reported, below.

This page used to describe a reflection design, and the reason it no longer does is worth knowing. The effect once resolved the service, built the stack and found the method entirely by name, so that Pickups would not have to reference Inventory. Three of those lookups were wrong — the assembly name, the ItemStack namespace, and the string container key, which reflection hands to a ContainerId parameter without applying the implicit conversion the compiler would have. Every one failed silently, so the effect granted nothing for the whole life of that design. Calling the API directly turns that class of mistake into a compile error, and the decoupling is still real: it is enforced by the assembly definition instead (below).

Important

This is optional

  • Pickups do not require Inventory
  • This integration only runs if a compatible Inventory service is present

No hard dependency

  • The Pickups assembly does not reference Inventory — this integration assembly does
  • That assembly is gated on REV_PICKUPS_PRESENT and REV_INVENTORY_PRESENT, so it compiles only when both systems are installed and disappears cleanly when either is removed
  • You can remove this folder without affecting Pickups

Scene dependency

The demo scene in this folder does depend on Inventory.

If you remove the Inventory module:

  • This scene will no longer function
  • It can be safely deleted, or
  • Cleaned up using the RevFramework Orphan Cleanup tool

Refusals are reported

The effect grants nothing and reports failure when:

  • itemDefinition is empty or is not an ItemDefinition asset, or quantity is zero or less (Editor warning)
  • no Inventory service resolves from the actor (Editor warning)
  • the inventory refuses the grant — a full container, a slot restriction, an unknown container key (Editor warning carrying the inventory's own result code)

👉 The effect fails safely rather than throwing.

It also implements IPickupEffectReportsDelivery, so the refusal is visible to the pickup rather than only to the console: TriggerPickup leaves a refused pickup in the world instead of destroying it, so the actor can come back for it once there is room.

Supported setup only

This integration is designed for use with the RevFramework Inventory system.

It relies on:

  • InventoryResolve
  • The standard RevFramework Inventory service
  • The RevFramework ItemStack structure

👉 A custom inventory cannot be substituted here by matching method names. The effect binds ItemDefinition, ItemStack and the RevFramework service type at compile time, so anything else is a compile error rather than a silent no-op.

If you are using a different Inventory system:

  • Treat this as a reference example
  • Implement your own pickup effect
  • Use your own service layer

Example Usage

  1. Create a GiveItemPickupDefinition

  2. Assign:

  3. itemDefinition → your Inventory item

  4. quantity → amount

  5. containerKey → target container

  6. Assign the definition to a pickup

  7. Ensure an Inventory service is present in the scene

👉 When the pickup is consumed, the item will be granted if a compatible service is found.

Design Intent

This integration demonstrates:

  • How Pickups can interact with other RevFramework systems without hard coupling
  • How to keep an optional dependency compile-checked, using a define-gated assembly rather than reflection
  • How to keep systems modular and optional
  • How to structure integration scenes vs core system scenes

Third-Party / Custom System Use

This integration is built for RevFramework Inventory systems only.

If you are using a different inventory system:

  • Treat this as a reference example
  • Implement your own pickup effect or adapter
  • Use the public APIs of your system

👉 Custom or third-party integrations are not supported by this layer.

Safe to Remove

This folder is completely optional.

Removing it will:

  • Not affect the Pickups runtime system
  • Not break non-Inventory pickups
  • Only remove Inventory-related pickup behaviour and demo scenes

Summary

This integration answers:

“How can pickups grant items without the Pickups system depending on Inventory?”

It provides:

  • An item grant effect that compiles only when both systems are present
  • A working integration example
  • A safe, optional extension point
  • A clear integration pattern

Use it as a reference, extend it, or replace it entirely.