A standard set of mods for modpacks? Or is that dumb?

[Kirameki]

The point of a core is just to have a standard library as opposed to one for each individual mod/rewriting the library for each one, right?

I've actually toyed with the idea of learning to code, merely so I could recode all the major mods into one giant modular collection. Take the pieces you want, leave those you don't. One library, one core. Only problem is the immense maintenance. I feel like you might as well be maintaining your own game.

That it is, yes. But if you only intend to write one mod, there's no real reason to create a separate library, so far as I'm aware. It could be potential future planning ("I may make another mod.."), but for only one mod it isn't really necessary. If any modder wants to correct me on this please do, as we'd be curious to the reasoning behind it.

On a side note, makes me wonder how many peoples' coremods duplicate features/functions already in other [core]mods. Maybe you could modify your idea and make a centralized coremod wiki or something like that so people don't have to reinvent the wheel? (Or does this already exist, I dunno', just throwing ideas around.)

 

[Celestialphoenix]

I'd say its a pretty dumb idea;

you're attempting to enforce a standardised set of mod content- essentially demanding everyone be/like the same; which in turn will make individual modpacks less individual and unique.

Likewise consider the cultural effect; ideas such as this only gain momentum due to the mods in question being liked by the supporting crowd (or in this case people supporting this to stronghold their own opinions of Xmod).
If you were to try to apply these same mechanics to a less well liked mod then I can guarantee a significantly more hostile response from the FTB community.
Similarly people who may not enjoy using Ymod will feel the same way about you trying to force it on them.

[For my own tastes- I'm pretty fed up with turning off every HUD mod in existence every time I play a pack or update]
​

What you could possibly do is expand the master config; so theres a standardised set of controls/keybindings/remaining non-infinite IDs ect...

Or better -- design a keybinding-control mod for the FTB client; so one's personal controls can automatically transferred to a new pack.​

 

[AliceTheVixen]

I'd say its a pretty dumb idea;

you're attempting to enforce a standardised set of mod content- essentially demanding everyone be/like the same; which in turn will make individual modpacks less individual and unique.

Likewise consider the cultural effect; ideas such as this only gain momentum due to the mods in question being liked by the supporting crowd (or in this case people supporting this to stronghold their own opinions of Xmod).
If you were to try to apply these same mechanics to a less well liked mod then I can guarantee a significantly more hostile response from the FTB community.
Similarly people who may not enjoy using Ymod will feel the same way about you trying to force it on them.

[For my own tastes- I'm pretty fed up with turning off every HUD mod in existence every time I play a pack or update]
​

What you could possibly do is expand the master config; so theres a standardised set of controls/keybindings/remaining non-infinite IDs ect...

Or better -- design a keybinding-control mod for the FTB client; so one's personal controls can automatically transferred to a new pack.​

I like those ideas, and I see where you're coming from. I don't doubt that I'd be walking a fine line, but what I would like to institute isn't a mod standard, but more of a code standard.

If done properly, I feel like having every working piece in a mechanism constructed and modified under one standard would function better. Better in respect to each piece made to an undetermined standard in which each piece needs to be adjusted until it functions, and not always optimally.

Now, if it were possible for one person to maintain said conglomerate, the next issue as mentioned is creativity. Will I simply rewrite everything someone else has ready made? Will I just plagiarize other ideas in the attempt at a grand idea, or will I attempt to venture off in my own direction, possibly failing to meet the excitement and diversity everyone endears?

Either way, the main idea isn't a super mod that forces someone to use Xmod. No, it would start as a core. Each and every mod would develop around that core, until only maintenance would be required. Now, instead of downloading 5 cores for 15 mods, say you wanted to play a magic map?
Aright, just download:
--Core, magicA, magicB, and magicC
as opposed to
-- CoreA, magicA and magicB, core B, magicC, D, E, etc.

If you want to at magic-tech, same thing. This isn't an idea to make a mod that forces people to play a certain way. Rather, it's an idea to make a mod that is so modular that could be played hundreds of ways.

Of course, the ethicality of this would have to be called into a question. If this is a success, what of the other modders? Will this mod became so useful that there is no need for other mods? I would hate to push another modder out of the community via the success of a silly bit of OCD. I think the intent is noble, but when ends meet, it seems to big, too bulky, and too unethical.

 

[Hambeau]

Problem: What happens when one of your "core mods" is no longer available? Last week the developer and/or maintainer of Ars Magica announced that he's leaving the modding community. As a result Direwolf20 has reportedly removed the mod from the upcoming DW20 1.7.10 pack. It might be added back if control of the mod is passed to someone else to maintain, but who knows?

 

[AliceTheVixen]

Problem: What happens when one of your "core mods" is no longer available? Last week the developer and/or maintainer of Ars Magica announced that he's leaving the modding community. As a result Direwolf20 has reportedly removed the mod from the upcoming DW20 1.7.10 pack. It might be added back if control of the mod is passed to someone else to maintain, but who knows?

This isn't actually something I'm going to do, I don't have the knowledge to do it. It's all just speculation as to what it could be. What do you mean by what happens when a core mod becomes unavailable? You mean if for instance IC2 stops updating?

As before said, the main goal would be to maintain the mod, I wouldn't be adding any new content. It is just an attempt to make a faster, more compatible version of already great mods.

 

[buggirlexpres]

Look at Running Red, that managed to gain massive popularity, and that was based around Blood Magic.

I dunno about massive. More of a "cult following."

It's a good idea but some people will never need stuff like:
COFH core, DragonAPI, WaslieCore, etc.

m8, I need Waslie for my BloodUtils

This isn't actually something I'm going to do, I don't have the knowledge to do it. It's all just speculation as to what it could be. What do you mean by what happens when a core mod becomes unavailable? You mean if for instance IC2 stops updating?

As before said, the main goal would be to maintain the mod, I wouldn't be adding any new content. It is just an attempt to make a faster, more compatible version of already great mods.

Yes, what if IC2 stops updating? What if Thermal Expansion stops updating? CoFHlib, as a primary one. All of RF would stop being Universal. We shouldn't rely on Core mods. We should try to be different. And what happens if you want to do something that the Core mods don't allow? There's no room for innovation. We can't focus all around one thing. We need to change.


inb4 RF debate

 

[AliceTheVixen]

I dunno about massive. More of a "cult following."

m8, I need Waslie for my BloodUtils

Yes, what if IC2 stops updating? What if Thermal Expansion stops updating? CoFHlib, as a primary one. All of RF would stop being Universal. We shouldn't rely on Core mods. We should try to be different. And what happens if you want to do something that the Core mods don't allow? There's no room for innovation. We can't focus all around one thing. We need to change.


inb4 RF debate

Maybe I don't know enough about code to even really say anything. All speculation. As I said before, at least I think, it would be approached from the respect that every mod included would be rewritten, so there would be no reliance on other mods. I don't see why I'd need to rely on IC2 to update if it was rewritten and maintained by someone else.

 

[Azzanine]

Also, a suggestion for a "standard" mod, should be WAILA, especially if you use a lesser used mod... Some people won't mine something they see no use in, and if they don't know it, it is useless

But if you want to be different make a pack based around a mod not many people use. Look at Running Red, that managed to gain massive popularity, and that was based around Blood Magic. Agrarian Skies (early game) is based around Ex Nihilo. Crash Landing, enviromine and hunger overhaul (sorta). ME^3 AE spatial storage.
I'm not saying you want your pack to be "launcher material" but it seems that if you orient a pack around a new/lesser known mod not only do you have a popular pack on your hands, but also you have a happy mod author, as many people start to use and abuse the mod.

Abusing a mod makes the author happy, as it allows them to fix things that shouldn't be doable.

*old man voice* Baaack in my day! we used to mine it anyway, read what it was then memorize the texture. This was before ore unification was a thing too so we had to memorize 3 different coppers and tin and 2 silvers. And that's hows we likest it!

 

[Celestialphoenix]

We have a conglomerate of mod api's and core files- its called forge.

As a result its a hulking monstrosity in order to cover as much functionality as possible; which results in a lot of extra/unneeded functionality for the individual modder. Not every forge mod uses every hook and function forge.api provides (collectively they probably do).
​

The advantage of individual mod core files is they provide only the functionality that the author needs; less overall complexity=less work, less to go wrong, ect

-as well as giving the mod author more independence (not waiting for updates, or having to update for the latest function/bugfix)
-different modders structure their code differently, so by forcing a standard practice you're inadvertently stifling other modders.​

​

 

[AliceTheVixen]

We have a conglomerate of mod api's and core files- its called forge.

As a result its a hulking monstrosity in order to cover as much functionality as possible; which results in a lot of extra/unneeded functionality for the individual modder. Not every forge mod uses every hook and function forge.api provides (collectively they probably do).
​

The advantage of individual mod core files is they provide only the functionality that the author needs; less overall complexity=less work, less to go wrong, ect

-as well as giving the mod author more independence (not waiting for updates, or having to update for the latest function/bugfix)
-different modders structure their code differently, so by forcing a standard practice you're inadvertently stifling other modders.​

​

See, I'd didn't realize this is what forge was. I assumed Forge merely facilitated the bridge between Minecraft and mods. This makes quite a bit of sense.

That being said, being a conglomerate has some glaring flaws, but still seems noble. In the end though, individuality will win out.

 

[Kirameki]

We have a conglomerate of mod api's and core files- its called forge.

As a result its a hulking monstrosity in order to cover as much functionality as possible; which results in a lot of extra/unneeded functionality for the individual modder. Not every forge mod uses every hook and function forge.api provides (collectively they probably do).
​

The advantage of individual mod core files is they provide only the functionality that the author needs; less overall complexity=less work, less to go wrong, ect

-as well as giving the mod author more independence (not waiting for updates, or having to update for the latest function/bugfix)
-different modders structure their code differently, so by forcing a standard practice you're inadvertently stifling other modders.​

​

Oh...*facepalm* "Forge API"...go figure I completely miss the obvious. Thanks for posting this. (...and people wonder why I stick to breaking things (QA) rather than programming. )

 

[namiasdf]

Hmmm. In general: (For techpacks)

Tool mod. TiCo is the bread and butter for this, but lots of other mods have their own toolset/progression.

Ore processing. Modded Minecraft and ore doubling/tripling/retarding go hand in hand.

Item/Liquid/Energy transport. Modded Minecraft and automation go hand in hand.

 

[100greenmen]

When making this thread I thought "alright variety is what makes different modpacks good/cool, but is a standard set of mods for every modpack something the community wants?" So far the answer is no and I am delighted by that. Thanks everyone for sharing your opinion.

 

[Deleted member 147725]

I think as long as you have stuff like NEI WAILA optifine ( why do people never put this in recent mod Packs?) a minimap armour status and status effect you good!


Sent from my iPad using Tapatalk

 

[Kirameki]

I think as long as you have stuff like NEI WAILA optifine ( why do people never put this in recent mod Packs?) a minimap armour status and status effect you good!


Sent from my iPad using Tapatalk

Because optifine causes more problems than solutions for many people. Minimap/status indicators are also a personal choice; the status indicators can cause burn-in on some monitors or overlap other HUD elements, and sometimes minimaps can be considered somewhat cheaty (especially if they have radar.)

 

[Celestialphoenix]

I wasn't aware Optifine gave distribution rights- also it doesn't work all the time [depending Optifine version, MC version, Mods installed]

NEI- or equivalent is probably needed; just for at a glance recipes.
Craftguide is pretty decent- does all the NEI stuff without the cheatmode options like item spawning, f7 light overlay ect...

The rest of the list is metagaming at best- out and out cheating the rest of the time.
I find stuff on the HUD very obnoxious in general.
Also WALIA constantly flickers and changes when you move about- gets very annoying very quickly.

 

[Wolfie_Waffle]

This may be an unpopular opinion, but I do not like WAILA. For me, I just takes up half the screen, and I usually always know what I'm looking at anyways . Maybe if it was more minimal I would like it more, but I still prefer not using it.

 

[Wolfie_Waffle]

Oh, I know, most cores will never be used, they can always be renamed to .disabled. It was more us discussing how some modders have only one mod yet feel the need to make a separate coremod/library for it, so I kept having to look for all these one-off dependencies. Drove me a bit batty, would have been convenient to just have them all in one place.

That annoys me as well, coremods are for if you have multiple mods and have some common code between them, like Thermal expansion/foundation/dynamics and Tinkerer's construct/mechworks. If you only have one mod, why do you need a coremod for it?