Ahem, you mean back when TE was an addon to Buildcraft? Or that 1.5 version where it cut the umbilical cord?
1.8: what is holding you back?
- Thread starter ShneekeyTheLost
- Start date
-
The FTB Forum is now read-only, and is here as an archive. To participate in our community discussions, please join our Discord! https://ftb.team/discord
This obsession with modularizing mods into core and multiple components is damaging load performance for no purpose other than to inflate developer egos. No one cares about your core mod. Just build it in and stop making us chase after why the hell do I need 'mythical-beast-core.jar' in my mod list. And why does it always add half a dozen secret world gen altering features entirely unrelated to the mod that needs it.
In some cases, it's because people don't always want all the components. Some people don't want BC Robotics, but want the rest of it. So they simply don't install it into their pack because it doesn't fit. Others, because it's easier to write a core mod that works with several mods of yours at once. Ala DragonAPI. And in that case, it's easier to tweak one core mod, than go and update something in all the child mods to ensure they're all using the same piece of code.
Not all of those so-called library or core mods are really core mods. For example McJtyLib is not a core mod. It is in fact not even a mod. Just a collection of java tools that I find useful in most of my mods. So it helps with sharing code between multiple of my mods.
So, do an experiment and realistically tell me how much the mods would be bloated if you just compiled the same core library into each one?
Well depends on how many mods use mcjtylib. In 1.7.10 that's only two (rftools and deep resonance). But on 1.8.9 it is three (rftools dimensions) and on 1.9 it will be at least four (XNet).
Also it means that if there is a bug there I only have to fix it once and not in four different mods.
McJty, you do realize that you can have your single library internally, and just have the build process lump it together with any mods using it, yes?
It's a little bit of setup to prevent issues with multiple conflicting copies, but not much, and you really only need to do that once.
When I dabbled with modding that's what I always did.
It's a little bit of setup to prevent issues with multiple conflicting copies, but not much, and you really only need to do that once.
When I dabbled with modding that's what I always did.
Well McJtyLib is also usable for other people. Nobody has done that yet as far as I know but there has been some interest already.
This is a debate, basically, over static linking vs dynamic linking. The problem with static linking is that, when you change the static library, you need to push updates to everything that depends on it. While for someone like McJty, who only has a handful of mods, this isn't a huge problem, for someone like Reika, who has a larger library to their name, that means extra time spent compiling, testing, and all that good stuff.
Dynamic linking, in Windows parlance DLLs, allows you to update and utilize common code from a single, centralized area that is independent of the main operating code. This is a huge advantage, because it allows you to change what goes on "behind the scenes" without necessarily having to update anything that depends on the library.
You are, of course, also failing to take into account content between libraries and actual mods. Using Reika as an example again, there's about an order of magnitude (I think, I haven't checked) difference in JAR size between DragonAPI and ChromatiCraft. Libraries, typically, don't house any assets outside common code. This means that the time they add to loading should, if Forge was made by someone with a brain, be utterly negligible unless we're talking about a titanic library that goes into the tens of megabytes, which almost never happens. Smart assets are almost always compact, even in Java. Its the dumb assets: the textures, models, sounds, etc in a mod that add the loading time.
BuildCraft has been modular since its very first days. I do acknowledge that the current module split has not aged well, however I disagree that modularization is bad, it'd just be better if I ported Charset's JAR-o-matic to BuildCraft... which it was originally planned for. Hmm.
I'm a huge fan of modularization of mods, personally. Overall, it either doesn't impact how much has to be loaded (if a dependency is only used by one mod), or significantly (if it is being used by many mods). Furthermore, this gives the chance for things like CoFH Crew to release the Core mods like CoFH Core and CoFH Lib first, then start working on their other mods, which can then be used by other mod devs to do THEIR mods with using that CoFH coremod list.
It also allows me to pick and choose. For example, say I wanted Railcraft's rails, but none of the machine or boilers or any of that stuff. I can do that. It also allows me, for example, to only pick up a couple of BC modules that LP is dependent upon instead of having to pick up the whole suite, since I never plan on using any of it anyway (although TBH I still wish that LP could have an alternate dependency on Thermal Dynamics and just runs with ducts, but that would be a lot of effort for a marginal user-base, so I understand why it is not feasible).
It does seem like Storage Network is going to be replacing LP and possibly even AE for 1.8. Short, sweet, to the point, functional. Does what you want it to do. About the only thing it really can't handle (yet) is auto-crafting on demand.
It also allows me to pick and choose. For example, say I wanted Railcraft's rails, but none of the machine or boilers or any of that stuff. I can do that. It also allows me, for example, to only pick up a couple of BC modules that LP is dependent upon instead of having to pick up the whole suite, since I never plan on using any of it anyway (although TBH I still wish that LP could have an alternate dependency on Thermal Dynamics and just runs with ducts, but that would be a lot of effort for a marginal user-base, so I understand why it is not feasible).
It does seem like Storage Network is going to be replacing LP and possibly even AE for 1.8. Short, sweet, to the point, functional. Does what you want it to do. About the only thing it really can't handle (yet) is auto-crafting on demand.
Last edited:
modularization is a good thing, one thing however that I would like is a way to easily get all the dependencies/modules of a mod so I don't have to hunt them down. That is the only problem I have with it currently, the lack of one click download links to get everything needed for a mod.
yea if you like to not have all the mods you want and some you don't like at all then go ahead, I rather just throw mods together myself (and hope nothing breaksIt's called a mod pack
)
Most packs tend to be fairly customizable. If nothing else, you can use the pack as the basis for what you want to do, remove what you don't want, add what you do want.yea if you like to not have all the mods you want and some you don't like at all then go ahead, I rather just throw mods together myself (and hope nothing breaks
I know, but if I do that being able to download all the dependencies of a mod + the mod I want at the same time would be nice
That being said, I get why mod-devs don't put downloads like this on the web, its more work for them and people will fail to unzip it first before throwing the mods in the mod folder and then cry
If only there was something like apt-get for mods
Reminds me of how RF replaced IC2 power - and as we all know, there's now no gameplay in power distribution beyond "connect A to B".
the other annoying problem, when mods DO start using common "dynamic" libraries, is that Mod_A will be updated and depend on Mod_Library v1.2, but Mod_B's author will be doing exams or something, and require Mod_Library v1.1
I just downloaded a mod for my kid that required 3 other library mods. All code, all tiny, statically linking that content would make this download a lot more convenient now, and a lot less prone to versioning conflicts later.
As it turns out, the @#$* core libraries have been updated since the mod was built. Of course, no one has documented which versions the mod was built against (and which version of Forge those were built against) so unresolvable errors. I guess I don't get to try Mowzies Mobs then.
Yay for mod dependencies.
Yay for mod dependencies.
Again, easily solvable if we had something like apt-get but then for mods.
It doesn't need to be that complex as apt-get though.