[WIP] Inigma's KSP Essentials Mod List & Bare Essentials Mod Pack (in testing)

[inigma]

Updated OP with current permissions and licenses. All items on mod list except KAS are free to be redistributed in any mod pack, not just mine. Rather interesting study. Mod pack release will require a License doc itself explaining the proper credit for all mod pack authors, and copies of their licenses so as to contain everything required in the variety of licenses used. Took an hour of my time if not more. Wow. Worth it though as I have no further questions as to what is permitted. If you are a mod developer and you wish to give us expressed permission to include your mod in the pack by all means continue to do so - you will be noted and especially thanked for your contribution to making this list and pack a reality. If you have any special conditions you'd like us to meet, post below, and I will gladly do what I can to honor them! You guys rock!

[inigma]

Inigma's Bare Essentials Mod List is now complete. Testing complete. 32 bit only KSP tested. Should be compatible with 64 bit KSP as well, but not tested.

Mod List found here.

http://forum.kerbalspaceprogram.com/threads/94353-WIP-Inigma-s-KSP-Essentials-Mod-List-%28in-Testing%29?p=1428244&viewfull=1#post1428244

I guess this will be the first mod pack I actually publish.

[inigma]

First draft of the Bare Essentials Mod Pack readme: Any comments?

*************************************

Inigma's KSP Bare Essentials Mod Pack v .24.2a

*************************************

TESTED PLATFORM: 64 bit Windows 7, 32 bit KSP v .24.2

RELEASE DATE: 9/23/14

PURPOSE:

A minimalistic introduction to KSP mods with some of the most widely accepted and tested non-part mods. None of these mods change game physics by default. HyperEdit is included only to allow a builder to test their spacecraft prior to mission.

INSTALLTION:

To install simply copy and paste the contents of the GameData folder into your KSP GameData folder.

LICENSING:

All original mod downloads are in this pack and contain licensing information for the mods included. All mods permit redistribution, some with certain restrictions that are outlined in their attached licenses.

MODS:

Editor:

SelectRoot by FW Industries (MIT) - select a new root part for your vessel

RCS Build Aid by m4v (GNU LGPL v3) - adds an rcs center of balance and other visuals in VAB and SPH for perfect RCS placement

HyperEdit by Ezriilc (GNU GPL v3) - included for only for testing ship designs, not cheating

Command and Control:

Toolbar by blizzy78 (License Permitted) - essential GUI container for other mod buttons

Kerbal Alarm Clock by TriggerAu (MIT) - set timers that alert you to launch windows, SOI changes, and maneuver node pausing

Docking Port Alignment Indicator by NavyFish (License Permitted) - easier docking with a GUI

Missing Game Artifacts:

Mk2 Cockpit Internals by Sam Hall (CC BY-NC-SA 3.0) - opens the windows on the stock mk2 cockpit. the only visual enhancement that isn't, since it actually should be in the stock game aways.

SUPPORT:

Before asking a mod developer any question about the mods in this mod pack, please post your inquiry to http://forum.kerbalspaceprogram.com/threads/94353-WIP-Inigma-s-KSP-Essentials-Mod-List-(in-Testing)

Please see each mod's zip folder for any required documentation, or else please see http://forum.kerbalspaceprogram.com/threads/94353-WIP-Inigma-s-KSP-Essentials-Mod-List-%28in-Testing%29?p=1428244&viewfull=1#post1428244 for links to each mod's release or development thread.

If at anytime a mod developer has posted a newer version than what is posted in this mod pack, we ask that you first contact our mod pack support thread, else we recommend that you update to the latest versions of all mods in this pack, and only then solicit individual mod developers for assistance.

Edited September 23, 2014 by inigma

[ferram4]

You make a point that there aren't a lot of incompatibilities in the current mod market, and then post a concern about issues that may arise with deprecated mod versions the older one's set of mods get. You essentially countered your own disagreement behind the market desire for a mod pack, with your later stated concern of users using deprecated mod versions seeking support.

