A trend of mod development

[ShneekeyTheLost]

There's a trend I have noticed while coding up ShneekeyCraft 1.3.0.A concerning development of mods for Minecraft in 1.7.10 versus 1.6.4. There's a TON more dependency or 'core' mods now.

In 1.6.4, for example, there was CoFH Core and CodeChickenCore. Oh, and Forge itself. There was also Forge Multipart, if you want to count that.

Now you've got CCCore, CCLibs, CoFHCore, CoFHLibs, and Thermal Foundation all as dependency mods for Thermal Expansion. Tinker's Construct now requires Mantle. Botania requires Bauble. Seems like every other mod has at least one, if not more, coremods that exist exclusively to provide support for the one mod itself. It's to the point where a pack can have more Core mods than there are actual mods they are supporting!

I'm not angry or upset, I'm just... puzzled. Is this so that addon mods have an easier time by using your coremods as dependencies to reduce hassle of API's? Is it because of the new Gradle stuff?

I get that some of these used to be 'built-in' and have since 'spun off', so to speak, but I'm just wondering why that decision was made.

 

[KaosRitual]

I think a lot of it might be mods adding in support for other mods to build off of, like Thaumcraft making Baubles.

 

[the_j485]

Also I imagine mod authors who only have one mod yet have a core mod might have such motives as that they to make more mods.

 

[chbachman]

Core mods not only allow mod authors who want to make more mods have less coding, they also are a batter style of coding. Making a util library is just better programming style than shoving it all into one mod. Also, things like cofh core and lib are different. Lib is useful for everybody, and so basically a util library.

 

[King Lemming]

There's a trend I have noticed while coding up ShneekeyCraft 1.3.0.A concerning development of mods for Minecraft in 1.7.10 versus 1.6.4. There's a TON more dependency or 'core' mods now.

In 1.6.4, for example, there was CoFH Core and CodeChickenCore. Oh, and Forge itself. There was also Forge Multipart, if you want to count that.

Now you've got CCCore, CCLibs, CoFHCore, CoFHLibs, and Thermal Foundation all as dependency mods for Thermal Expansion. Tinker's Construct now requires Mantle. Botania requires Bauble. Seems like every other mod has at least one, if not more, coremods that exist exclusively to provide support for the one mod itself. It's to the point where a pack can have more Core mods than there are actual mods they are supporting!

I'm not angry or upset, I'm just... puzzled. Is this so that addon mods have an easier time by using your coremods as dependencies to reduce hassle of API's? Is it because of the new Gradle stuff?

I get that some of these used to be 'built-in' and have since 'spun off', so to speak, but I'm just wondering why that decision was made.

Well, first of all, we now ship CoFHLib as part of CoFHCore - in theory this will always be fine, as we're going to update the two at the same time. Also, ChickenBones has given us permission to repack the parts of CCLib that we are using - CCLib is not a dependency anymore - but realistically you really should be using NEI.

But in general, here's why.

CoFHLib is full of stuff we don't mind people reusing and depending on explicitly. It's safe and no mod is added. CoFHCore contains a lot of stuff where if people depend on it directly and screw up, then they're going to mess up our mods too. And we don't want that.

Thermal Foundation is basically a LOT of resources and materials, and pack makers can use it to add things to the world without requiring that Thermal Expansion be installed. Also, it gives us flexibility to create a new mod using the same concepts/materials as TE without making it a TE addon simply because it needs copper or tin.

And, in general, it's *far* easier to manage smaller mods. Thermal Foundation for example, I doubt is going to have many bugs at all, if ever.

 

[ShneekeyTheLost]

Well, first of all, we now ship CoFHLib as part of CoFHCore - in theory this will always be fine, as we're going to update the two at the same time. Also, ChickenBones has given us permission to repack the parts of CCLib that we are using - CCLib is not a dependency anymore - but realistically you really should be using NEI.

But in general, here's why.

CoFHLib is full of stuff we don't mind people reusing and depending on explicitly. It's safe and no mod is added. CoFHCore contains a lot of stuff where if people depend on it directly and screw up, then they're going to mess up our mods too. And we don't want that.

Thermal Foundation is basically a LOT of resources and materials, and pack makers can use it to add things to the world without requiring that Thermal Expansion be installed. Also, it gives us flexibility to create a new mod using the same concepts/materials as TE without making it a TE addon simply because it needs copper or tin.

And, in general, it's *far* easier to manage smaller mods. Thermal Foundation for example, I doubt is going to have many bugs at all, if ever.

Makes sense, I was just wondering why that decision was made. In brief, CoFHLib and Thermal Foundation got spun off from CoFHCore to prevent issues with people trying to use them as dependencies to make it easier for addons. Works for me.

It's a little bit more hassle on my part as a conscientious mod pack maker because I credit every single mod, but that's only a one-time thing so it's not a real issue. I was just wondering why the dependencies exploded from one to five.

Also, I prefer CraftGuide to NEI. If CraftGuide could include a Shift + ? functionality to auto-populate crafting grids, I'd honestly never use NEI in favor of CraftGuide. It's just a lot leaner and efficient at what it does, without bogging you down with unnecessary features.

 

[Pokefenn]

Well, it depends on mod to mod.
The CoFH guys use it because they want to separate it into separate parts for certain tasks.
CoFHLib holds the general library code that is used by everyone for RF and the such, it should be a general library so it is.
CoFHCore has certain tasks and is made specifically for CoFH mods, other mods can use it if they wish.
Thermal Foundation is if people want the ores and stuff without using Thermal Expansion, which was a request for quite a few people.
And finally there is CCL, which has special rendering vector code and other stuff, really great lib.

All in all for CoFH they do it for customization, you can have it work in a specific way

Baubles is just a nice tool for mods that want to add magical rings and stuff, it's great to not have repeating slots/content.
And lots of the mods follow this with dependencies, to stop overlapping features (and code, libraries can be a god send) and to also stop repeated content and stuff

 

[InfinityRaider]

I really like hte way the cofh guys did it imo,

 

[Golrith]

Really hoping that Thermal Foundation is the starting seeds to a unified ore system, so no longer are we plagued with 5 types of copper ore/ingots/dusts just because 5 mods need copper.
Here little seed, have some Bonemeal, grow strong so we can harvest your fruits.

 

[ICountFrom0]

If I could, I'd ping in people from buildcraft and railcraft, as those mods use a differnt and yet simmilar aproaches.

If you installed just the two of them, you'd have 5 child mods that are part and parcel with buildcraft, while railcraft has them all in one and you can configure them on or off as you like.

MFR has 23 dependent subparts, could quite possibly be a record, makes the small handful for TE look very small indeed.