Spawn a UIS player only after the configured Inventory System Manager and database are ready. The player prefab owns the Inventory, Item Collections, Currency Owner, Inventory Identifier, input, and interaction components; the project, character controller, or networking solution owns the spawn point, prefab instantiation, respawn rules, and authority.

Released Ultimate Inventory System Version 1 does not include a player spawner or spawn-point component. Its role begins when the configured player GameObject becomes active.

Understand the spawn sequence

Use this order for a new player:

  1. Initialize the configured Inventory System Manager and its database.
  2. Initialize Save System Manager when the player will restore saved data.
  3. Instantiate the configured player prefab at the project-owned spawn point.
  4. Let Inventory, Currency Owner, Item User, and Inventory Identifier initialize in Awake.
  5. Let Inventory Interactor and saver components initialize in Start.
  6. Assign or resolve the UI’s Panel Owner.
  7. Load saved data only after the replacement player’s savers have registered.
  8. Announce player readiness through the project spawner or networking layer.

Do not use an early static UIS lookup to discover whether setup exists. If no configured Inventory System Manager is active, static access can create an empty InventorySystemManager GameObject with no database. Establish the manager root first and then spawn the player.

Prepare the player prefab

  1. Open the player prefab in Prefab Mode, or select a scene instance that will be applied back to the prefab.
  2. Open Tools > Opsive > Ultimate Inventory System > Main Manager.
  3. Select Setup.
  4. Under Character Setup, assign Character Gameobject.
  5. Select Add Components.

Character Setup adds these components when they are missing:

  • Inventory Identifier;
  • Inventory;
  • Item User;
  • the released Version 1 Unity Input implementation;
  • Inventory Interactor; and
  • Currency Owner.

Character Setup sets the added Unity Input component’s cursor options Enable Cursor With Escape and Disable Cursor off. It does not choose a player prefab, spawn point, database, Item Collections, loadout, UI, or network owner.

Configure the player identity

Keep Inventory Identifier on the same GameObject as Inventory, Currency Owner, and Item User for the standard workflow.

Inspector field Version 1 default Spawn requirement
Inventory Identifier > ID 1 Must be nonzero, unique among live players, and stable when UI or saves refer to the player
Item User > Inventory Input None Resolves a compatible player input component from the same GameObject
Inventory Interactor > Inventory None Resolves Inventory from the same GameObject in Start
Inventory Interactor > Interactable Indicator None Optional project visual shown when interaction is available
Inventory Interactor > Auto Interact Off Leaves interaction on input rather than triggering automatically
Inventory Interactor > Input Action, Button Down Default interaction input configured by the component

Inventory Identifier registers itself with Inventory System Manager in Awake. When two live identifiers request the same ID, Version 1 may assign a generated ID to the later object. Treat that as an error for player ownership; configure unique IDs rather than depending on runtime reassignment.

Configure Bag, Equipment, Items, and Gold

Character Setup creates the components but not the finished player data model.

  1. In Inventory, name the main Item Collection Bag and keep its purpose as Main.
  2. Add an Item Slot Collection named Equipment when the player equips Items into fixed slots.
  3. Add one Health Potion to Bag’s Default Loadout for a visible spawn test.
  4. Add or equip an Iron Sword according to the project’s Equipment workflow.
  5. In Currency Owner, configure Currency Amount with a known starting Gold value.
  6. Confirm that every referenced Category, Definition, Item, and Currency belongs to the database assigned to Inventory System Manager.

An Inventory with no serialized collection creates one fallback collection named NewItemCollection and marks the first collection as Main, but it has no project-specific structure or restrictions. Configure Bag and Equipment explicitly on the prefab.

Inventory applies each collection’s Default Loadout after all of its Item Collections initialize. A non-additive Inventory Saver load later clears the current collections before restoring the saved state, preventing the default Health Potion from being added on top of a normal replacement load.

Choose the spawn point and prefab lifetime

Use the project spawner, Unity scene loader, character controller, or networking solution to choose the spawn Transform. Instantiate with the final position and rotation so character and project Awake logic sees the intended pose.

Choose one player lifetime:

Lifetime Behavior UIS consequence
Scene-owned player Destroy and respawn on each scene Save before unload and load after the replacement savers register
Persistent player Apply DontDestroyOnLoad to the player root in project code Inventory, Equipment, Gold, identifiers, and UI owner references remain in memory
Respawn in the same scene Destroy and instantiate a replacement Decide whether death retains, clears, or reloads Inventory and Currency before the new player becomes ready
Pooled player Disable and reuse an object Requires a custom identifier lifecycle; Inventory Identifier does not automatically unregister on disable

Do not spawn a scene-owned player when a persistent copy already exists. Duplicate Inventories, identifiers, inputs, savers, and UI owners can all appear valid individually while operating on different player objects.

For pooled players, Version 1 exposes InventoryIdentifier.Unregister() and RegisterIdentifier(), but unregistering resets the registered ID. A custom pooling layer must restore the intended ID and registration deliberately before making that player authoritative again.

Connect the player and UI

Display Panel Manager supports either relative spawn order.

UI exists before the player

When Panel Owner is empty and Panel Owner Inventory Identifier ID cannot be found, Display Panel Manager registers itself, logs a warning, and disables its GameObject. Add Dynamic Panel Owner to the player prefab and keep its Display Panel Manager ID matched to the intended UI.

Released Version 1 defaults are:

  • Display Panel Manager > ID: 1;
  • Display Panel Manager > Panel Owner: None;
  • Display Panel Manager > Panel Owner Inventory Identifier ID: 1; and
  • Dynamic Panel Owner > Display Panel Manager ID: 1.

Dynamic Panel Owner calls SetPanelOwner in Awake. The manager then initializes its panels and re-enables the UI GameObject.

Player exists before the UI

When the UI appears later, Display Panel Manager resolves the registered Inventory Identifier whose ID matches Panel Owner Inventory Identifier ID. No Dynamic Panel Owner is required for this order, although using it consistently is valid when the matching panel manager already exists.

Player and UI spawn together

Load or instantiate them only after Inventory System Manager exists. Keep the UI and player IDs matched. If they are in an additive player/UI scene, do not put a second Inventory System Manager in that scene.

The Display Panel Manager owns UI selection, not the player spawn lifecycle. Use its OnPanelOwnerAssigned event or the Opsive owner-change event when project UI must react to a new owner.

Restore saved state after spawning

When a newly spawned player should continue an earlier Inventory:

  1. Under Main Manager > Setup > Save Setup, assign the player prefab or instance to Object to save and select Add Components.
  2. Confirm that Inventory Saver and Currency Owner Saver are present.
  3. Confirm that the manager Game root has Save System Manager and Inventory System Manager Item Saver.
  4. Keep Inventory Saver Additive off for a replacement restore.
  5. Keep the player’s GameObject name and each saver’s Key stable between saves.
  6. Call SaveSystemManager.Load(slot) only after the new savers reach Start.

When Save System Manager preloads the slot before the player exists, enable Load On Start on the player’s savers. For scene unloads, enable Save On Destroy or save explicitly before destroying the old player. See Save System and Scene Transitions for the full timing model.

For Ultimate Character Controller characters, use the integration’s Inventory Bridge Saver instead of the standard Inventory Saver.

Multiple spawned players need stable, unique saver full keys as well as unique Inventory Identifier IDs. Rename the runtime GameObjects before saver Start, or use distinct configured prefab variants/keys, so two Player(Clone) objects do not compete for the same saver key.

Keep the Inventory separate only for advanced setups

The standard prefab keeps Inventory, Currency Owner, Item User, Inventory Identifier, input, and Inventory Interactor together. This lets each component resolve its dependencies from the same GameObject.

An Inventory can live on another GameObject, such as a persistent UI root, if Inventory Identifier remains beside that Inventory and project code resolves it by ID. This is an advanced ownership model:

  • the visible character must obtain that external Inventory explicitly;
  • Inventory Interactor looks for player input on the Inventory GameObject and therefore does not support this separation without customization;
  • same-GameObject fallbacks in other UIS components must be reviewed; and
  • the external Inventory’s lifetime, identifier, UI owner, savers, and network authority must remain aligned.

Prefer the standard co-located prefab unless persistent inventory ownership is a deliberate architectural requirement.

Configure local multiplayer and networking

For local split-screen:

  1. share one Inventory System Manager and database;
  2. give every player prefab a unique, nonzero Inventory Identifier ID;
  3. give every UI a unique Display Panel Manager ID and matching Panel Owner Inventory Identifier ID;
  4. connect each UI root to its intended EventSystem through Event System Identifier;
  5. give every saved player a stable GameObject name or saver Key; and
  6. verify that each input implementation belongs to the correct local player.

Configure identity on prefab variants or before activation when other Awake logic requires the final ID. Changing the ID after instantiation unregisters and re-registers the Inventory Identifier, but any component that already cached the earlier identity must also be rebound.

Released UIS Version 1 has no network player-spawn, ownership, prediction, replication, or scene-migration component. Inventory Identifier ID is a local UIS lookup key, not a network object ID. Let the networking layer spawn the authoritative prefab, assign network ownership, choose the UIS ID, synchronize Inventory/Currency mutations, and announce readiness. Do not let every client independently apply a default loadout or local save to the same network player.

Editor checkpoint

Before entering Play Mode, confirm that:

  • the configured Inventory System Manager and database load before the player prefab;
  • the prefab contains Inventory Identifier, Inventory, Item User, player input, Inventory Interactor, and Currency Owner;
  • Inventory Identifier ID is nonzero, stable, and unique;
  • Bag is the main Item Collection and Equipment uses the intended slot collection;
  • the Health Potion, Iron Sword, and Gold references belong to the active database;
  • the spawn system instantiates the intended prefab at the intended Transform;
  • the UI’s Display Panel Manager and Panel Owner IDs match the player;
  • Dynamic Panel Owner is present when UI can exist first;
  • savers and stable keys are configured when spawned state must be restored; and
  • split-screen or network ownership is assigned before the player is announced as ready.

Verify in Play Mode

  1. Start with the player absent and confirm that exactly one configured Inventory System Manager is active.
  2. Spawn the prefab at a visibly different test point and confirm its position and rotation.
  3. Resolve the configured Inventory Identifier ID and confirm that it returns the spawned player.
  4. Confirm that Bag contains the default Health Potion, Equipment follows its configured starting state, and Currency Owner has the expected Gold.
  5. Open the Inventory UI and confirm that it shows and modifies this player’s Inventory.
  6. Pick up an Item or interact with a Shop to verify Inventory Interactor and input ownership.
  7. Destroy and respawn the player. Verify the designed rule: reset to defaults, retain a persistent Inventory, or restore the save after saver Start.
  8. Spawn a second local player and confirm that IDs, UI, input, EventSystems, and saver keys remain separate.
  9. Change scenes and confirm that the chosen persistent or recreated-player model does not produce duplicates.
  10. In a networked test, verify on a remote client that only authoritative replicated state determines Items and Gold.

Troubleshooting

Symptom Check Fix
Spawning logs that the database is null The configured manager did not initialize before player Awake Establish the manager/bootstrap first and delay prefab activation
GetInventoryIdentifier(id) returns null ID is 0, the prefab is inactive, the manager register was recreated, or spawning has not reached Awake Use a stable nonzero ID and query after the active prefab registers
The second player receives an unexpected ID Another live Inventory Identifier already uses the serialized ID Assign unique prefab IDs and remove duplicate players
The player has no Bag or useful Item Collection Character Setup added Inventory but the prefab data model was never configured Add and name Bag/Equipment collections in the Inventory Inspector
The Health Potion appears twice after loading Inventory Saver Additive is on, or project code reapplies the loadout after load Use a non-additive replacement load and initialize defaults only once
Gold resets on respawn Currency Owner Saver is missing or no explicit persistence rule exists Add the saver and load after Start, or keep Currency Owner persistent
Interaction input does nothing Inventory Interactor cannot find Inventory/player input, or UI left gameplay input disabled Keep dependencies together, assign them explicitly, and verify UI/input events
UI remains disabled Display Panel Manager has no owner Match Panel Owner Inventory Identifier ID or use Dynamic Panel Owner
UI controls the wrong player Player, Display Panel Manager, or EventSystem ownership IDs are crossed Give every local player/UI pair a unique and matching configuration
Saved players overwrite each other Spawned GameObjects and saver Key values produce the same full key Rename each player before saver Start or use unique configured saver keys
A pooled player’s lookup points to an inactive object Inventory Identifier does not unregister on disable Add an explicit pool registration lifecycle or avoid pooling the identity owner
A remote client has different Items or Gold Local spawn defaults or save loading ran without network authority Let the server/host initialize and replicate the authoritative state

