# Existing Fusion Project? Read This First

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.
