I want to build a modpack, BUT… please hear me out!

[mololabo]

Beware, dragons and a wall of text ahead! 1500+ word epos ahead! Many questions to be answered!

Who is this dude?

Hello everyone, I am mololabo, or molo for short. Longtime lurker, player/watcher and hobby semi-not-really-critic of games and anime, working as a Java-dev, with broad interests of all kinds of science, books, a bit of martial arts and other stuff. Most people tell me I'm a really friendly dude, but I'm sure they're lying about that. Just judge for yourself.

Oh, and I am an absolute lover of KSP mods.

Oh god I installed another one, send help! *drowning noises*

-------------------------

Did this dude even read anything about how we handle things in this place?

For about a week I've been thinking about assembling a modpack. Now, I haven't only been thinking about it, I've also read up a bit about the possibilities of it in the scope of KSP and it's modding community. Read through diverse forum rules, read licenses and how I could handle them in a modpack. Looked at the requirements for developing mods and I wanted to get into C# either way. I also read a lot about the general mood/opinion of mod-devs and people, which is, to say the least, not positive.

Now from other threads where people mentioned the thought of assembling a modpack, it never really seemed very well thought-through to me. I hope to win your (and especially the mod devs) favour by actually having a concept and presenting it as a coherent whole before actually *working* on a mod-pack. Yes, working, I am planning to do more than just slap together some folders.

So, let's get to business and answer some central questions!

Disclaimer: I will mention all kinds of mods to make my point. Please take notice of the fact, that I will still ask you before using any of your assets. I haven't done anything substantial yet.

Most importantly: How will you handle crediting the devs who did most of the work and whose combined hours will be a multitude of those you will probably invest?

I've got nothing but the utmost respect for the multitude of awesome devs who developed those great mods for this game which I absolutely love.

Actually, I am planning to list every mod I'd include at the top of the modpack's topic. Together with their linked name, release thread and the used license. I will ask before including it and I sincerely hope that I will be able to gain everyone's approval.

I also want to throw 10-20 bucks into every devs donation bucket, whose mod I am planning to include. I don't mean to really "pay" you for allowing me to use it in the modpack, I will even do that before I ask you. I just want to pay my respect to great work.

What do you even want to do with this modpack? What is your concept?

I mainly want to extend upon the basegame, keeping the general feel, while adding manageable, additional systems and gameplay. More or less a managed form of "more of everything". I want to take some cues from reality like KSP. I am absolutely not interested in "hard realism". On one hand we already have Realism Overhaul for that and on the other it's just a bit too hardcore for me. I've enjoyed my time with Dark Souls and Eve Online, but that'd be too much.

I also don't want to use a calculator or have to look at extensive charts to build a decent craft/rocket/plane. Which is why I would prefer NEAR over FAR. And I think a lot of players could feel similar.