I did not argue that there was no market desire for modpacks. I stated that there was no market desire for modpacks for the purpose of removing incompatibilities, which is your stated main benefit of doing this.

In essence you concur there will be a market need at some point after a mod release to provide such support for users using deprecated mod versions!

There may be a desire for that, but there is no reason to support out-of-date versions. Ever. More importantly, you shouldn't bring anything up to a modder about fixing an old version of their mod; they have likely already made fixes and have no desire to try and support the zombie version that you are going to distribute.

Whether or not a user download and installs a mod pack with old versions though, or downloaded and installed mods individually when those versions were the latest and run into the same problems, there then exists in both scenarios the exact same incompatibilities and the lack of mod dev willingness to support such. There is a need for such a support service.

And which incompatibilities might these be? Do you have examples? If it were actually a problem requiring support by a third party, surely you would have enough examples to justify it; why have you not provided any like I asked?

The answer in both scenarios, which I think you may be missing: is that the end result is the same - to recommend the user to troubleshoot by removing mods to discover which is at fault, and then updating current mods with the latest versions starting with the at-fault mod, and only then bring up incompatibilities with the mod developer. At that point, regardless if they started out with a mod pack, or were an independent mod aficionado and installed mods independently at one point matching the same conditions as users with a mod pack, they would still go to the mod dev for support once the latest versions of all mods were finally installed and if the problem persisted.

So basically, in the end, for all the talk about dealing with incompatibilities, you provide no way to resolve them yourself; you simply shift any discussion of any (rare, I must reiterate) incompatibilities to another thread where they will not be seen by mod developer so that they can be fixed. What value does this add?

The only real benefit to the mod pack scenario is that multiple users would be affected, not just one, and thus a pattern better established, and perhaps additional data points for troubleshooting what otherwise would have been an isolated issue.

This is not a benefit. This is more users suffering issues, which is a bad thing.

I know testing this mod list and doing the work to make a mod pack is a lot of work.

You think it's a lot of work now?! Take my advice: abandon your project now. You will be overwhelmed trying to provide support if you think that throwing a few mods together is a lot of work.

