Crater

A good rule of thumb is that your payload should be about 10% of the total mass of your launch vehicle. In other words, if you build the payload first, you can expect to have to have to "put a naught on the end" of the mass before you launch. Or, if you build a lifter, you can expect it to put about a tenth of its own mass into orbit as a payload. In the real world, the figures are more like 5% mass for a typical launch payload. In KSP, you can sometimes push it quite a bit further, especially with jet engines. But for a rocket, 10% is a reasonable ball-park figure.

AlexMoon's Launch Window Calculator at http://alexmoon.github.io/ksp/ is very useful for this kind of thing. If you tell it where you're going from and to, it'll tell you when to do, and how much it'll take to get there. As was mentioned above, Moho is the most difficult target, with Eeloo second. You'll need somewhere over 10,000 delta-V for a round trip to Moho. Also, Mechjeb 2.0.9 works fine with 0.21 and still has the VAB delta-V calculator, which seems to give pretty accurate results from what I've used it for. Edit : for the Moho trip, you can only aerobrake for the kerbin return insertion, which at best will save you less than 2k delta-V, so you're still going to need upwards of 8k. Oh..... are you bringing the lander back, or are you leaving it there? Dropping 100t off at the target will give you a lot more delta-V from your fuel load on the way back.

Thanks all. Good to know I wasn't missing anything obvious

Just the direction matters, not the location. You can also use a docking port, if that's any easier, or an inline probe body in one of the stacks. Just make sure that you click it and select "control from here" before you launch.

I have a feature request for you: Would it be possible to have an alternative UI for this based on right-clicking on the actual tanks on your vessel? I know that you already use the flow lock on the tank to represent any tanks that you lock in TAC, and I was wondering if you could also have UI lines on the menus for the parts for IN and OUT for each resource type in the tank (or even just for every resource on it at once). I assume that you'd need a module attached to the tank for this to work, but I see in your TAC Life Support thread that you're using a dynamic module installer to add such things on the fly to any parts that need them Personally, I use this mod a LOT at fuel depots, and it would be far simpler to click on the big stock tank that is currently being drained and click "OUT" whenever a ship docks, locking them once they're empty, than to open the GUI, identify which of the many tanks it is, and do it from there. The other potential benefit would be that if there was a module, it should be possible for each tank to save its state into the persistence file, meaning that if you did have stock-tanks with "out" set, then as soon as you docked, your vessel would start to refuel automatically. (Awesome mod, by the way, I'd be totally lost without it)

