Possible Replace Implementation

Disclaimer: This is about possible implementation so dont yell at me if you dont understand just because you've never programmed something before. Or maybe I word it so that anyone understands, who knows. This is also speculation since I dont actually know how the game is coded, its just how I think it is / how I would have done it. I initially was going to make a long comment but it started to get really long.
This only really works for armour cubes, Hardware would take a lot of extra collision checking. Besides its not that hard to replace 6 SMGs, is it?
________________________________________________________________________________________________________________________
Assuming:
* the garage is stored as a 3D array of cube elements
* each cube element contains what type of cube and its orientation

Undoubtedly changing all the cubes would involve searching the entire array for cubes of the same type as requested. While counting them all, and then after confirming the amount needed/ needed to be bought, simply changing the value of the tier of the block.

Now the as for how long each process will take (with big O notations);
* Searching the garage for cubes of a certain type: 68921 (41^3) elements for Mega garage, and 29791 (31^3) for the normal sized. This can never be made quicker as every block needs to be checked. O(n)
* Checking availability of replacement; almost no time at all, just a few lines of code O(1)
* Replacing the blocks can be done differently with different times associated:
** 1. save the location of each block while searching, then replacing those blocks. O(n) (faster)
** 2. search the whole array AGAIN, this time replacing the blocks appropriately. O(n) (much slower)

To get the cube list using this implementation you would need a button "Get Cube List" which would search the array to generate the list. This can be made automatic but will need a different replacing algorithm. For now doing it when you need it is the better option.
________________________________________________________________________________________________________________________
Here's two implementations to have the list generate on the go. Now that I think about it this would actually speed up the replacing algorithm :^) but potentially use up slightly more(1) or much more(2) memory :^(

Again assuming:
* the garage is stored as a 3D array of cube elements
* each cube element contains what type of cube and its orientation

(1) This time as you are building the bot, the game is saving the number of different cubes to variables, not their location just their amount. (This will use a little bit of memory but not a whole lot, so its OK).
This lets it skip the first Array search from the other implementation but forces it to have to search during replacement. (At least it gets to stop once its replaced all the blocks and not have to search the rest of the array)
This way the list is constantly generating and updating easily and could even be displayed while in the garage.

(2) This method has the potential for the most functionality additions to the garage.
As you are building the bot, the game is saving the number of different cubes AND THEIR LOCATION to variables. (This will use a lot more memory but there are ways of saving rows of cubes not just individual cubes Eg: start of row -> end of row)
This not only lets you skip the first search like the last algo, but also means you already know where the cubes are and can just replace them quickly. (so no second search)
The list is also constantly generating and updating easily like the last one, but now its more than just a list.
This effectively saves a model of the build without functional cubes which could be used to show different layers and allow the player to get easier views to the inside of the bot.
________________________________________________________________________________________________________________________
Both of these last two would require an initial search upon the update obviously but thats not important.