Colonel_Panic

Ah, but you can warp when you have another ship selected, and that can, in my experience, cause the kraken to swallow ultra low orbit ships whole. There's not, but he's just THAT low. I think the highest munar peaks are somewhere between 2km and 3km. Minmus reaches as high as 5-8km.

Don't be surprised if the kraken eats it the next time you timewarp

I'm planning a lot heavier than that... but yeah, will see.

Well the real trick is determining at what mass using LV-Ns becomes feasible, because for lower mass payloads and engines, you can actually get more dv AND more twr just by going lighter... but with a heavy enough lander, the engine weight is less important than thrust and efficiency. EDIT: not sure how accurate that spreadsheet is. I know I've gotten 11k dv out of an orange fuel tank and an LV-N...

Less is more with landings. Lighter craft need less thrust to negate the effects of gravity. Curious why you'd go with an aerospike though, as I'd think the only real benefit would be atmospheric ascent.

Except for the fact that you won't be able to turn the other way, and will need constant correction to stay on course. ASAS won't do a good job of it, and even mechjeb won't be of much help. It'll be a lot of work making it fly at all. I'm not saying it's not doable, just that it would be way more trouble than it's worth as opposed to other solutions.

I routinely use cubit octagonal struts as angled attachment nodes for engines in engine clusters. If you turn on clipping you can even mount them flush with the above tank and hide the hackery. That said angling your shuttle engines is a bad idea here. Sure it will help you get your rocket in space, but then what? Now you have a gimped shuttle with off-center thrust that can't do anything without its ascent booster.

few more tips: RCS will always cause velocity change when using it for rotation. turn it off before making major rotation adjustments or using SAS, unless you have a very heavy ship. use precision controls for docking. Hit capslock to turn them on and your crosshair will turn blue. You can make finer adjustments and save more fuel that way.

I've never had luck with RCS balancer. It always seems to cause even more thrash, wobble and instability, waste fuel faster, and end up being counter-productive. I wouldn't use MJ for fine docking like this. These ships and parts are so small you do better on your own. Line it up visually -close enough- and then turn on precision controls with capslock and do your translation nice and slow and easy. I managed to assemble the entire station using less than 2 round RCS tanks worth of fuel. LOADS to spare, not even counting the RCS fuel pods that come with it.

and the simple answer to that is no I like my autopilot for exactly what it was designed for: removing the tediousness of lengthy, repetitive tasks so I can focus on the more exciting aspects of the game, like fudging up the landing for the fifth time in a row.

I'm not really worried about the dv to reach the planet. I plan to use some clever orbital hackery and gravity assists along with ideal windows to peg the moho transfer with a "minimal" 4000-5000-ish dv, but even that aside the omni-lander is basically going to be a 4-part integrated vessel that can be assembled in orbit, consisting of a main ship (tug), lander module, heavy lander addon, and rover. The mission profile for the vessel will be to transfer to the desired planet via the tug, descend with the lander, heavy lander addon and rover, land, and then return to orbit again (either with the entire thing, or, in the case of places like Tylo or Duna, with just the main lander component, leaving the rest behind, to rendezvous with the tug and return to kerbin and/or another convenient nearby orbital resupply and refit station before going on to the next mission. The tug will be fairly large, probably 2 orange tanks worth of fuel but minimal dry weight (it will have only 2 LV-N engines, which it will augment with the heavy lander addon's own engines to save weight by reducing unused engine mass.) More of what I was wondering about was other requirements, such as, I'd heard moho could pose an overheating problem for engines, etc... are there for example certain engines I have to rule out of using in my lander? For the heavy lander addon I plan to aim for a 6000dv with 1-1.2 TWR (in Kerbin Gs) fully fueled with 50%+ wet weight, so it should be around 1.6-1.7 TWR on landing with half the dv (and therefore about 2/3 the fuel mass) expended. If I can't go that high, I'll probably keep the TWR profile and use the lighter lander core for return to orbit when on tylo. I'm disregarding laythe because I plan to set up an extensive base network there with SSTO spaceplanes, orbital assembly docks, and rovers to take advantage of the oxygenated atmosphere, so I won't need my exploratory lander to set down there on its own. Here's my other question though: disregarding for a moment tylo, what's the -next greatest- minimum TWR required to safely land on a planetoid or rocky body? I basically want to design my lander so that with the heavy lander addon it can land on tylo, but without it I want to conserve engine mass by making it lower TWR for the other bodies. So what kind of minimum number should I aim for, for that? This is pretty in-line with what I plan to do. I don't plan to set it down on laythe though, just tylo. I want to use the heavy lander stage for all landings I can, but to reserve jettisoning it for tylo, or as an emergency contingency under other circumstances. I don't plan to visit Eve with this ship. Doing so would require a special mission profile focused only on the eve landing and ascent (and landing on Eve is indeed very difficult if you're planning to do it with a ship capable of taking off from Eve again..) Furthermore I have no reason to believe that any form of SSTO is possible from Eve. Anything even close to having the TWR and dv necessary would need many stages, and lacking some sort of eve-atmosphere-breathing engine, it's not going to happen.

