MBINCompiler
MBINCompiler copied to clipboard
monkeyman192
Organising structs a bit better
At the moment we have the problem that there are over 1000 structs. Because of this github truncates the list online which is very annoying if you are searching for something online. It would be good to come up with some categories to split the files into. I did an initial mess around with splitting them up and had the following folders as categories: Creature, Generic (for vectors/strings etc), Globals, Missions, Rewards, and UI. This left about 770 structs still un-categorised. It doesn't make sense to put every single file in a category I think, but even splitting mission structs into their own folder takes about 140 files out of the main list!)
There should be a folder for BaseTypes: It will contain just the primitive types and generic types that are specific to NMS, like Colour, EmptyNode, Vector* and NMSString*
All the Tk* files should be organized within a Toolkit folder. All the Gc* files should be arranged in a GameComponent folder.
For the Toolkit and GameComponent folders, they should be split into Internal and External classes.
We should start there.
what do you mean by 'internal' and 'external' classes? Ones that are and aren't used by mbins?
By internal/external I meant an internal struct is never in it's own MBIN. I dunno how useful of a categorization that is anyway. nm the internal/external I guess ^_^ I'm sure we could use more practical categories but we should split it into to those 3 folders I mentioned to start with then we can evaluate what's left.
The namespacing should also be changed:
- libMBIN.NMS.BaseTypes
- libMBIN.NMS.Globals
- libMBIN.NMS.GameComponents
- libMBIN.NMS.Toolkit
reorganized in 6fffdd6be22ac7e9ee7e136ee57ff0e066402e23 GameComponents and Toolkit should be further reorganized.
So I'm going to re-open this issue because as of 2.0.X we now have >1000 structs in the Game components folder so maybe it is time to discuss another re-organisation...? @Fuzzy-Logik thoughts??
I think the next level of reorganization will need to be like you said. Identify and group related structs based on context, such as missions, rewards, UI, etc ...
If you go ahead and do this, keep in mind that you should move files using git, not explorer or cmd or Visual Studio, so that the proper history is preserved. The files should NOT be deleted and re-added in git. The re-added files will appear as being new and will be disconnected from the deleted files at the old location. If the files are moved using git then the association between the files will be maintained.
I use source tree which is pretty smart about it I think, so even if move them in explorer they come up as a rename as we want for preserving history. I'll definitely make sure to keep it in mind when I look into it though