koobas.hobune.stream
Selecting GameObject in hierarchy during runtime alters variables
Short story: In runtime, if ever I select my player in the hierarchy all of the null InventorySlot.Item class objects in my player inventory get magically initialized no longer returning null.
Long story: Clicking on the player GameObject causes the problem... that right there has me stumbled. The list in question:
[HideInInspector] public List<InventorySlot> equipmentSlot;
is quite simply a list of a class that stores some enums and an itemAmount int, nothing fancy. I have checked all references to it project wide, I have added Debugs into everything that goes anywhere near it, and ONLY when I click on the player GameObject in the hierarchy does the problem occur.
The problem: when the game starts the List is initialized setting the Item variable in each InventorySlot to null, because there are no items in our inventory yet. I can confirm that with Debugs in runtime, they are null. Then I click on the player GameObject in the hierarchy, and call the same Debug, now the Item is not null and returns as an initialized Item, but of course all of it's variables are empty and now the game doesn't know what to do with it.
How does that make any sense?? Monobehaviors respond to in editor selection some way that I don't know about?
The Count of the List remains unchanged. The order of the list remains unchanged. The InventorySlots that have things in them, or in other words are not null, go unaffected. The InventorySlots that are null somehow are magically assigned an empty Item.
The InventorySlot class doesn't even default to an initialized Item, it loads them as null:
public class InventorySlot {
public int slotNumber = -1;
public int itemAmount = 0;
public Item item = null;
public InventorySlotTypes slotType = InventorySlotTypes.Null;
}
I can pause, click on everything else in the scene, unpause no problems. Pause, click on the player, deselect the player, unpause and the inventory is broken. By broken I mean empty slots are supposed show their Item as null, but now they are all initialized somehow.
Would never happen to a player in a real build sure, ya I could hack around it to find empty items and reset them as null, but what in the heck is going on??
There's only one reason I can think of this is happening. When writing custom inspectors, whenever a gameobject is selected, a MonoBehaviours serialized values get read and written to, depending on what code is used. maybe the same is happening for classes that do not have a custom inspector. List<InventorySlot> is public, therefore serialized for the inspector. For the serialization, null does not exist and an actual instance information is saved. Maybe, without using a custom inspector, the default is just that, write the serialized values to the actual gameobject.
You should be able to check that by simply adding the NonSerialized attribute in addition to the HideInInspector attribute, like so [HideInInspector, NonSerialized]
Thank you @hexagonius NonSerialized did in fact prevent the problem Haven't 100% wrapped my head around the answer and all possible scenarios, but your explanation makes sense. Thank you for the enlightenment.
To word it a little different as I understood it: Calling on the inspector preview of the script was the cause which happens when the inspector tab is visible and the gameobject with the script attached to it is selected. This attempts to initialize any public variables as per serialization is required to show them in the inspector. I was using the HideInInspector attribute to hide the public List, but it was still being processed by the inspector. Adding NonSerialized stopped the initialization behavior. This also has not interrupted my write to disk functions which I take to mean the List is still serializable, it's just not automatically serialized unless explicitly done.
Started happening a week ago sporadically I had no idea what was causing it!! Glad it's off my plate! Thanks again.
