Notes
They are just kinda stupid. A parent class with .valid and .class would be cool, as well as using metatables to avoid the silly duplication of all collection methods on every class. Will probably be a bit annoying to restore the metaclasses, but I think I can handle it now. LuaBootstrap::register_metatable might also play into this now.
Also, having generic add/remove/etc methods even though most of the time, there is only one class of object stored, is dumb, and should be un-genericized.
Should also use metatables to make accesses like factory[1] get the first subfactory. Trickier for places where there’s more than one class associated, will have to think about it.
Subfactories having a list of all floors in them is kinda weird, see if I can get away with dropping that list. Alternatively, maybe subfactories are dumb, and everything should just be floors. There’s probably a few issues with that, but it should be solvable. This would help with a lot of pain points that relate to the top floor being special etc.
Also, maybe Line should be split up into Line and FloorLine, which is special for the lines with subfloor. Makes the split a bit less messy, since they are basically two mostly distinct classes in one currently.
Consider renaming Line to Recipe (and integrating the recipe class into it since it’s tiny). Recipe is what it’s called in the GUI anyways, and Line is kinda bland, so why not.
Maybe collections should not have gui_position, but be a linked list instead. Saves on complication and keeping track of count most likely. If I could get rid of the index variable, collections could be simplified further to just the linked list. I’d still need IDs, which could potentially be a randomly generated UUID, instead of just incrementing a counter. Alternatively, I could have a separate incrementing counter that’s shared between all objects. If using linked lists, give each class iterator functions for easy traversal. Instead of having a complicated cached index to find things by ID, just have one global one (possible because IDs are globally unique) that gets you to the object, populated on_load by going through the whole data structure. This saves me any complicated caching structure, and allows me to find any object by just its ID, instead of needing all its parents IDs as well.
For subfactories specifically, maybe I Factories don’t have a list of them, but the Pool idea comes into play, where Factory is renamed pool and contains both the normal factory and the archive. Then, when multiplayer supports hit, it’ll contain all that stuff also. Then, I can think about having a single ‘ID space’ for subfactories, where the Pool just has a single list, and the members have flags to indicate where they should be shown. Would make some stuff easier. Prime issue is how to keep track of GUI ordering, since the above linked list won’t work for a central list. Could split GUI order out like I do for selected_X etc, but there’s details to be worked out.
For the few above ideas, it might make sense to have a parent class like CollectionMember that contains fields like next, previous (if I need that), parent, maybe others.
View state data (selected_floor etc) should probably be moved outside of the main subfactory objects and into a separate data structure. This is both the cleaner factoring, makes it easier to set and reset this data, and will be important for multiplayer subfactories in the future. Make sure to move the state reset code out of init.lua
. Also, it should have a way to set more detail (like a specific line/machine/item/whatever) on it, so those parameters don’t need to be passed on for every GUI action (like opening the machine dialog, or similar). Maybe the additional detail is reset when the event is done, or it is just left to be overwritten by the next one. Also, maybe this rewrite can incorporate the addition of forward/back functionality. I‘ll need to research how that is normally done, but if every view is uniquely identifiable by a specific context table, then that table could just be stored and then re-stored on demand. Also, could have individually unfoldable subfloors with this system (activated by right-click on recipe).
Could rename Factory to Pool for the forthcoming pool idea, but that could also wait until that later point, since the rename would be pretty straightforward.
Make sure to drop Items having Product/Byproduct/Ingredient as their class, makes things complicated for no reason.