Existing Fusion Project? Read This First

Integrating the Runtime Spawner into an existing Fusion project

If your project already uses Photon Fusion with a custom pooling setup, please read this section before enabling Runtime Spawner’s Fusion integration.

Runtime Spawner Requires Its Own Fusion Pool Provider

Runtime Spawner includes a component called FusionPoolObjectProvider, which becomes the single INetworkObjectProvider for the NetworkRunner. Fusion only allows one provider at a time, which means:

• Any existing pooling system (custom provider, custom IPoolAdapter, or Fusion’s default provider) will be replaced by Runtime Spawner’s provider.

• Fusion will still handle network lifecycle, but Runtime Spawner will now manage all object pooling.

This is required to ensure:

• Proper reuse/despawn behavior for Runtime Spawner–spawned objects

• Consistent population tracking

• Network-safe object recycling

• Correct cleanup before returning objects to Fusion’s internal pool

What You Need to Do

If your Fusion project previously had pooling logic, you have three options:

1. Prefab-Level Pool Logic (Recommended) Move any “OnSpawned/OnDespawned” or reset logic onto the prefab using OnEnable / OnDisable. Runtime Spawner will call these at the correct times.

2. Use Runtime Spawner’s Spawn/Despawn Events Subscribe to Runtime Spawner’s events if you need global visibility over active objects.

3. Advanced: Wrap the Provider If you must keep custom provider-level behavior, you can implement a wrapper provider that forwards calls to FusionPoolObjectProvider.

---

TL;DR

• Runtime Spawner becomes the pooling system used by Fusion.

• You may need to move your old spawn/despawn logic.

• Runtime Spawner provides extension points so you can still run custom logic on pooled objects.