What reward do I get? Same thing: recognition (but more importantly I'd rather just be happy knowing I helped someone enjoy KSP all the more since I want to see KSP thrive. I don't need to have my name associated with this project.

You should probably get rid of your name from the pack then. From where I'm sitting, it looks a lot like your trying to get recognition and glory based on other people's work, while providing almost no value of your own.

:MY RESPONSE: If the versions in the pack work well enough at the time of release, then new versions won't need to be updated "exactly when a mod updates" for any "up-to-date bugfixes" that could likely break compatibilities with other mods in the pack anyways! Granted new features may be missing, but concerns about bugs should be emphasized and worked out during the mod pack's testing phase, not necessarily post-release.

:MY RESPONSE: This is true regardless if a user installed a mod pack or downloaded the individual mod's version at the time that singular version was current. The support scenario and resulting solution is the same: update the mod! Most existing features do not change significantly between releases. If its a bug that is found that escaped the mod pack's original testing, then standard mod troubleshooting is the answer! Remove mods to isolate affected mod, update mod, and if doing so breaks compatibility with other mods whether in the mod pack or not, then update those mods as well. If unable to be fixed by the community or the affected mod devs after that, then users should be encouraged to simply remove the mod, and future releases of the pack should remove it as well!

:MY RESPONSE: The solutions always remain the same though, and the answers just as forth coming both here in this thread and in mod dev threads: remove offending mods to isolate cause, update all mods to latest versions, remove mods that can not be fixed. Simple eh? Stick to that response, forever, and there will be no issues. In fact, isn't this what is already being told to mod users that are having problems? So my approach is nothing different than what is already being done. I wouldn't expect mod devs to change what they are doing now anyways. It really is a seamless response. Except now the community has another point of support: this mod pack's user community, where I hope this mod pack user base collective intelligence will resolve problems even faster than the current user-mod dev support model.

So, the answer I get from these is, "not updating the mods isn't a problem, because even though users will run into issues that have already been fixed and that they wouldn't have to deal with if I just updated it like I should have, they can still download the updated version from the mod author's thread, after complaining to them / me about issues that were already fixed." This is the problem that I'm talking about. You've just told me that you will cause the problem that I'm worried about, as if it doesn't end up being a problem! Modders are going to get support requests for versions that are out-of-date and should be gone, but will continue being distributed due to you leaving that version up in your download. Thank you for confirming that my concerns are valid though, you're the first mod packer to do so, and so honestly.

:MY RESPONSE: Perhaps then I should leave instructions in the OP that if I am AFK for more than 3 months straight (no posts on KSP), Kerbal Stuff pulls the mod pack down, and any mod developer or user is welcome to inform Kerbal Stuff to do so at that point with the authorization from me, the list/pack manager, already in my OP. Call it a self-destruct clause if you will.

This is the only comforting about this. However, I'd urge you to pick something closer to a few weeks (since 3 months is less than the time between KSP updates, and mods update every few weeks normally), otherwise you will cause issues.

What value are you providing to this, beyond a zip and assurances that things work (the latter of which we can already provide, simply by the nature of KSP plugins)? The only "value" that I expect you will provide is to encourage more modders to deny support to users on the basis of outdated versions and due to any changes that you might make to their mods.

[mrBlaQ]

This is a bad idea. Don't created instantly-outdated bloatpacks just to pretend you're helping the community. Go make an informative wiki page and keep it up to date as new versions are released.

KerbalStuff's notification system is a far better solution to this clustermess.

[inigma]

@ferram4 There is a market for mod lists, and mod packs. Do you deny this? Beyond providing basic mod troubleshooting and feature help, I don't intend to provide out of date mod support. My recommendation for any irreconcilable mod conflict will always be to require the user to update individual mods to the latest version, test, and if it breaks other mods in the pack, report it to this thread so we can make a decision on what to do next: either report it to the mod devs, or remove it from the pack. There are incompatibilities with KAS and DMP, but none I've experienced. There may be incompatibilities with RCSsounds and Chatterer. In my testing I am discovering them and attempting to find work arounds. I am sharing my knowledge with the mod list and this thread, as well as sharing the final result in a mod pack. It looks like I may have to dump KAS altogether if I can't get licensing for it. If there is discovered and reported in this thread an incompatibility that requires the mod pack to be updated, then I hope my my self-destruct clause in my OP at 3 weeks of AWOL inactivity as you suggested takes effect by anyone reporting my absence to Kerbal Stuff asking them to take it down. Great idea.

Edit: Self Destruct clause added.

@mrBlaQ anytime a mod player downloads a list of their own choosen mods, are they instantly out of date? What's the difference if it was a group of individual mod players downloading the same mods at near the same time, or providing a pack? I'll have to check out KerbalStuff's notification system. I wonder if Kerbal Stuff would be interested in working with mod packers providing a mod list that then Kerbal Stuff can notify subscribers of new updates.

Edited September 23, 2014 by inigma

[ferram4]

@ferram4 There is a market for mod lists, and mod packs. Do you deny this?

So you didn't read the first statement of my last post. My attitude on that can be seen quite clearly there, that there is a market, but not for your main stated purpose / benefit, that of fixing incompatibilities. Because there are rarely any incompatibilities, and more importantly, when there are, you can't do anything to fix them.

Beyond providing basic mod troubleshooting and feature help, I don't intend to provide out of date mod support.

So you're not doing anything beyond what the average involved user of a mod does then.

My recommendation for any irreconcilable mod conflict will always be to require the user to update individual mods to the latest version, test, and if it breaks other mods in the pack, report it to this thread so we can make a decision on what to do next: either report it to the mod devs, or remove it from the pack.

So in the case of the rare incompatibility, you're seriously considering just letting it silently disappear so that mod developers aren't aware of the issue, and thus can't fix it? You're actively harming mod compatibility then.

There are incompatibilities with KAS and DMP, but none I've experienced.

This, at least, is an example. Thank you.

There may be incompatibilities with RCSsounds and Chatterer.

This, however, is guessing. If you can only provide one guaranteed example out of all the hundreds of mods we have, then incompatibilities are very much not a problem and your pack and claimed services are completely unnecessary.

In my testing I am discovering them and attempting to find work arounds.

Hint: if there are conflicts, there aren't work-arounds.

I am sharing my knowledge with the mod list and this thread, as well as sharing the final result in a mod pack.

And in the process, instead of bringing up the issue to the mod developers directly so that they can address it, you're hiding the results away somewhere else. Why? What benefit does doing this provide?

If there is discovered and reported in this thread an incompatibility that requires the mod pack to be updated, then I hope my my self-destruct clause in my OP at 3 weeks of AWOL inactivity as you suggested takes effect by anyone reporting my absence to Kerbal Stuff asking them to take it down. Great idea.

It's not incompatibilities! It's old bugs in each constituent mod itself, separate from any others. Those are the issues I worry about, issues that you are not seeming to comprehend.

Once again, what value are you providing with this? You have consistently ignored the fact that incompatibilities are not a serious issue and continue to state they are, as if you stating this again and again will make it true. It will not. There are not enough compatibilities to justify your efforts (as shown by the fact that you could only provide one incompatibility out of the hundreds of mods we have here) and of the one that you have provided as an example, you have not explained how your efforts alleviate that issue any better than we have done before you arrived.

I would suggest that rather than trying to gain your fame on the backs of others while providing no value in return that you attempt to create your own mod. That will provide value to the community, and will also make you far more aware of the issues involved in creating and supporting a mod int he first place. If you choose to go forward with a mod pack from that point on, you will actually have some appreciation for the problems that can and will result from that, and you will be better equipped to serve the users and modders that you intend to support.

Based on your statements in other threads, it's clear that you lack experience in developing and supporting mods, and a mod packer should not be a job undertaken by an inexperienced novice. Supporting a single mod can often be challenging; supporting the dozen or so mods that you intend to pack (as you will inevitably have to do) will burn you out, frustrate your users, and frustrate the modders who will have to pick up the slack / correct any mistakes that you make as a result of your inexperience. I know you won't take my advice, since you seem to be stubbornly refusing to acknowledge even the slightest knowledge about modding incompatibilities from people who know about them, but creating a mod (particularly a plugin) and supporting it will put you in a much better position to serve users than you are currently.

[inigma]

@ferram4 The mod list is called Inigma's KSP Essential Mod List because one's person's essential mod is another's bloat. I take full responsibility for the composition of the list. If I were to remove my name and just call it KSP Essential Mod List, then I'd face a new set of naysayers wondering what right I have to determine what is essential for KSP. Catch 22. So it remains Inigma's KSP Essential Mod List, unless you can propose a better name. As I said, I wouldn't care to remove my name from it. Heh. Maybe I should just call it KSP Essential Mod List and let the controversy roll in to see which side of the coin I get the least grief! And yes, I desire to work on learning mod development. I have two WIPs: a rotating docking port for post-docked vessel alignment, and looking into adding a resource layer that Karbonite can be broken down into further, with those resources finite but minable depending on type of location, and Karbonite more rare but still available universally. We'll see what I can pick up and contribute in that way too. For now, I think I will release the Bare Essentials pack when .25 is posted, just to prove to myself and the community that a properly managed pack isn't the pandora's box of problems you have shared with me as your worry. It's a simpler list. I might keep the larger KSP Essentials Mod List as just that - a list. We'll see. This thread won't be hiding anything from mod devs when a compatibility issue is discovered pre-pack-release. Post release, deprecated version bugs wont be forwarded to mod devs for obvious reasons. But post release, current version bugs will be forwarded. I don't see a problem, but I do thank you for sharing your concerns and allowing me to address them. I hope at least other mod packers will learn from my example...which is why I want to set a good one. If you did support a mod packer, what would you realistically want to see in one?

Edited September 24, 2014 by inigma

[ferram4]

@ferram4 The mod list is called Inigma's KSP Essential Mod List because one's person's essential mod is another's bloat. I take full responsibility for the composition of the list. If I were to remove my name and just call it KSP Essential Mod List, then I'd face a new set of naysayers wondering what right I have to determine what is essential for KSP. Catch 22. So it remains Inigma's KSP Essential Mod List, unless you can propose a better name. As I said, I wouldn't care to remove my name from it. Heh. Maybe I should just call it KSP Essential Mod List and let the controversy roll in to see which side of the coin I get the least grief!

It would be logical to name it something that makes sense. "Essentials" doesn't actually make much sense, especially considering that I play with almost none of the mods on your list, and many of them don't really fill essential holes in the game. As for throwing your name on it, well, it looks like you're trying to bill yourself as the great packer of everything essential for KSP modding. There's not much way around it when you're not developing any of the mods in the pack yourself; you just look like you're trying to get recognition for you based on someone else's work. Perhaps you should consider making it "The Assorted Tools" pack or something like that, a name far more descriptive of what it actually is.

And yes, I desire to work on learning mod development. I have two WIPs: a rotating docking port for post-docked vessel alignment, and looking into adding a resource layer that Karbonite can be broken down into further, with those resources finite but minable depending on type of location, and Karbonite more rare but still available universally. We'll see what I can pick up and contribute in that way too.

Good! You should do that before you release any packs though. You should experience what happens when someone who doesn't completely understand your code tries to provide support, and provides it badly. You should experience the effort you need to put in to correct inaccurate "common knowledge" that crops up when people out-of-the-know start trying to help with mod support and perceived incompatibilities. You should experience the joy of trying to stop a rash of people from deleting a required dependency because someone said, "this fixes it!" when it didn't. You should work on your mods and release them so that you can see all the trouble that someone like you will cause when you provide inaccurate support info. And make no mistake: you will provide inaccurate support info. You can't know any of these mods better than their respective authors, and so you will inevitably make more mistakes in support than they will. And both the users and mod developers will have to deal with the consequences of that.

For now, I think I will release the Bare Essentials pack when .25 is posted, just to prove to myself and the community that a properly managed pack isn't the pandora's box of problems you have shared with me as your worry. It's a simpler list. I might keep the larger KSP Essentials Mod List as just that - a list. We'll see.

And if all of my worries come to fruition, what then? Will you close up shop? When the problems inevitably occur, and we come to you talking about the issues that you have caused, will you accept that they are legitimate and concede, or will you continue to deny that they exist?

This thread won't be hiding anything from mod devs when a compatibility issue is discovered pre-pack-release. Post release, deprecated version bugs wont be forwarded to mod devs for obvious reasons. But post release, current version bugs will be forwarded.

Why go through with the forwarding at all? What benefit do any mod developers get from needing to have bug reports forwarded to them rather than given to them directly? What benefit is there to users and mod developers when you're sitting there as the middleman in between us? Why do we need you, when we've gotten on so well without you?

I don't see a problem, but I do thank you for sharing your concerns and allowing me to address them. I hope at least other mod packers will learn from my example...which is why I want to set a good one. If you did support a mod packer, what would you realistically want to see in one?

I don't see what I would want in one, because I don't see the point of a modpack. Ever. So I guess the answer would be nothing, then.

[RoverDude]

Hey inigma - any chance on getting the self destruct clause at two weeks? Given the sheer velocity of my mods that would make me more comfortable Figure you'd need to be here anyway on an almost daily basis regardless to maintain this.

[inigma]

@ferram4 Thanks for your input! Yes if the Bare Essentials pack causes the irresolvable problems you fear, I will pull it, close up shop and you can use this thread as an example of what not to do. Regarding the name, its not a tools pack. Is my own configured pack of mods that I install in every game I play which I consider essential and have bothered to test in several games over time. You don't have to subscribe to that. You're worried about an ugly duckling before the eggs have even hatched. I'm darned if I name the pack after me, and darned if I don't. I'm darned if there are no compatibility issues to justify assembling the pack, and darned if I discover or "introduce" any in the process of doing so. I'm darned if I don't support the mods in the pack, and darned if I don't. I'm darned if I require subscribers to post incompatibility issues in my mod pack thread, and darned if I refer them to seek help from mod dev threads. Not to ask the obvious question, but what do you want? You've already made it clear you just don't like mod packs, but the reasons you state your dislike appear to conflict. Just remove the idea of me as a mod packer and just consider me as a single user of all these mods together, would you then have a problem with me seeking support from you or discussing my problems with others? What if there were duplicates of me all experiencing the same issues then - would it really be a problem giving them all the same answers or even a relief that others like me are figuring out solutions on our own and sharing them? From this I gather from you and others is that the whole argument against mod packs and their subscribers is just an argument against using multiple mods and individual players who find themselves in the same situation as other players of the same multiple mods. Is this what you want to argue? Other than my own mod experience being duplicated by others, the only substantial argument against mod packs I can gather so far from others is a loss of download count, which can be rectified by sharing that info.

Regardless, as I said, this will be an unpluggable experiment if it goes awry. Are you at least ok with that?

I do have one question for you though: if you could recommend a list if mods that didn't add parts or change game physics, what would you recommend to new players who have never played with mods but still want a mostly stock game experience? What's in Ferram's KSP Bare Essentials Mod List?

@RoverDude: You want two weeks? You've got it!

Edited September 24, 2014 by inigma

[inigma]

Removed the following mods from the KSP Essentials Mod List

• TweakableEverything by toadicus (License Permitted)(P) - tweaks part parameters such as engine thrust, decoupler expolsive charge, docking port magnetic power, etc. (was removed due to tweaks able to apply values greater than stock game, which is physics changing and not in line with the theme of this pack unless mod dev can confirm or limit tweakables to stock max values)
  
• Navball Docking Alignment Indicator by mic_e (✓)(GNU LGPL v3)(P) - easier docking with a navball aid (removed due to possible conflict with upcoming .25 navball. Uncertain for now. When .25 is released NDAI will be reconsidered)
  
• Improved Chase Camera by BahamutoD (GNU GPL v3) - chase camera follows current velocity vector, not rear of craft (removed due to current limitations with ICC being constantly on, causing manual flight errors when switching camera views, will be reconsidered if default value is reprogrammed to off.)
  
• Kerbal EVA Resource Transfer by marce (CC BY-NC-SA Intl 4.0)(P) - EVA Kerbals can carry a small amount of any resource and transfer it to another vessel (was useful to move some resources, but not practical. marce, if you can find a way to have EVAs carry a fuel pipe to connect two vessels together to allow resource transfer, then it would add a larger value to the EVA RT mod! right now its nice, but i don't see value yet in an "essentials" pack after playing with it for a while since small resource transfer isn't practical yet except to maybe kickstart a dead vessel. If you made KERT able to connect pipes between vessels, you'd have a winner!)
  

Added Procedural Fairings to KSP Essentials list, though it adds parts, they are actually missing parts that should be included in the stock game at gold release.

[inigma]

Should I include RCS Sound Effects in the Bare Essentials List? No conflicts, and adds something that is missing in stock that might get added later.

[ferram4]

@ferram4 Thanks for your input! Yes if the Bare Essentials pack causes the irresolvable problems you fear, I will pull it, close up shop and you can use this thread as an example of what not to do. Regarding the name, its not a tools pack. Is my own configured pack of mods that I install in every game I play which I consider essential and have bothered to test in several games over time.

And yet the name tells me nothing about what's in it at all. At least my glory seeking mod name talks about aerodynamics.

You don't have to subscribe to that. You're worried about an ugly duckling before the eggs have even hatched. I'm darned if I name the pack after me, and darned if I don't.

Not really, you could name it something descriptive.

I'm darned if there are no compatibility issues to justify assembling the pack, and darned if I discover or "introduce" any in the process of doing so.

No, it's just that incompatibility issues only occur in code, and unless you're going to go into the mods and change their code specifically for your pack to fix the conflict, you can't do anything. The problem is that there is nothing a packer can do to fix incompatibilities while still being just a packer, and the incompatibilities that happen are few and far between.

I'm darned if I don't support the mods in the pack, and darned if I don't. I'm darned if I require subscribers to post incompatibility issues in my mod pack thread, and darned if I refer them to seek help from mod dev threads. Not to ask the obvious question, but what do you want? You've already made it clear you just don't like mod packs, but the reasons you state your dislike appear to conflict.

That's like saying that when you're caught between a rock and a hard place your inability to move right or left is in conflict; that's not the case. It's simpyl that both solutions to the support problem have serious downsides as a simple fact that you're redistributing another person's work.

If you do provide support, mod developers and users have to rely on you to know what you're doing. The problem is you can't, simply because you didn't make or maintain the code in the mods you're distributing. So you would be a blind person leading the blind, and we'll have to try and deal with the result of users breaking things following your advice, or other users repeating your statements and causing the same problems, and then (when you finally get around to forwarding any bug reports) we have to hope that you actually got all the information necessary. All of this requires that you're at least a mod developer to start with so you know the problems that you can run into.

If you don't provide support, then our support workload and frustration is directly tied to whatever you distribute. If you make silent changes to the mods in the name of compatibility, but that causes issues, then we have to deal with the consequences of that. If you don't update on time, we're getting support requests for issues that might have already been fixed because users are getting old builds with whatever bugs might be in them, and we have to pick up the mess.

It's not contradictory to say both problems have their issues, especially since they're the direct results of redistributing someone else's work. Both options are terrible. There's no way around that. It's just how modpacks are.

Just remove the idea of me as a mod packer and just consider me as a single user of all these mods together, would you then have a problem with me seeking support from you or discussing my problems with others?

The first point, no, unless you're also redistributing those mods as a pack. The second point, no, until you make a mistake and start spreading inaccurate information, which will happen, and yes, has happened, and yes, we will have to deal with it.

What if there were duplicates of me all experiencing the same issues then - would it really be a problem giving them all the same answers or even a relief that others like me are figuring out solutions on our own and sharing them?

This was how we got people repeating that "ModuleManager conflicts with X!" (when it doesn't) and advocating for deleting it, breaking tons of mods in the process. You are assuming that users know how the mods work; a very large majority (including yourself, based on your other posts elsewhere) don't, and that's where the really nasty problems start.

From this I gather from you and others is that the whole argument against mod packs and their subscribers is just an argument against using multiple mods and individual players who find themselves in the same situation as other players of the same multiple mods.

Ah. So you are going to dismiss all of my support-based concerns because it does not fit what you desire. And I should trust you to willingly cave once you cause these issues later, why?

Is this what you want to argue? Other than my own mod experience being duplicated by others, the only substantial argument against mod packs I can gather so far from others is a loss of download count, which can be rectified by sharing that info.

Or... there are all the support issues that you have completely dismissed because they don't fit your narrative. If you really think that the only substantial argument is download counts, then you're in for a rude awakening when you find yourself in the middle of a support nightmare.

Regardless, as I said, this will be an unpluggable experiment if it goes awry. Are you at least ok with that?

I am ok with that, but I worry given how quickly you've dismissed support concerns that you will continue to keep it alive, regardless of how much damage it causes.

I do have one question for you though: if you could recommend a list if mods that didn't add parts or change game physics, what would you recommend to new players who have never played with mods but still want a mostly stock game experience? What's in Ferram's KSP Bare Essentials Mod List?

There is nothing there, primarily because the only two "essentials" I actually use change the game physics.

[inigma]

I am ok with that, but I worry given how quickly you've dismissed support concerns that you will continue to keep it alive, regardless of how much damage it causes.

Thats just it. Even you agree on the rarity of mod incompatibility. If I assemble well tested mods and test their compatibility with each other before any initial release, the rarity of such a drastic issue being discovered post-release is even more minimal the older it gets. But even if a glaring incompatibility or serious mod bug were discovered post release, my self destruct clause should alleviate that support concern outright. The pack wont be kept alive for long in such a scenario.

Long term, only feature support would be an issue compared to the latest mod release, but only deprecated features would be an issue - yet how often do mod devs deprecate features? In such a scenario a user would be instructed to download the latest mod version - the same response a mod pack user should also get.

Edited September 24, 2014 by inigma

[Specialist290]

As this thread is a duplicate of a previous thread that has already been locked due to disputes over the possibility of using licensed material without permission, we of the moderation staff have decided that this thread should be closed as well.

To reiterate a point from the previous thread: We aren't opposed to users creating modpacks, as long as they take the time to ensure that everything is above-board regarding respecting licenses and obtaining permission (when and where necessary) from the original mods' creators.

Everyone have a nice day

Nevermind; see sal's post below. Now that everything's been sorted out, carry on.

Edited September 29, 2014 by Specialist290

[sal_vager]

Reopened as it's not breaking any rules.

inigma intends to stick to the addon rules and only include addons with permission, please continue discussion.

[inigma]

I have confirmed that KAS conflicts with DMP. When one does a pipe connection between two vessels, KAS destroys both vessels and creates a new merged one. DMP doesn't see this action and instead sees a new duplicate vessel created in the space of the old. When a player reloads from the tracking center, the KSP physics engine tears the duplicated vessels into a massive parts explosion as parts attempt to occupy the same space as their duplicate. Until corrected, and since KAS is not open source, I can see it as an easy decision to dump KAS from the mod list when DMP is priority.

[inigma]

The latest development build of DMP fixes the KAS issue. With .25 out I am testing the Bare Essentials pack, as well as the Essentials list again.

[inigma]

As far as I've tested, the mods listed in the KSP Bare Essentials Mod Pack are fully compatible with KSP .25.

Edited October 7, 2014 by inigma

[NathanKell]

What subset is "bare"? Certainly some on the list have issues in .25.

[inigma]

What subset is "bare"? Certainly some on the list have issues in .25.

This subset (found in the next post after this thread's OP):

http://forum.kerbalspaceprogram.com/threads/94353-WIP-Inigma-s-KSP-Essentials-Mod-List-%28in-Testing%29?p=1428244&viewfull=1#post1428244

RCS Build Aid will need a recompile using the .25 assemblies, but it works when you do.

Edited October 8, 2014 by inigma

[NathanKell]

My understanding is that selectroot also has issues.

That said, the real test is this: do any of them throw compatibility warnings when you launch KSP? If so, then (with the exception of blizzy's toolbar, see his dev thread) they should not be treated as compatible.

[inigma]

My understanding is that selectroot also has issues.

That said, the real test is this: do any of them throw compatibility warnings when you launch KSP? If so, then (with the exception of blizzy's toolbar, see his dev thread) they should not be treated as compatible.

RCS needs a recompile but I don't see any warnings. The rest work. Doing more in-game testing now. I won't publish a formal Add-On Releases thread with a .zip until I test it more. If anyone else has testing they've done and find something, let me know right away!

Edited October 8, 2014 by inigma

[ApostleThirteen]

KAS does not work with .25