It relates to how much ore is there. The darker the colour, the richer the vein (or the lighter, can't remember which)

Personally, I'd be lost without it! I used to have a perl script that parsed all the parts and edited/inserted the various modules I wanted, but it was a pain to maintain, and constantly needed tweaking as things changed (I first wrote it against 0.17 part files). Now I just have a handful of rules for your excellent MM extension, and I don't need to worry And when an update to a mod arrives, I just drop it into place, knowing that my deltas will happily apply themselves! Thank you.

I have a question on interplanetary transfers, the Oberth effect, and refueling stations. Conventional wisdom for an interplanetary burn is ALWAYS ALWAYS do it at low altitude so you're moving faster, so you get maximum benefit from the Oberth effect. All things being equal, it will always be more efficient to start at e.g. 70 km altitude than it would be to burn up to, say, 1000 km altitude, circularize, and then burn from there. But... what about if you are refueling at 1000 km. In that case, what happens? So, using AlexMoon's excellent calculator, at http://alexmoon.github.io/ksp/ , I find that to get from Kerbin to Duna Starting at 70 km requires about 1714 m/s of delta-V Starting at 1000 km requires 1433 m/s of delta-V So, surely, if I started off from 1000 km with full fuel tanks (due to refueling at a station there), then surely I would still have almost 300 more delta-V when I got to Duna than if I had started at 70 km and taken advantage of the Oberth effect? I know that it is, overall, less fuel efficient, since it would take me more than 300 m/s of delta-V to circularize the 1000 km orbit from the 70 km one. But if I'm refueling, that doesn't matter. It only matters how much I have in the tanks at Duna, or how big a tank I need in order to get to Duna. So, am I missing something, or is it actually the case that the stock answer of always start low is only applicable if you are not refueling on the way?

I can confirm that the second variant works fine for me. I use it to add MJ, Protractor, and other stuff to command pods, e.g. @PART[*]:HAS[@MODULE[ModuleCommand],!MODULE[MechJebCore]] { MODULE { name = MechJebCore } } And it does exactly what I would expect. @CreationME: take a look in the KSP.log file. There is a section in there where it tells you what rules and which parts it is matching and applying. Also, try your rule to just patch the new module onto a single part, by name, and see if it works for that one. Edit: lol, you posted while I was typing

"Up" is the direction that the currently selected "Control from here" capsule is pointing. In other words, no, if you have a cabin poining sideways, or a mechjeb pointing sideways, then Mechjeb will try to aim that "up", and leave your engines sticking out sideways, then wonder why they don't push it in the correct direction.

For the command pods, remove any of the following rotPower = ... linPower = ... Kp = ... Kd = ... and any module with name=AdvSASModule Then make sure that they have (still only the command pods) MODULE { name = ModuleSAS } MODULE { name = ModuleReactionWheel PitchTorque = 15 YawTorque = 15 RollTorque = 15 RESOURCE { name = ElectricCharge rate = 1.5 } } where the three torque values are appropriate to the module size (5 for tiny, 15 for a 3man pod, maybe more for anything bigger), and the electric charge rate is 1/10 of each torque.

It is based on the mass of the rocket that you're trying to build - you need the same mass of RocketParts to build it, which now that the density of RocketParts has been reduced to a more realistic value, is LOTS. That looks about right. Spot on. That would be the line in the config file for the lauchpad that says "debug = true". It is switched on by default in the current version of the addon for that launchpad - you'll need to edit the GameData\Extraplanetary Launchpads\Parts\launchpad2\part.cfg file to remove it. (line 96) Yup, the new launchpad is a two-man command pod, though it does have probe-autonomous functions if needed, so you can decrew it before launch if you want to fly it unmanned.

Kind of - there is an extension to ModuleManager that allows the use of wildcards. http://forum.kerbalspaceprogram.com/showthread.php/41616-Extension-for-ModuleManager-with-wildcard-and-conditional-v0-2-24-july-2013?highlight=modulemanager+wildcard With that, you could specify "all parts", or "everything with a command pod" or "every fuel tank that doesn't have RCS" It is seriously powerful.

Also remove the old SAS/asas code and add the new ones to the pods. Same applies to the mk2, Jool heavy lifter, nautilus, and probably other of Bobcat's awesome creations, though I have only tested these.

Just a thought, but could you arrange the sleep stations such that there were two horizontal ones using each of the outer viewports, with the center one used for the conference table? so that each kerbal had his feet by a module end-hatch, and his head pointing to the center of the module? I know is is a big change to the internal, but it would mean that we could keep the lined up windows (which look WAY better), and still have horizontal sleeping, so our poor abused guys can still get a good night's sleep when they're in a surface base.

I'm pretty sure that you're not allowed to distribute Kethane parts, modded or otherwise.

The orbital attachment issue sounds a lot like an issue that has been around since... oh 0.17 at least, with or without KAS. Sometimes when you EVA a Kerbal from one vessel, and try to interact with another vessel, e.g. board it, bump it, whatever, the game would react like the vessel wasn't quite where the screen showed it to be. Sometimes you could even float through another ship, other times, you were just bouncing off the wrong part. Could you try going back to the space center and reloading back into the scene, and see if that allows your EVA Kerbal to attach the object?

Other options for pads include http://kerbalspaceprogram.com/hl-portable-runways-and-landing-pads/ and http://kerbalspaceprogram.com/spherical-launchpads/

There is a fixed version of the Auger in post #711 - http://forum.kerbalspaceprogram.com/showthread.php/35217-0-21-1-Extraplanetary-Launchpads-v2-1-patch-0-21-support-Debris-Recycling?p=556884&viewfull=1#post556884

Uhhh, so the difference between SAS and ASAS is that neither of them are probe bodies? Probes or command pods are a very different beast. This discussion is about SAS/ASAS parts, and how they impact on the new since 0.21 mechanics.

LF+OX is a bad example to use, since the conversion efficiency is about 1, with either converter. If you're talking monoprop instead, then the small converter has an efficiency of 0.3, so you're talking about 3.3t lifted to get 1t of monoprop. If you're after xenon, then the large converter has an efficiency of .25, so you're lifting 4t to get 1t. Like you say, it is down to play style. Personally, I have a base on the Mun with conversion facilities, and I also lift raw Kethane to orbit and stock my Munar station with it. But the question I was originally answering was "what is the most efficient", not "what is fun / what is simple / what do others do". So I explained the maths behind the relative efficiencies.

Most likely, the descriptions haven't been updated along with the actual part functions. And maybe Jeb left his lunchbox in the ASAS unit? could that explain the extra mass?

Short answer: as of v0.21 NOTHING The long convoluted answers above about asas using every control authority mechanism available, and sas just being a reaction wheel were correct through KSP version 0.20, but are obsolete as of KSP version 0.21. Now, as stated by DMagic if your vessel has one or more SAS-computers (which are in pretty much all the pods and probe cores), then it has access to ALL the attitude control systems on the vessel. The reason that there are still two parts not one, for SAS and ASAS is simply so as not to break all the old .craft files that had the parts on them. If you look in the config files for all of the stock SAS and ASAS parts, you will find that they have MODULE { name = ModuleReactionWheel } and MODULE { name = ModuleSAS } meaning that they give control, and have torque. The only differences are in the total torque they deliver. Nothing else. Not any more.

The small kethane tank has a drymass 0.25 and holds 1000 units of kethane, totaling 2.25t The small fuel tank has a drymass 0.25 and holds 400 units of fuel+ox, totaling 2.25t 1000u of kethane is approximately 400u of fuel after conversion The only part that matters is the conversion efficiency. If you are using a large converter for lf+ox, you should convert in space as it creates 1.007 tons of fuel per ton of kethane. For any other fuel, or for anything done with the small converter, you lose mass in the conversion process, so you should convert before shipping.

correct, so if you want a ton of fuel in space, it doesn't matter whether you ship a ton of lf+ox @ density=0.005 = 200 units, or a ton of kethane @density=0.002 = 500 units, either way, you're dragging a ton of mass into space, with the associated thrust and fuel costs. so like I said, the fact that kethane has a lower density doesn't help you get it to orbit.