This sounded fun until the no plugins part. I'm all up for the challenge of designing a plane that can circumnavigate kerbin, but not for the tediousness of actually flying it the whole way around by hand. It could take hours.

If your question is whether it's possible to SSTO a shuttle command pod and return to KSC, the answer is yes. The landing part is both straightforward and tricky. You'll want to have some kind of marker such as a touched down lander at the pad, so you can see KSC from the orbital map while adjusting your re-entry angle to put you about 30km west of it, so you can fly or glide the rest of the way in for a landing. Markers of some kind at the ends of the runway are recommended too so you can see it on approach and line up with it. You want to get it exactly on your 90-degree east vector on the nose, to be lined up and heading in straight for a landing. Then just lower your gear, slow or cut your engines as you get close, and try to make a soft touchdown at low speed. It's easier said than done and requires practice. Even if you use mechjeb he will fudge it up more often than not (although at least his landing predictions can be useful for getting your re-entry in the right ballpark)

Hi, I know Tylo is a very challenging planetoid to land on due to its high gravity and no atmosphere, and so requires a lot of delta v and TWR to land on successfully. Exactly how much is recommended for this, and to reach orbit again? Now for the other part of my question, disregarding eve and laythe which require staging or splaceplanes to ascend, or jool which is just a kraken swamp, are there any other bodies that are particularly difficult to land on and return to orbit again? Assume the challenge of reaching them and entering orbit will be accomplished by a tug or other means... what special considerations would I need for a single-stage lander that can touch down on and return to orbit from every planet and moon in the kerbol system?

It's going to vary from machine to machine, albeit not too much. One thing to note is that docking ports appear to be bugged and contribute to lag more than other types of nodes. If you come within range of an oversized station, you will know it. The game will hang while it loads it up, and then slowly pick back up into bad lag. Fortunately, you have to get very close for this to happen, generally close enough it's not something that happens accidentally. Stations in orbit do not contribute to lag when they're not loaded, as far as I'm aware. If you're unsure, test things first. over-strutting can contribute to this problem, since it's easy to send your part count through the roof that way. It's usually better to attach problems like rocket wobble through better balance and disabling gimballing on outer engines, before you try and attack them with struts. A little flex won't kill you, and most of the time the problem is caused by something other than just not enough struts. This is both true and not. Since KSP is limited to a single physics thread, physics is always the bottleneck when lag arises, and regardless of the processor, graphics, memory, etc... the only thing that will really net you better (and margainally better at that) performance is a higher clock speed or more FLOPs per clock per core. Because of this things like massive 6 and 8 core processors in really serious gaming machines can actually do more poorly in KSP than a simple core 2 duo with a very high clock speed.

I recommend mod manager for mods. The fags question has already been answered. -some- older mods. Most of the ones I use have had issues. Some minor, others not so much.

Better, more direct and kerbal-friendly solution: send up shuttles in pairs, with one on either side of the rocket for balance. The problem you'll face in doing this the canon way is that while a shuttle in real life uses vectored thrust and specific flight characteristics of its engines and tanks to achieve bnoth balance and control, KSP simply isn't designed to make that kind of thing work. Even if you mod the engine gimballing range, KSP won't know what you're trying to do, to balance it out appropriately. The only way to really make it work without excessive hackery, is to design your ship so that the total center of thrust is directly under the total center of mass, AND that both your shuttle and its rocket and tanks have pretty much exactly the same TWR curve on ascent (aka, your total weight on one side needs to drop at the same fractional rate as your weight on the other, while thrust remains constant on each... you can accomplish this by tweaking your engine efficiency and staging, and balancing your wet/dry weights one each side. It's extremely difficult.) Or, you could just launch with a second shuttle to counterbalance the first. P.S., make sure you ascend with your wings knife-edge up and down, or you'll get weird lift problems that will throw your rocket off.

Hmm, correct m if I'm wrong, but any way you slice this problem, aren't you basically going to still reach your destination planet at the same time as if you'd used a hohmann transfer directly? It seems to me the price you pay for an early departure, all delta-v aside, is a longer transit time with more adjustments en-route.

Hi Starkllr, I actually made a tutorial video that covers in great detail exactly this stage of rendezvous. You can see it here: skip ahead a little ways if you already know about configuring your ship for docking and maneuvering.

Gentlemen this is the war room! you can't fight in here!

The same thing. If your keyboard doesn't have an F2 button for some reason, you may have to get one that does. (AFAIK all modern macs have function keys).

Odd, it worked for me, but I just cleared my cache and now it doesn't. To be quite honest my computer can't handle it in orbit either. I get a whopping 3 FPS with the complete station, hence I'm going to do a version with just one dock and maybe just one crew core and power mast too. here, have the full original linked photoset: http://s11.postimg.org/ut95zg9sj/2013_05_28_00004.jpg' alt='2013_05_28_00004.jpg'>

That's the folder you unpack for the plugin.

My new orbital assembly dock needs a name.