Bugs. They seem to appear out of no where and affect things that you’d finished ages ago.
With the new arrays in GMS2.3 I discovered a rather unusual aspect for how they are saved/stored and used.
Other programming languages I’ve used have for game dev have multidimensional arrays such as: MyArray(10,10) which creates a grid variable that is 10 wide and 10 high, so each row (X,0) has 11 elements (including the zero) up to (X,10). Nice and straightforward. However, javaScript (which GML is based on) uses the array in an array method.
GMS2.3 switched to using a more modern form of array from the previous GMS2.2 version. So, I assumed it would work the same as every other language I’ve used. You can create elements dynamically in an array so I could do:
myArray[0][4] = “something”;
And this would add in a 4 slot to the multidimensional array. However, what I didn’t realise is that because these are in essence arrays in arrays just because [0] now has 4 slots doesn’t mean that [1] also has 4 slots.
Why does this matter? Well, the inventory in the game is stored in a 2 dimensional array and each sub-element represents the skills that inventory object can use, such as examine object, or player usable.
When my save routine was processing the entries I merely took the width (number of elements) of the first row in the array_length(myArray[0]), this however only ever had 3 sub-elements and so the fourth, reserved for player usable objects, was ignored when saving. When the game was reloaded all these objects would loose the ability to be used in the environment.
After realising my error I changed the save code to work out the width of each array row as it went along.
