OmniscientQ

How is the player supposed to know that the Agriculture Support Module uses Crusher efficiency parts without looking it up on the Github wiki? That's exactly my point. I'm reasonably sure it used to be displayed on the part in the VAB. In other news, I tested a fresh download of MKS with a fresh install of KSP and no other mods. The various parts still do not display a module that declares which type of efficiency they "consume" nor how much. They do still work, though. An inflatable hab part successfully enhanced the output of an agroponics module on the launchpad.

This used to be a much longer post, but most of it was irrelevant. Here's the important bit: I think I remember, once upon a time, that for MKS parts that could be enhanced by productivity boosters, their specific type and weighted booster consumption were listed as a module on the part in-game. Today, however, I find that while the inflatable habitation parts and the Ranger agriculture part all say they boost "Greenhouse" converters, none of the Tundra modules explicitly state that they are boosted by greenhouses. The same goes for Crushers, Smelters, and Workshops. Am I simply misremembering the way such data used to be displayed, or do I perhaps need to re-download MKS, or is it because some part of MKS was broken by KSP going up a version?

I tried building an all-inclusive monolith that I called the "Omnifactorium". The idea was to have one of everything on it that I could then expand by dropping a standardized colony pod nearby. Each colony pod had a Colonization module, and enough MPU, Agriculture, and Workshop space to boost the output of the Omnifactorium by enough to accomodate another six Kerbals. It... didn't go so well. Honestly, I should learn to use the konstruction ports more.

Hm. I guess I haven't honestly paid much attention to the trigger conditions for planetary and local logistics. For example, I usually have one vessel as a dedicated supply depot, with a Pioneer/Logistics module and enough storage units for at least every raw resource, then use local logistics to transfer to other factory vessels. (No need to put a logistics module on every single vessel in a colony.) Is the 10% capacity transferred per LL cycle determined by the source, the target, the larger vessel, or the smaller vessel?

How feasible would it be to add governor sliders for each bay in a MKS converter? I can add a github issue, but I'd feel embarrassed to ask for it if there were some technical limitation in the way. EDIT: I just remembered that I had another MKS-related question. Are catch-up conversions still done in 6-hour chunks, meaning any facility should have at least 6 hours of input/output storage in order to maintain full efficiency? I saw a page or so back that someone was recommending 60 hours of storage to allow for local logistics. And do those guidelines apply for electrical storage and distribution? Six hours of battery storage to run a workshop that's sucking down 100 EC/s is not trivial.

I agree with most of the rest here. I hate it, but it can be disabled, so I don't care. And it's obvious enough that it CAN be disabled. It's not like the games primary options menu is hidden or anything. It's not a console command.

I actually enjoy reinventing the wheel every time I start a new game. Most of my early vessels wind up being identical to the ones I used last game, but sometimes the mission parameters change. Contracts are different, and I'll decide it's worth the 20,000 fund bonus to include a part or use a different engine than I had planned. I tend not to build standardized, reusable vessels until I've finished up the tech tree. Once I start building those, however, I'll always forget some little detail, or wonder how I managed to cram all the science parts into my tiny little spaceplane last time, and I wind up doing things differently anyway. I learn new techniques that way, and it keeps the game from getting old.

[quote name='dziki0022']Another anoyng thing is share of crew specially at start where you just got 2 pilots so max 2 person can fly at once. I hope devs will give us nice multi with separate launchpads and ability to coop[/QUOTE] Unless they changed something in the "silent" patch the other day, you don't need a pilot-class Kerbal to launch anything. I'd be okay with them adding a second or third launchpad to the KSC, but there's absolutely no reason for a second space center. I'm not sure how anyone could have played this game and imagined a competitive Player-vs-Player mode of any kind, whether it's a race to the stars or shooting rockets at each others space center. Kerbal Space Program has always been about the Player vs Gravity. If and when multiplayer is added to the game, it'll wind up being purely cooperative (outside of mods, of course). I welcome the idea. For one thing, there's all kinds of missions I've dreamed up but been unable to carry out due to engine limitations (mostly regarding atmospheric flight and the on-rails destruction radius). Having a second player to run the other craft would be perfect. And when the mission inevitably goes wrong, then my buddy and I get to watch Jebediah die in a huge fireball together. I'm on the fence about how much interaction needs to be programmed into the game for the planning stages. The VAB, SPH, and administrative buildings can all be operated independently be each player. I imagine that for most people, the details of a mission will be planned out via Skype or IRC or whatever before KSP is even launched. The only thing that is needed is to transmit the .craft files to each player, and a means of deciding who controls what if you're launching a single vessel together. As an added bonus, multiplayer would necessarily bring with it a server/client model that would let me put more than one computer to use, even if I'm playing alone. I'd love to be able to hand off to a dedicated server some of the extreme amounts of math that currently make my computer cry if I try to launch a vessel with more than 100 parts in it.

