mololabo

Tighter payloads, by being able to let a power hungry satellite fold out large solar assemblies made off of steel beams / structural parts that are folded to the side, to which the solar panels are attached. I am desperately waiting for this mod to be fully released. I have always enjoyed it a lot. Thanks for all your hard work <3

Well, I don't know what it was, but I fixed it with a CKAN uninstall, deleting the folder by hand (I don't know right now which mod put anything in there), and reinstalling it. Made quick plane to test it: Edit: So... I would recommend trying that if anything goes awry in the future. Thanks for answering my question earlier!

Not that I know of. I checked for that mod/cfg and I generally don't use WIP versions. (I naturally did some searching before posing my question). However, I will check for that error later today when I am back home. I'm also not expecting any help at this point since my install is heavily modded.

That was the answer I am looking for. Now I only need to find out why in my heavily modded install the CoM and CoL doesn't change when I change the wing dimensions.

Short question regarding my understanding of the requirements for using this mod: Does that mean that if I use FAR, I should use the latest FAR version? Or does it mean, that using a newer FAR version is a hard requirement? Since it is also only written under "note" and I otherwise can't read anything about "requirements" I am simply not sure. Thanks for any answers!

Wow. I only wanted to come out of the woodwork again when I've finally built something. But I didn't expect this to blow up as much as it did. I'm sorry if anybody feels like I've just caused unnecessary stress. I still believe in the idea I have and while I would still really like to build it, as I already stated, I will explicitly NOT go against the wishes of the mod creators. I still want to start contributing to this community, and after having trained in C# and made myself more comfortable with the Module Manager, I will probably try to build something along the lines of the RO (pack? thread? whatever term makes you feel most comfortable!). And build some useful tools wherever I might think I might be able to pitch in. To the "version fragmentation" problem I just have one bit to say: It's already happening. Users are already in a situation where they can't update mod x because y hasn't updated yet. Some people (have?) put off updating KSP because some of their favorite mods weren't ready yet. Maybe some put off installing the newest B9 pack, because Hot Rockets don't work with it yet? Since TAC LS has updated from Kerbal/day units to liters, it still doesn't have any way to recycle food (or rather solid waste) again, CELSS Greenhouses wasn't completely updated yet the last time I looked and conversation errors seem to have been everywhere. The only thing I would've felt a modpack would make better in that regard, is that it would keep the "experience together" until the compatibility of the all included mods can be guaranteed by the pack-supporter in some way. Yes, we have the ModuleManager, KSP mods are highly compatible and dynamic and I absolutely love the flexibilty of this system. But while MM might make it easier to put the pipes between mods together, they're still pretty disjointed most of the time. I would also concur with WololoW concerning the choosing of licenses and terms. However, I also understand the mod creators concerns... Therefore... ... as I said, I will not create a modpack since it obviously goes against the will of the modders who crafted the mods I love to use, without which I would've stopped playing KSP ages ago. I've still got nothing but love and admiration for those beautiful mods you all crafted which made more out of KSP, than it currently is. But I am also out of energy right now and will not continue to bother you with my initial idea. I'd rather get into doing something productive for KSP this weekend and see what I can cook up. I hope I will still be welcome with the occasional development question after all of this and wish you all a hopefully short Friday and a nice weekend! molo off .o/

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/

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.

@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.

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.

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""

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: 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

Mhm, just a quick thought.... but given, that we have clear-text access to the cfg files, shouldn't it be possible to crawl and auto-generate that list somehow? Either way, quite interesting and thanks a lot!

I've got B9 here, but not installed yet. The other two are, of course, installed already

Hey there brave adventurers, hobby astronauts and pilots! I'm pretty new (to the game), but seeing/reading how incredibly helpful and friendly you guys and girls seem to be here, I decided to just give it a chance and maybe take part in the forum-life a bit. Seriously though, it has been a really long time since I encountered a forum and community as friendly and helpful as this one. (from what I gathered from all kinds of threads after having lurked for some time) I've started only some weeks ago and have pretty much gone through most of the science tree already with the help of quite a lot of missions to the Mün and on Kerbal. Minmun is my next target and after that manned missions to Duna. Already brought a science drone into orbit around Duna and I'm currently preparing one for Eve as well. I'm quite a modfreak and have enjoyed using mods in all kinds of games. And, well, KSP is no exception. I'll be glad to hear about your suggestions and tips. And I'll be thankful when you point me in the right direction should I happen to violate any rules. (I've read them and will try my best to adhere to them of course) And maybe help some other little newbies somewhere in the future. Random bit of information about my KSP habits: I "version" my rockets. Every major new design which serves the same purpose is a new "mark". Every iterative change a new version. So my main rocket, at the moment, is the "Explorer Mark III V2", with a subversion of "Explorer Mark II V2 KProbe" and "-SProbe". Respective with a Kethane scanning remote satellite and a science satellite.

Just tested it, everything is working as expected now. Thanks a lot for your patience and quick help! I'm going to try out your engines now.

I used the Mod Manager. Seems like it really is a dumb mistake on my part. Thanks a lot for your help, I will try that later tonight and report back!

First off: Thanks a lot for your hard work! I've got a small problem with your mod (Electrical Engines) though, and I hope I'm right with posting here about it. Basically: Your xenon tanks do not appear in my game. Neither in career mode (in which I already unlocked ion engines), nor in sandbox mode, from which I took the following screenshot: Version 0.22 of the game, using a bunch of mods. I'll be glad to provide any other information you might need to fix this. Or point me to my own stupid fault.