Starstrider42

Without MM, any kerbonauts (stupid or smart) outside the workshop will have no effect. So basically, same rules as I quoted, except only smart kerbals in the workshop help you, and only stupid kerbals in the workshop hurt you. My apologies; I've played so long with Module Manager that I forgot it was a prerequisite. Also, something I forgot to include in my explanation: if you right click on any (crewed?) part, the menu will show you "part productivity", which is basically a measure of how good your kerbals are at extraplanetary construction. It will also show you "vessel productivity", which is just the sum of part productivity across all parts, and is the stat you want to maximize to get fast builds. Before you start moving kerbals around, check if it's negative. Actually, there is: go into map view, then click the kerbonaut icon on the right side of the screen. You'll get a complete crew list by part, with stupidity/courage stats for each.

You need a crew of smart kerbals (stupid ones will actually slow you down), and you need to give them space to work. Kerbals in command pods will have the smallest effect on construction rate, those in hitchhikers slightly more, those in labs still more, and those in the new Construction Workshop part most of all. So most likely you have too many stupid kerbonauts on your crew, and they're getting in the way of their smarter peers.

I don't think this will be a problem, for two reasons. The first is that Toolbar is so popular, and so widely adopted by many of the bigshot modders (including ones with an existing track record for adopting others' mods) that it's inevitable that it will remain supported even if blizzy78 leaves. The second is that blizzy78 has been *extremely* professional about proper versioning and backwards compatibility. They know what would happen if they got sloppy.

That kind of depends on how your own brain works, methinks. What I've been doing for my own mod is making heavy use of feature branches, and using the standard "main branch must always work" rule -- that adds enough overhead to starting a new feature that it discourages me from working on more than 1-2 features at once. My record so far has been 3 simultaneous features, but those were so closely related that it was actually easier to work on them all at once.

Actually, appealing to popularity is not a bad idea when it comes to interface design: http://en.wikipedia.org/wiki/Principle_of_least_surprise.

Delete everything except the parts with "BoulderCo/Clouds/Textures/duna2" as their texture. Those are the dust storm parts, the rest are duplicates of the default texture.

That's not part of final frontier, that's the toolbar. Click on the down arrow, then click on "unlock position and size". Don't think it's possible to completely hide it except with F2, but you can place it near the edge of the screen and it will be less obtrusive than, say, the MechJeb panel.

You can move it by dragging pretty much any part of it. As for closing... well, there should be a "Close" button in the upper right corner. To open it again, click the Toolbar button labeled "FF". You may need to set up Toolbar to show it. You can also hit ALT+F to toggle the window, but that feature seems to be a bit buggy at the moment.

Yes, by the power of Module Manager: http://forum.kerbalspaceprogram.com/threads/55219 Though it takes some familiarity with KSP's config file format; specifically, you need to be able to read and understand the .cfg files for the parts you want to edit.

Huh? This is news to me. I thought all the stock converters had a flat 90% efficiency.

Not yet, but I'd like to add large asteroids at some point. Can you pm me a copy of KSP_Data/output_log.txt, or post it on GitHub? It sounds like the plugin had a catastrophic failure early on, but I can't fix it without more info.

Because plants metabolize, period. No life form keeps everything it consumes; whatever isn't used for structural material (i.e., edible stuff) gets used for its energy and turned into waste products. And that's assuming you're using some magic GM crop where everything is digestible, something that's certainly well beyond our own biotechnology. For real crops, only some of the matter that stays in the plant is actually fit for food. While closed-matter biospheres can exist (the Earth is proof of that), it's extremely difficult to make one artificially. There are always sinks, which we can abstract into the TAC framework as an imperfect conversion efficiency. Also, game balance. As RoverDude said, a life support system that lasts indefinitely defeats the purpose of having a life support system in the first place.

I've been thinking about that, but the parsing would be a nightmare. I'll see what I can do, but no promises. EDIT: Hmm... actually, now that I think about it, Trigger Au's guide had a trick that I could use here. Still no promises, but I'm starting to think I'll be able to pull it off.

All the configs are read. Unfortunately, since they tend to be redundant with each other you'll have to remove the extra cloud layers. Hit ALT+N while in-game to access the editor, then delete the extra copies of the layers that are in both files.

Don't know what causes it (not RSS, because I don't have it), but you can work around it by exiting and reloading your save. That bug never strikes twice in a row.

Since nobody else has brought this up... The flaps on the bottom set of fins are almost certainly too powerful. When combined with SAS, you get a rocket that's unstable in flight simply because it keeps overcompensating for tiny course changes. Either remove the flaps entirely (if you have five SAS modules, plus gimbals, you don't need aerodynamic control surfaces), or right click on them in the VAB and turn the "control authority" setting way down. Had a lot of trouble launching rockets until I learned that trick, though most of them spun instead of flipping.

You, sir, have the heart and soul of a kerbal. (Though IMO using a self-guided bowling ball is cheating )

Have you tried checking for the acceleration on your ship/part? That could address most of the things on your list (decoupler, both engine issues, touchdown).

If your Kerbin satellite and Duna base are targeting each others' planets with the 400 Gm dish, then even at the maximum separation between Kerbin and Duna (35 Gm) the cone will have a radius of only 1500 km (dropping to 265 km at closest approach). If your Kerbin satellite is in a 12,000 km orbit, it will be outside the Duna base's cone most of the time. For the Duna satellite, I've got nothing. That one should work if, as you say, the Duna satellite is low enough to always be in the Kerbin satellite's cone. Just to double-check, what kind of orbit is that satellite in?

Custom Asteroids 0.2.0 has now been released. This is a complete rework of the configuration system to make it both more powerful and more flexible. Please let me know how the new format works for you, so that I know whether to keep it for version 1.0. Changes: Stock configs now have many more minor planet groups Custom Asteroids will now scan the KSP install for asteroid configuration files. This should make it easier to personalize asteroid sets without conflicting with the mod install. Completely new configuration file format. The new format makes much smarter use of default settings, and the distributions assumed for each orbital element are no longer hardcoded. Custom Asteroids can now control all six orbital elements. Orbit size can be set by constraining semimajor axis, periapsis, or apoapsis. Orbit phase can be set by constraining mean anomaly or mean longitude. These two options give configuration-writers more control over where asteroids will and won't appear. Added units to config file documentation Reorganized code to support asteroid modifications other than orbits in future releases.

Low-resolution altimetry is always grey. To warn you that it's low-resolution, I presume.

Bug report: when transferring a crew member using Ship Manifest, TAC life support resources get added (not moved, but duplicated) to the part the crew member entered, eventually filling the entire ship. No other resources (e.g. fuel) are affected. Haven't tried to see how reproducible it is yet, but I strongly suspect it's because TAC mistakes the transfer for an EVA... EDIT: the following steps do not reproduce the bug: 1. Create a vessel consisting of one Mk 1-2 pod and one Hitchhiker container 2. Tweak the stored resource values so that the tanks are no longer full 3. Go to the launch pad 4. Use ship manifest to move from the command pod to the hitchhiker While resources get moved around with the kerbals, the total amount in the ship remains fixed. Will keep trying...

You want [noparse] [/noparse]. Scroll down to the bottom of the page where it says "BB code is On", and click the link to get a full list of BB code commands.

You can right-click on the burn in the queue (opened by ">>", if you haven't done so). But yes, it's subject to signal delay, so odds are the damage is already done. Without figuring out what's causing the bug, I can't really tell you how to avoid it. Suggest posting an issue on GitHub (link in the first post), together with your save file, output_log.txt, screenshot, etc.

Hitting enter in the burn length box is equivalent to clicking burn, so don't do it until you're ready.