It appears that this mod is used to do 2 unrelated things. One is to act as a library for creating basic boilerplate code for other mods, and one that adds all sorts of interesting new items and gameplay. It does both things well, however when other mods use it, you are forced to take all of these new items and gameplay changes with you. The author has created another wonderful mod (Always Greener) that transforms existing biomes to look much more natural and beautiful. It depends on this mod. However now if I want to use Always Greener, I'm forced to take these other items and gameplay changes. As a player I'd prefer to have the choice of whether or not I want them (sometimes for performance reasons). As a mod developer, I'd be leery of creating mods based on this library, because again, I probably want more control, and want to add my stuff while taking advantage of the code the library gives me, without always being forced to include these new unrelated items. For this library to be widely adopted by other modders, it needs to be split into a mod boilerplate library mod, and the new items & gameplay mod. Yes there are settings to disable the new items, but it creates unnecessary bloat. And it defaults to having both turned on, something that as a modder I might not want to have the player to mess with settings to get this extra stuff removed.
I did consider making two (or more) separate library mods early in the development of Etc, but I kept on arriving at the conclusion that all my mods would just end up depending on both, basically defeating the purpose of splitting them since the library also provides crafting resources and mechnics such as the mortar and pestle, anvil, and so on.
My other issue was that I would basically be spamming CDB with libraries that only I would ever actually use, since most of the features are specific to my other projects at the end of the day.
I've tried my best to make the content additions as optional as possible, and ensure they don't get in the way of anything in the base game. (Of course, they can also be disabled individually or as a whole with library mode anyway).
An idea I've been considering was to make all the content modules 'lazy-loaded' by default, so they wouldn't actually be enabled unless another mod requested them, but that would leave players who came for the other half of the mod in the dark. I could add options to force enable them, but I think it's better from a design perspective to have them all enabled by default and allow players to disable what they don't want, than to require manually enabling everything they do want.
I think you'd be surprised, I thought that people might never use some of the library mods I created, and people wound up using them for things I never imagined to use them for. Think of it this way, layered architecture is everywhere in my day job. That means we have backend libraries that do the logic, and front end modules that do the UI stuff (that's visible to the user). Splitting 1 mod into 2 won't be considered as spamming CDB at all if it makes better sense from an architectural perspective. While chalk and mortar and pestle and all the other new in game items are great, they are not needed by even the first UI based mod you created (Always Greener). Always Greener provides beautiful new models for plants & leaves etc. It has no need for any of the new items. If every other mod you create does need them then I would have a Base Library mod that is a dependency for the new items/gameplay mod that is a dependency for the new mods. Base Library > Items Mod> Mods that need items. Minetest is a bit different from Minecraft in that Minecraft you pretty much get a complete game that you're just tacking a few customizations onto. Minetest Game is more like a lego set which is composed of a blank slate plus lots of tiny modules that the player combines in ways that the developer never imagined. Most of the mods are very simple and just do 1 thing, but they do it really well (think Weilded Light mod, or my Node Touch Action library). Mods that are a conglomeration of a bunch of unrelated things just aren't as useful.
It appears that this mod is used to do 2 unrelated things. One is to act as a library for creating basic boilerplate code for other mods, and one that adds all sorts of interesting new items and gameplay. It does both things well, however when other mods use it, you are forced to take all of these new items and gameplay changes with you. The author has created another wonderful mod (Always Greener) that transforms existing biomes to look much more natural and beautiful. It depends on this mod. However now if I want to use Always Greener, I'm forced to take these other items and gameplay changes. As a player I'd prefer to have the choice of whether or not I want them (sometimes for performance reasons). As a mod developer, I'd be leery of creating mods based on this library, because again, I probably want more control, and want to add my stuff while taking advantage of the code the library gives me, without always being forced to include these new unrelated items. For this library to be widely adopted by other modders, it needs to be split into a mod boilerplate library mod, and the new items & gameplay mod. Yes there are settings to disable the new items, but it creates unnecessary bloat. And it defaults to having both turned on, something that as a modder I might not want to have the player to mess with settings to get this extra stuff removed.
converted review into a thread
I did consider making two (or more) separate library mods early in the development of Etc, but I kept on arriving at the conclusion that all my mods would just end up depending on both, basically defeating the purpose of splitting them since the library also provides crafting resources and mechnics such as the mortar and pestle, anvil, and so on.
My other issue was that I would basically be spamming CDB with libraries that only I would ever actually use, since most of the features are specific to my other projects at the end of the day.
I've tried my best to make the content additions as optional as possible, and ensure they don't get in the way of anything in the base game. (Of course, they can also be disabled individually or as a whole with library mode anyway).
An idea I've been considering was to make all the content modules 'lazy-loaded' by default, so they wouldn't actually be enabled unless another mod requested them, but that would leave players who came for the other half of the mod in the dark. I could add options to force enable them, but I think it's better from a design perspective to have them all enabled by default and allow players to disable what they don't want, than to require manually enabling everything they do want.
I think you'd be surprised, I thought that people might never use some of the library mods I created, and people wound up using them for things I never imagined to use them for. Think of it this way, layered architecture is everywhere in my day job. That means we have backend libraries that do the logic, and front end modules that do the UI stuff (that's visible to the user). Splitting 1 mod into 2 won't be considered as spamming CDB at all if it makes better sense from an architectural perspective. While chalk and mortar and pestle and all the other new in game items are great, they are not needed by even the first UI based mod you created (Always Greener). Always Greener provides beautiful new models for plants & leaves etc. It has no need for any of the new items. If every other mod you create does need them then I would have a Base Library mod that is a dependency for the new items/gameplay mod that is a dependency for the new mods. Base Library > Items Mod> Mods that need items. Minetest is a bit different from Minecraft in that Minecraft you pretty much get a complete game that you're just tacking a few customizations onto. Minetest Game is more like a lego set which is composed of a blank slate plus lots of tiny modules that the player combines in ways that the developer never imagined. Most of the mods are very simple and just do 1 thing, but they do it really well (think Weilded Light mod, or my Node Touch Action library). Mods that are a conglomeration of a bunch of unrelated things just aren't as useful.