RevFramework – Pickups • FAQ¶

This FAQ answers decision questions about the Pickups system.

It is not a feature list or a repeat of the READMEs — it exists to help you decide:

• Is this the right extension point?
• Why does this behave the way it does?
• Am I integrating this correctly?

If you’re looking for setup or API details, see the folder READMEs instead.

This page focuses on integration decisions and architectural intent, not basic usage.

How do I integrate Pickups into my game?¶

World pickups (fastest path)¶

Use this when the pickup should trigger automatically on contact.

Do this:

• Add TriggerPickup to a prefab
• Add TriggerRelay2D or TriggerRelay3D
• Assign a PickupEffect (usually built from a Definition)
• Set layer/tag filters if needed

Avoid:

• Writing custom trigger logic
• Calling effects directly from OnTriggerEnter
• Adding the TriggerPickup at runtime, after Instantiate — the relay resolved its one receiver in Awake, which has already run, so the component you add is never wired to it and the pickup silently never fires. Author it on the prefab.

Interactable pickups (player input)¶

Use this when the pickup requires player intent.

Do this:

• Subclass InteractablePickupBase
• Implement DoPickup(GameObject actor)
• Trigger success/failure via return value

Avoid:

• Putting effect logic directly in the interactable
• Mixing input handling with effect execution

Is Pickups tied to Inventory, Health, or Currency?¶

No.

Pickups is modular:

• Inventory integration is optional (via custom effects)
• Currency integration is optional (via custom effects)
• Health integration is optional (via custom effects or bridges)

Pickups itself introduces no hard dependency on these systems.

If an integration is not present:

• behaviour depends on your effect implementation
• some effects may safely do nothing
• others may require guards or null checks

Pickups does not enforce integration behaviour — your effects do.

Why didn’t my pickup apply its effect?¶

Check these in order:

1. Authority¶

• Is an IPickupAuthority present and returning false?
• No authority = allowed by default

2. Null-damageable rules¶

• Does the effect require IDamageable?
• If yes and missing → effect will not run

3. Conditional decorators¶

• Tag, RNG, or other conditions may block execution

4. Cooldowns¶

• Effect may still be on cooldown for that owner

5. Layer / tag filters¶

• TriggerPickup may be rejecting the actor

Why did my pickup trigger twice?¶

Usually caused by multiple colliders on the same actor.

Examples:

• capsule + feet collider
• rigidbody + child colliders
• composite 2D setups

Pickups prevents duplicate consumption within a single physics step using an internal latch.

A step is the right scope even for a pickup set to destroy on use, whose Destroy does not take effect straight away: Unity flushes pending destroys between physics steps rather than at the end of the frame, so a pickup that has paid out is already gone by the next step and cannot be entered again. A frame that runs several physics steps does not open a gap. That is the engine's behaviour rather than ours, so it is pinned by a test.

If it still happens:

• check for multiple pickup components
• check overlapping interactables
• check duplicate relay components

Should I put gameplay logic in Effects or Interactables?¶

Interactables should:

• decide when a pickup happens
• not decide what the effect does

If logic lives in interactables, it becomes:

• harder to reuse
• harder to decorate
• harder to test

When should I use a Decorator vs a new Effect?¶

Use a Decorator when:¶

• adding cross-cutting behaviour (VFX, SFX, logging, conditions)
• behaviour should apply to multiple effects
• core effect should remain unchanged

Use a new Effect when:¶

• implementing new gameplay logic
• behaviour is specific and not reusable

Why are Decorator priorities "backwards"?¶

They are explicit and deterministic:

• Lower values = inner
• Higher values = outer

At runtime:

• outer decorators run first (BeforeApply)
• inner decorators run closest to the core effect

Does Pickups handle multiplayer replication?¶

No. By design.

Pickups only answers:

“Can this actor consume this pickup?”

Replication, prediction, rollback, and despawning belong to your networking layer.

Pickups provides:

• authority hooks
• clean execution seams

Can I safely remove parts of Pickups?¶

Yes — if you respect boundaries.

Typically safe to remove if unused:

• feedback components
• specific decorators or effects

If other systems are removed:

• Pickups still works
• related effects must handle missing integrations safely

Is Pickups meant for no-code designers?¶

No.

Pickups is designed for developers who:

• are comfortable with C#
• want explicit, inspectable behaviour
• prefer modular systems over hidden logic

Designers can author Definitions, but system behaviour is developer-driven.

Final Guidance¶

If you’re unsure where something belongs: