[BUG] Inventory System Manager sometimes fails to get Item when Serializing Save Data

Mr. Singer

New member
Greetings. I've been struggling with a bug in which in rare occasions, seemingly at random, the SerializeSaveData function in the InventorySystemManagerItemSaver class will return a null value at line 134. This does not immediately break the game, but once it occurs, other savers seem to start failing during subsequent reloads, which then causes a host of other issues.

Of note is that the itemID is always retrieved successfully, but the manager does not return the item. I've triple-checked all item categories to ensure they're not Immutable & Common, as I've read that can cause issues.

What perplexes me is the randomness of the bug. 9 times out of 10, everything works without problem, and no error appears when I save. What could be causing this? Thanks.

1790807370864.png
 
The immediate failure is that the Item Saver has an item ID recorded for a saver, but the Inventory System Manager cannot resolve that ID to a live Item at save time. The immutable/common warning is checked only after that lookup, so it would not explain a null result from the lookup itself.

This most likely indicates a stale saved-item reference—such as an Item being removed, destroyed, replaced, or recreated while its saver entry still retains the old ID—but the supplied information does not establish which lifecycle path causes it.

Please add temporary logging immediately before the failing lookup and report:

1. The saver full key and item ID being processed.
2. Whether that Item is still present in its expected Inventory/Item Collection immediately before saving.
3. What happened to it since it was registered: transfer, removal, consumption, replacement, scene unload, pooling, or load.
4. The complete exception and stack trace from the first failure.

In particular, compare a successful save with the failing one for the same saver key. If the ID belongs to an Item no longer in the collection, the issue is stale saver registration/lifecycle cleanup. If the Item remains present but the manager still cannot resolve its ID, please include the item's runtime ID and the manager/database initialization order around the save/load cycle so we can narrow down why its registration is missing.
 
I've added the following lines to log the saver key and item ID when the item is null:
1791320533371.png

Here's what I've found:
1. Here's the Saver key and item ID of a successful save:
1791320566850.png
And here's the Saver key and item ID for the same item when the error occurs:
1791320578043.png
As you can see, the ID is the same in both cases.
2. The item is still present in its expected Inventory immediately before saving.
3. The bug occurs (only rarely) after picking up an item and then saving using Pixel Crusher's Dialogue System for Unity's saving system. This saving system is linked to UIS using the UIS Saver provided by Pixel Crushers. Upon pick up, the pickUpItem prefab is destroyed, and the item itself is added to the Equipped collection. Then, I have the game save automatically after a 3 second delay. Of note is that the bug can occur even when this is the first and only item the player has picked up in the game.
4. Error Stack Trace:
1791320632636.png
The item remains present in my inventory after the error occurs, so it would seem a stale saver registration is not the cause. Where can I seethe item's runtime ID and the manager/database initialization order? Thanks.
 
You can read the runtime ID from the Item instance’s public ID property. Log it at the point where your pickup code receives or adds the Item, for example:

C#:
Debug.Log($"Picked up item ID: {item.ID}, initialized: {item.IsInitialized}");

Then log that same ID immediately before the save request. Since the lookup has already returned null at the saver, capture the ID from the Item reference in your own pickup/equip flow rather than from the null result.

For initialization order, the Inventory System Manager initializes from its Awake method. Add frame-numbered logs in your own components at pickup completion, just before Dialogue System starts its save, and wherever your player inventory is created or loaded. Include Time.frameCount and the Item ID in each log.

The important comparison is whether the equipped Item’s ID on the failing save frame matches the saver’s stored ID. A matching ID would rule out an obvious replacement of the Item instance, but it still wouldn’t explain why the manager cannot resolve it; the pickup/save frame sequence would then be the next useful detail.
 
Last edited:
Hi @Mr. Singer
This really is a weird bug.

If GetItem returns null it must mean the item with that ID is not registered. So like Atlas said maybe it was removed/destroyed/unregistered between the Saver retrieving the ids to save and the saving.

Or perhaps the item was never registered with that ID in the first place.

The fact that it is random makes me think it's an excution order issue but I could be wrong.

one thing to take into account, your statement here is incorrect:
> ensure they're not Immutable & Common, as I've read that can cause issues.

Immutable & common is the easiest and most reliable combination as the ID is static and does not change from the one defined in the itemDefinition default item

Mutable & common is the combination that is a bit more complicated to handle as it tries to merge items with similar attributes into one item reference

Unique (whether Mutable or Immutable) always gives a new id when creating the item, so it's predictable, once it's given an id it will stay unique and won't change. Only it's attributes can change

I hope that makes sense.

If you can manage to replicate this issue in the demo scene. Or create a easily reproducable scene then I can try to replicate it internally and see if we can figure out the issue and fix it.
In the meantime, if you know how to use breakpoints in your IDE you could try adding a breakpoint at the line GetItem and step through the function and inspect the list/dictionary of registered items to see if you can find anything weird, like your item being registered with a different ID
 
Back
Top