(And just to make sure, I highly value what you devs have accomplished with FAR and Realism Overhaul, it's just too much for me)

I'd also try to keep those game changing mods as modular as possible to allow for easy removal if a player wants to get rid of… reentry effects, more complicated atmospheric behaviour, life support, etc.

More power to the player.

What would be the advantage compared to just downloading every mod one by one? Why does it need to be a modpack?

This is going to be a list...

1. removal of duplicate and unnecessary parts

Did you ever download a multitude of part packs which have a lot of awesome parts, only to then swim in a huge sea of different tanks, most of them being relatively ugly?

Yeah, me too. I will remove unnecessary parts with art which didn't really seem like a priority. For example I am really not a fan of NovaPunch's white-red tanks. They don't really fit with the rest of the game.

The same I will do for engines, structural elements, etc.

2. taking care of mod conflicts

KSP modding API is awesome and module manager solved a lot of things. Still, sometimes there're conflicts. Which I aim to solve.

3. mod compatibility, reviving older and/or incompatible mods and making a "greater whole"

It's true that modding KSP is incredibly easy, but in the end, we're still just throwing together different mods.

Aside from what I wrote above in "What do you even want to do with this modpack?", I also want to merge some resources between the different mods. Like the water-splitter in TAC-Life support which produces oxygen and waste. Why not make it actually produce hydrogen and use that to also fire up a Near Future Propulsion engine which could make use of that! Wouldn't that be awesome?!

I also might consider reviving some old mods if the creators let me do that and try to integrate them within the modpack. I will also try to build new parts when it would fit a given niche/hole I want to fill. Add more biomes, rework a multi mod techtree, add better models to simpler sphere-tank modules, when they aren't tanks, etc…

EDIT: A modpack also allows the modpack-manager/dev to control which version of which mod he might use in the pack. While that also poses its own pitfalls (old mod versions) it's als an advantage since it allows the modpack-manager/dev to assemble the mod versions which will (hopefully) work together the best. It will also avoid the possible case of players being unable to download the version of a mod that would be required by the modpack. Be it because the given version isn't findable, because the website went down (Kerbal Spaceport?) or because only the newest download is still available.

4. rough balancing

I will probably work on some part's .cfg files to roughly balance them out with the rest. A lot of mods have some sense of balance with stock KSP, but mix a lot of them together and it becomes a mess very fast. I'm sure I won't be able to balance it out 100%, but I at least want to make it less severe and I can still try.

5. Making the installation easier for the user

I don't know how you feel about it, but I don't particularly enjoy hunting down 20 topics to download 23 zips and unzip them all by hand, taking care of what I do in which order since some are patches, etc.

Even if my modpack wouldn't be to everyones taste, it'd still be easier to install it, delete 1-3 folders, install another and call it a day, wouldn't it? (+ all the reasons mentioned above)

I'm also hoping for building an extensive github wiki to help players out with all the added mods and link to appropriate other wikis.

How will you handle licenses?

The modpack will be splitted into several zips which will be licensed with the appropriate license, in accordance with the licenses of the mods in the appropriate zips. So modpack part1 => CC-NC-SA, modpack part2 => GPLv3, modpack part 3 => … etc. you get the gist of it.

Of course I will do my very best, like no one ever was… at abiding by the licenses and everyone is invited to call me out if I .... that up!

The general idea: As few zips as possible, as many as needed.

Won't that be a bit much to handle?

Yes. But I will work with a friend (Volatar, he doesn't have an account on the forum yet), I will always be open to advice and help and I will start small and progressively add mods as I go along. I'm not insane enough to try and integrate 15+ mods at once.

Tech questions round 1: How will you build the modpack?

I will probably be using binaries when possible to reduce the general complexity. It will already be more than enough work as it is. I will compile by source if the license allows me to and if it's needed to solve a given problem. Knowledge, insight, ideas I gather from that will be shared from the devs, unless it seems to go against the idea and direction they're taking with their mod.

Tech question round 2: Why not take a path similar to the Realism Overhaul mod/thread?

1. see "What would be the advantage compared to just downloading every mod one by one? Why does it need to be a modpack?" question 5 "Making the installation easier for the user"

2. avoiding installation mistakes

It will happen either way, but having a user extract one zip into one folder is probably less error prone than letting him install 15+ zips whose root is sometimes "GameData" and sometimes "InsertModName" and sometimes "InsertProjectName\GameData\InsertModName".

3. Keeping the complexity manageable

I'm not completely sure about that, so you're free to give me tips / correct me.

I feel like editing the cfg files directly might make it easier to manage than write a bunch of module manager scripts. It'll become a big package over time and will probably be complex enough as it is.

But I'm really not sure about this part. Maybe Module Manager scripts really would be better? I feel like I am talking out of my arse right now. Hit me up!

So… what do you think? Is that acceptable? Would you all actually be okay with that concept? Is it still a horrible idea despite me trying to start with a systematic approach? Did I make a horrible mistake and accidentally start a thermonuclear war? ARE YOU NOT ENTERTAINED?! *raises sword*

Whatever your answer may be, shoot me a reply below this post, I'll read everything and try to answer to the best of my abilities. Even if you do not approve of my endeavour, thanks for reading, your opinion and peace <3

addendum:

So long as you don't run into licensing troubles, you should be fine. You seem to have a decent idea of the pitfalls of creating a mod pack for KSP otherwise.

How do you plan to handle support of the mods in your pack? Many mod authors will not be excited in the least by potential increased support requests stemming from your packaging.

Right, I totally forgot to answer that!

I'd write a clear statement on the modpack page that, for the scope of the modpack, I'd be responsible for the support of the pack and the included mods. If needed, asking the mod devs for help or should I find a bug/incompatibility , giving them a heads up about

Edited August 26, 2014 by mololabo

[Volatar]

Yes. But I will work with a friend (Volatar, he doesn't have an account on the forum yet)

I do now. This is an exciting project and I hope that the various amazing mod creators will work with us.

[regex]

Of course I will do my very best, like no one ever was… at abiding by the licenses and everyone is invited to call me out if I .... that up!

So long as you don't run into licensing troubles, you should be fine. You seem to have a decent idea of the pitfalls of creating a mod pack for KSP otherwise.

How do you plan to handle support of the mods in your pack? Many mod authors will not be excited in the least by potential increased support requests stemming from your packaging.

[Endersmens]

Hey hey hey, what's up guys?

First off, I would like to throw out that I am not a modder. I'm just a guy in the community. (however, I would LOVE to get into modding! I love coding and writing in computer language all that jazz, just haven't really learned it yet. (meaning I've written on minecraft computers, and on KSP computers, via kOS))

I think this is a very good idea. Especially if you give us the option of deleting a few mods we don't need or want, so it doesn't seem like you're forcing mods down our throats.

I would be happy to be a tester for your modpack, if you would consider that. (i.e. you give me the modpack before it's released to test the function, how easy it is to work with, test the balancing, and make sure it works and stuff)

Have you started on a list of mods you think would be candidates yet? I would be happy to help with that too, since I'm a modaholic. (I think my record was 36 mods. But that was before my hard drive crash. and no it wasn't related to how many mods i had. ) I read up on mods I don't have too, so i would say i'm familiar with 60+ mods.

As i said, i would be glad to help this in any way possible. (Also, I have a company in the rocket builders thread, and we could promote the modpack by making it our company modpack, if we like what we see. Totally at your descretion, though)

[mololabo]

So long as you don't run into licensing troubles, you should be fine. You seem to have a decent idea of the pitfalls of creating a mod pack for KSP otherwise.

How do you plan to handle support of the mods in your pack? Many mod authors will not be excited in the least by potential increased support requests stemming from your packaging.

Right, I totally forgot to answer that!

I'd write a clear statement on the modpack page that, for the scope of the modpack, I'd be responsible for the support of the pack and the included mods. If needed, asking the mod devs for help or should I find a bug/incompatibility , giving them a heads up about it.

Which leads me to another question I want to answer in the post above. Sit tight.

@Endersmens: That is still far off. I'll keep it in mind though.

EDIT:

Added regex' question to the first post, extended point 3 of the question "3. mod compatibility, reviving older and/or incompatible mods and making a "greater whole""

Edited August 26, 2014 by mololabo

[Endersmens]

What's far off? The testing? Yeah i knew that would be. Just thought I'd get my foot in the door, so to speak.

[ferram4]

If you're gonna be rearranging things to reduce the number of folders in GameData, I'm gonna tell you something you don't want to hear: you're going to have to modify every part.cfg and fork every plugin in order to make the necessary changes to the hard-coded directory structure they expect. There's no way around it without the game breaking.

But besides that, once you're in the realm of changing things to make them fit, you're not bundling someone else's mods. You're creating your own versions and distributing those. Baiscally, that means that now you are responsible for all the support requests that come out of this. If you change something in NEAR to "balance" things or to "maintain compatibility" and someone comes to me complaining about it, I'm going to have no clue what they're talking about, and I see no reason for me to support anything that someone else changed.

Think about it: someone still has installation issues? Your problem. Someone has uninstallation issues? Your problem. Someone has odd things happening with a part pack you modified? Now, it's your problem. Someone gets odd behavior out of a plugin you modified? Now, it's your problem. You will be stuck attempting to support a gigantic number of mods with codebases that you will likely not understand. And given that we won't know what you changed, nor do we want to deal with whatever you've changed, you won't be able to send users to us for support.

This is just going to result in everyone being more ticked off when things go wrong. I think you underestimate the issues and overestimate the benefit of doing this.

[Endersmens]

Ferram4, Theoretically, he could make a support team for the modpack, one for each Mod. They could familiarize themselves with the mod they are assigned to, and with the changes that were made. And then support users questions about that mod.

Just a friendly brainstorm suggestion.

I probably have no idea what i'm talking about, but oh well.

[mololabo]

I do not want to reduce the amount of folders in GameData, I realize that the paths are hardcoded.

I also realize that there are a multitude of mods with a mindnumbing complexity, with yours being some of the most impressive ones. I also know that some of those have a mindboggling complexity and I will probably stay far away from putting my hand into these insane machines. I rather wanted to tweak some parts to work better with them. Take a look at how you balanced and changed parts working with FAR/NEAR and tweaking parts from packs which aren't supported by FAR/NEAR.

And I realize that it will be my problem to deal with any support related questions. I would post a really big disclaimer that every support question with this modpack would be my responsibility. I know this will be my job and not yours or any other mod devs.

I thank you a lot for trying to make me realize how complex this will be and for your time reading this.

I still want to try putting it together though.

[Endersmens]

I don't mean to sound annoying, but is there anything I could do to help? Anything at all?

[mololabo]

@Endersmen

No, not right now.

I'm mostly waiting for more dev reactions and answer and afterwards I'll carefully think about if I even want to seriously work on this.

I do not plan to work on that against the general scorn/displeasedness of the very mod-devs whose work I love so much.

[ferram4]

Well, then in that case, it's up to you to ensure that your users are aware that they pester you about the problem, especially since you're actively considering bundling older (read: unsupported) versions of mods. No modder is going to be happy with you if they discover that their threads are getting clogged with already-fixed issues because you bundled that version rather than the one with the fix, nor are they going to be happy with you if they're asked to support something you implemented. It's up to you then to make sure that users only pester you about your stuff.

In general, I've never been a fan of people packaging my work (though the license allows it if they want to go ahead in spite of that), simply because there's no benefit for me in it. All I get is more support requests and have to deal with older versions out in the wild for longer.

You do realize that by creating a modpack, you'll be actively discouraging people from updating regularly for bugfixes, right? No one is going to download an entire pack again and again because one mod updated; they'll either download the independent version (which may conflict hard with whatever changes you've made for your pack) or they'll just not bother. In either case, users will enjoy playing less and it will be more work for all of us to support it.

[Volatar]

I would be happy to be a tester for your modpack, if you would consider that. (i.e. you give me the modpack before it's released to test the function, how easy it is to work with, test the balancing, and make sure it works and stuff)

Testers will be essential so that would be awesome.

Have you started on a list of mods you think would be candidates yet?

Yes, in a way. This whole idea started by Molo handing me a dropbox share of all the mods he was using plus one or two with modifications. That is where we are starting. As molo said, most of it is to extend existing stock gameplay with more to do and achieve. I have been really enjoying Station Science for example. It adds a lot to the base game. Real reasons to build things in orbit.

You do realize that by creating a modpack, you'll be actively discouraging people from updating regularly for bugfixes, right? No one is going to download an entire pack again and again because one mod updated; they'll either download the independent version (which may conflict hard with whatever changes you've made for your pack) or they'll just not bother. In either case, users will enjoy playing less and it will be more work for all of us to support it.

On the contrary. How do you think such a pack should be distributed? We plan on using source control to distribute the pack, meaning it will be constantly updated. A page out of the Garry's Mod book of modding if you will.

[mololabo]

I cannot talk for everybody, but I don't look for updates with a 10-15+ modlist each week for every mod in a given private game-environment.

And as I said I would do my best to make sure they pester me and not others about it.

Also, I did not simply say I'd bundle "older and unsupported" mods. What I meant to say was, that I'd consider picking up older / unsupported/abandonded mods and take care of them myself with the permission of the creator. I also mentioned diving into the source code for specific issues or making sure resource transfers work, but never did I want to dive into something as complex as FAR or NEAR. I don't want to just throw some folders together and "wing it", I'm taking a more active role with this and actually trying to fit something sensible together. I want to actively support and update the pack, not leave it there to rot after 3 days.

[Tiberion]

How do you think such a pack should be distributed?

It should not be distributed.

Just say no to modpacks. Don't redistribute other mods. No matter how attentive and active you plan to be, you'll get bored or something will happen and leave it hanging. At the very least you're causing MORE version fragmentation. Every time someone says "I can't update your mod until the modpack updates" a tiny kitten is murdered.

We have this wonderful tool called Module Manager. Make a list of mods you want to work together, create and distribute a set of configs to achieve that, andhave the users install the mods from their valid source. Then maintain those MM configs as currently as you can and you might not cause too much extra work for everyone. If you can show that you know how to do that for a while, you'll probably get more cooperation.

[NathanKell]

Putting aside for now questions of bundling things, I want to talk up the advantages of Module Manager.

As of MM 2.x, it's an extremely powerful tool. In particular, it will allow you to make changes based on what people have installed, so that (as you mentioned some flexibility in re: which mods users would have installed) you could tailor the experience to the install.

The wildcard system, combined with HAS, makes using MM actually easier than manually editing cfg files. It also makes updates painless, since you don't have to redo your changes and because (if you're using wildcards) new parts will be automatically supported by your existing changes.

Realism Overhaul would be *harder* to maintain if we bundled everything and edited cfgs; it would be a *lot* harder. It would also be far less flexible.

[mololabo]

I still have some arguments to make and I still believe that there're substantial benefits, but it is clear that I'm less than welcome here with that idea. And that's okay.

I thank you all who answered for taking the time to read this and engage with me and I hope you believe me when I say that I only had the best intentions and was completely serious with my proposal.

Especially thank you NathanKell for the heads up about ModuleManager and your experiences with it.

I will dabble in C# now and see what I can do with the ModuleManager.

You will hear from me when I've actually produced something useful, and I hope I'm not unwelcome when I come out of the woodworks with something that is not a modpack.

Now finally, some gallows humour:

For all I care, this thread can be closed or stickied "Why to not propose a modpack". Maybe it would save other people with good intentions a lot of time.

cya .o/

[WololoW]

No offense to the wonderful modders that replied and those that didn't, but I suggest you go on with your endeavor despite what was said here. I for one would heed Nathan's advice and create MM config files instead of altering others .cfg's though.

As long as you do what you stated, your mod pack will be successful; and from what I know, will fall within the rules of posting mods here on the forum.

The requirement of a license for each mod is exactly for reasons like this. If the license provided by the author of the mod allows for redistribution, go ahead and redistribute it! They can/would have a different license if they didn't want that. Modpacks are a good way to get the mods you enjoy more public view, and therefore more deserved attention.

Ferram4 brings up a good point about support, but as long as you take support responsibility, there should* be no negative effect for the authors of the mods you include. Another idea that you could mull over would be letting the users know that if they want support from the mods author, that they must be using the version that is downloaded from the mods forum page and with none of your .cfg edits to it.

All in all, I think this community talks Modpacks down too much, and not enough brave souls have taken it upon themselves to create, distribute, and provide support for one because of the remarks on this forum.

Heres to hoping you keep at it and pave the way for future Modpack creators/supporters.

-WololoW

[JDCollie]

At the request of some of my very small viewer base, I too have made a mod pack. I'm not going to link it here because my goal is not to ninja or derail this thread, but I wanted to ask a few things:

1) I have provided the author/contributor names, mod form post, and the listed license the mod was released under in a text file in the document. Is this sufficient documentation? (I also clearly stated that I do not own any of the content I am redistributing in the same document)

2) I use several mods which are released under non-redistribution licenses in my Let's Play; I have removed those mods from my pack and provided links and installation instructions for those who wish to include them. I also did this for the one or two I couldn't find a license for. Should this be okay?

I also made sure to mention that by using the pack, players are acknowledging that there may be issues which arise from mod interaction, and that such issues aren't the problem of the mod authors.

Does that sound okay to you guys? Is there anything else I should be doing?

[OrbitusII]

@JDCollie:

I would make sure you have talked to the mod creators before redistributing their stuff. Even if the license doesn't require it it's still good practice. Other than that your documentation should be ok.

Since those mods don't allow redistribution or lack a license, you did the next best thing by giving instructions to install them.

Sounds good overall, and if you have a link I'll be sure to check out the thread.

Back on Topic:

I agree with WololoW in that modpacks are seen as a bad thing when the biggest problem is people who compile modpacks without using the licenses correctly or talking to the mod creators. Part of this may be a lack of interaction from the creators themselves, but problems are rarely caused by one singular issue. I for one try to respond to my threads and PMs as soon as possible because I dislike a lack of communication.

mololabo, if you can get permission to use all the mods you want, go for making your modpack! I think it'd be cool to see modpacks become a bigger thing in this community.

[NathanKell]

mololabo: Again not taking a stance on whether modpacks are good/evil/chaotic neutral, I do at least want to thank you for *clearly* putting much time and effort into considering the ramifications.

[AlphaAsh]

No matter how attentive and active you plan to be, you'll get bored or something will happen and leave it hanging. At the very least you're causing MORE version fragmentation. Every time someone says "I can't update your mod until the modpack updates" a tiny kitten is murdered.

Going to agree with Tiberion on this. Version fragmentation is going to come back on the devs of the mods you include, no matter how hard you try to middle the support. Also, where are YOU going to go to get the answers you need? Bam, straight back to the source with a huge issue list for probably an out-of-date version.

If you think you can keep up with the modders, then good luck to you. I'm afraid I'm going to be one of those gits who changes his licences if I'm being harassed for support of contents of a mod-pack.

[WololoW]

I'm afraid I'm going to be one of those gits who changes his licences if I'm being harassed for support of contents of a mod-pack.

I honestly implore you to do so now if this is how you truly feel. Your licensing should reflect what you want to happen with your mod. I am also very glad I have never seen your mods, because this statement would have made me uninstall them. Very close minded and rude.

edit*

FYI closing your license to redistribution does not stop it from being in a mod pack"*", it just makes it harder for other modders to utilize it within their distribution (imagine Toolbar had a closed license.)

"*"- They will just give the link and tell the people to download it at your forum page, making you retain all support requests and problems [which is actually better for the person that is making and supporting the mod because he stated that he would give support to any mod that was distributed in his pack and not distributing yours means he doesn't have to support it.]

TL;DR- Restricting redistribution of your mod will only make you have to support the people who are forced to download your mod from your page.

Edited August 28, 2014 by WololoW
Clarification and addition

[freerunnering]

I honestly employe you to do so now. I am also very glad I never have seen your mods, because this statement would have made me uninstall them. Very close minded and rude.

Seriously?!?

As a developer I've seen this sort of thing happen quite often. I know quite a few developers that start of open sourcing their stuff with very permissive licences, then it causes them trouble, so they restrict the licence. And then (for quite a few projects I've seen) they get people just recompiling the code and pretending it's their own so the original developers just end up close sourcing it completely.

A good rule of thumb if you want things to say open source with permissive licences: "Don't cause problems for the developers!"

[sumghai]

As a developer I've seen this sort of thing happen quite often. I know quite a few developers that start of open sourcing their stuff with very permissive licences, then it causes them trouble, so they restrict the licence. And then (for quite a few projects I've seen) they get people just recompiling the code and pretending it's their own so the original developers just end up close sourcing it completely.

A good rule of thumb if you want things to say open source with permissive licences: "Don't cause problems for the developers!"

I concur with freerunnering.

I encountered such a situation last year with FusTek. Someone wanted to distribute compressed versions of my part textures, but since I was overhauling the parts to use a common texture map (and UVs would get updated/moved around/reworked on an irregular basis), I privately told him to wait until I've finalized my overhaul. He agreed to do so privately, but then announced publicly the very next day that he was going to do it anyway.

When I pointed this out to him, he claimed that my licence permitted him to do so with or without my permission, and that he was "saving me the effort". My counterpoint was that the major changes I was implementing would render his optimizations completely useless and outdated. As it happened, he went ahead anyway, just as I released a dev build of my overhaul, and indeed, his "optimizations" became obsolete almost immediately.

At the end of the day, it's better to ask nicely and honor the decisions of the original add-ons' authors, instead of re-interpreting/exploiting permissive licenses to one's personal advantage.