Open HyperCodec opened 1 year ago
How about you use an inner class instead of a shitty complicated modules system, like I suggested months and months ago, each "module" defines itself in the configuration what it wants to act as and load itself as (e.g. command, module, items list, etc..), and based on that the loader will look for an inner class inheriting that certain type and create an instance of itself, this would consolidate the modules and items and commands and whatelse into one directory
How about you use an inner class instead of a shitty complicated modules system, like I suggested months and months ago, each "module" defines itself in the configuration what it wants to act as and load itself as (e.g. command, module, items list, etc..), and based on that the loader will look for an inner class inheriting that certain type and create an instance of itself, this would consolidate the modules and items and commands and whatelse into one directory
but then modules cant contain multiple (command, item, etc) in one
The current one is alright, but it has flaws that make it difficult to work with when developing modules:
Many problems arise from requiring a separate items directory, which is very annoying when modules are single-file and would require different types of modules (unless we get multi-file modules working) to define items; Ideally, we'd want it to be possible to register items from modules during module initialization (and maybe even onEnable/onDisable stuff if creative tabs are editable midgame) or, in the event of multi-file module compatibility, simply define item classes in the module's directory to be autoinitialized alongside the module.
Another little change I'd like to make is that it should simply accept nbt objs directly in the base GenericItem rather than only string bc it provides a somewhat useful abstraction.
These changes create opportunities for module devs to write much more powerful modules.
(Yes I'm in the scholarly asshole writing style bc I have school to deal with now)