I'd be happy with a maneuver node that doesn't change its orientation as you plan maneuvers. I wouldn't be at all happy with one that changed the orientation of the node handles, and changed their behaviors as you go. The maneuver nodes as they function now gave me a much better understanding of the orbital mechanics involved precisely because I could watch as the new orbit failed to change in the way I expected it to. Orbital mechanics are (to most people) completely non-intuitive, and the current nodes allowed me to understand WHY I was wrong. And understanding why I was wrong made it trivial to use the nodes as-is.

People who run life support mods certainly are. I can see a kind of sticking point, in which you establish your "routine" resupply mission when Kerbin and Duna are at a minimum-delta-v position, and then somehow continue that supply run without modification when they're on opposite sides of Kerbol. I would definitely be willing to concede that "routine" missions can only occur in Kerbin's SOI. But since all missions originate from Kerbin (barring even more mods that let you build and launch from other bodies), it'd still be a useful feature. If you have a non-self-sustaining base on Duna, then you should build it to go a year without resupply, regardless of convenient automation features.

That is possibly the most hilarious sentence I've read on these forums.

I agree with both camps here, somehow. I acknowledge that having a Revert button and self-imposed challenge of declaring a launch to be "simulated" or "real" before I press the button achieves one part of the goal... But I would really, REALLY like to be able to just warp my lander straight to a simulation of Duna so I can test its performance before I even start worrying about how I'll get the lander off of Kerbin. I could sit back and do all the math involved in calculating the drag myself to try and guess what the performance will be like, and I've done it before. I'll even admit that it's how NASA had to do things once. But honestly... Sometimes I just wanna watch the pretty colors as my lander explodes with Jeb inside it without having to go through twenty minutes of launch and rendezvous corrections first. Being able to pick a body and drop a craft in as a simulation shouldn't be something I have to hack in with third-party programs or a text editor.

You, sir, win all of the Kerbals.

Oh, yes, yes. A thousand times, yes. I frequently build rockets in which I need to swap control at launch from the rear-facing command module to a probe core buried underneath a fairing at the bottom of the stack... And trying to maneuver the camera is a huge pain.

My Top 5 wants for a future version? Hm... 1) Better automation of "routine" flights. Exactly how one would determine what is "routine" can be up for debate, but there are plenty of times I wish I could reduce the tedious parts of running a space agency. When I build an air-to-space launch vehicle (a rocket piggybacking on a conventional aircraft), I want the aircraft to return to KSC on its own while I fly the rocket. When I set up a mining and refueling depot on Minmus and prove to myself that the fuel hauler and orbital refinery and mining operation all work by doing a few fuel runs myself, I want to be able to turn that over to the crew. If I have a life support mod enabled (or if it gets added as a stock option later), I want to be able to automate the resupply missions, after I do it myself a few times. 2) Reworked science. Experiments, science labs, and all. I have a thread here about how I'd like to see the science system redone, but almost any change would be a welcome one. A science system that's friendlier to mods and more sciencey. The one we have was a nice, basic proof-of-concept for career mode, but it's time to put together the real deal. 3) Multiplayer. Yeah, I know. This is a seriously divisive issue. There's all kinds of arguments for and against, and competitive gameplay, and multiplayer balance, and all of that. I don't think KSP needs a competitive game mode in which players race each other to the Mun, or launch nuclear-tipped rockets at each others space centers. You don't need to worry about getting paired up with a troll by the match-making system. KSP has never been that kind of game. You can't just meet up with some random person from the internet and start playing in the VAB. If the person you play with tries to ruin your fun... why are you playing with them at all? In any kind of multiplayer experience, the mission specifics will probably have been hashed out in advance on IRC, parameters defined, and only after it's been decided does anyone actually launch KSP. Cooperative play. KSP has always been about the player vs the unforgiving laws of physics. I just want my buddy to come along for the ride. 4) Scale-able parts. I know it's been said before, but sometimes the girders are just a hair too big, or too small, or too round. Sometimes I want to cram a part inside of another part (The 2.5m utility bay is a godsend for me. I hated trying to fit the materials science bay into an otherwise large rocket because the damn thing can only be stack-mounted). Even better, it'd make it easier to balance the center of gravity on asymmetrical ship designs. I hate having exceedingly long rockets. I want big, fat ones. But since the science lab and ISRU and the Near-Future nuclear reactors aren't all the same weight, I can't radially mount one of each without throwing the CoG off-center. A scalable part would let me adjust the distance from center of each one based on its weight. 5) Kerbin monkeys. What kind of frikkin' space program doesn't shoot monkeys into outer-frikkin'-space? Don't give me any of that "Kerbals are kind of like monkeys" stuff. I want my space monkeys!