Version 1 boundaries

  • No built-in player spawner, spawn point, respawn controller, or network player authority is supplied.
  • Character Setup adds components; it does not configure Item Collections, default Items, Gold, UI, saves, or spawn rules.
  • Inventory Identifier registers in Awake; Inventory Interactor and savers complete relevant setup in Start.
  • Inventory Identifier does not automatically unregister when a pooled player is disabled.
  • Display Panel Manager can wait for a player owner, but the project decides when the player is ready for gameplay.
  • Database IDs, Inventory Identifier IDs, saver keys, collection layout, and UI IDs must remain stable when saves or persistent references depend on them.

Developer details

Spawn and validate the prefab

The project spawner should instantiate the prefab at the final pose, give each runtime player a stable name before saver Start, and verify the identity serialized on the prefab:

using Opsive.UltimateInventorySystem.Core;
using Opsive.UltimateInventorySystem.Core.InventoryCollections;
using UnityEngine;

public class UISPlayerSpawner : MonoBehaviour
{
    [SerializeField] private GameObject m_PlayerPrefab;
    [SerializeField] private Transform m_SpawnPoint;
    [SerializeField] private uint m_ExpectedInventoryID = 1;

    public GameObject Spawn()
    {
        if (InventorySystemManager.IsNull ||
            !InventorySystemManager.Instance.IsInitialized ||
            InventorySystemManager.Instance.Database == null) {
            Debug.LogError("Spawn the configured Inventory System Manager first.");
            return null;
        }

        var player = Instantiate(
            m_PlayerPrefab,
            m_SpawnPoint.position,
            m_SpawnPoint.rotation);

        player.name = $"Player_{m_ExpectedInventoryID}";

        var identifier = player.GetComponent<InventoryIdentifier>();
        if (identifier == null || identifier.ID != m_ExpectedInventoryID) {
            Debug.LogError("The player prefab has the wrong Inventory Identifier ID.", player);
        }

        return player;
    }
}

Instantiate invokes Awake before returning for an active prefab, so the expected Inventory Identifier ID must already be serialized on that prefab when other Awake logic depends on it. The runtime name change still occurs before the new object’s first Start, when SaverBase registers its full key.

Resolve the player and bind the UI

After the player has registered:

const uint playerID = 1;
const uint panelManagerID = 1;

var identifier = InventorySystemManager.GetInventoryIdentifier(playerID);
var inventory = identifier?.Inventory;
var currencyOwner = identifier?.CurrencyOwner;
var panelManager = InventorySystemManager.GetDisplayPanelManager(panelManagerID);

if (identifier != null && panelManager != null) {
    panelManager.SetPanelOwner(identifier.gameObject);
}

Use Inventory.IsInitialized as an Inventory readiness check. When a saved spawn is required, also wait for its Saver components to register before calling SaveSystemManager.Load.

UIS has no player-spawned event. The project spawner should publish that lifecycle signal after identity, UI ownership, and optional save restoration are complete. Useful V1 notifications after that point include DisplayPanelManager.OnPanelOwnerAssigned, EventNames.c_OnPanelOwnerChange_GameObjectPanelOwner_DisplayPanelManager, and the Inventory update/add/remove events documented on Events.