Starman4308

Mechjeb for certain. Probably also Kerbal Engineer and Vessel Orbital Information Display.

I think you're overestimating how shallow that is. While I haven't been playing with SSTOs much, I've had capsule reentries with a periapsis of 50km, taking 3/4 of an orbit to set down on Kerbin. Wanderfound's advice is to set AoA to 14-20 degrees: his first goal is to re-establish aerodynamic lift and kill downwards velocity. A 0 degree AoA means negligible drag: you are basically darting straight into low atmosphere. A 90 degree AoA means you are slamming into atmosphere like a brick, killing velocity too quickly and leading to instantaneous stall and aerodynamic failure when you start getting down into atmosphere. A 14-20 degree AoA means moderate drag, and lets you get aerodynamic lift from the moment you hit atmosphere. Too low AoA: you dart into atmosphere. Too high AoA: you are basically a stalled-out brick on ballistic reentry. Just right AoA: You are a space plane​. EDIT: For future reference, I was not suggesting 50 km reentry. I was suggesting that 30km was not "super-shallow": 30km is around the upper limit of what I'd do, but I'm overcautious about reentries anyways. If I wanted an accurate stock capsule reentry, I'd probably aim for 40-45km periapsis.

Almost always 100%. If you ever use less than 100% until the final stages of ascent/circularization, you have either failed to optimize your design, or you messed up your gravity turn/pitch profile. Either option is failure.

I think the major point here is that Crayola would care if it's something which would hurt its business. What you posted does not hurt Crayola's business, and probably helps them (at the very least due to the sale of those crayons). In a similar fashion, modders care when somebody does something which causes excess bug reports to land on their laps. I suspect many of these modders would be happy if somebody added features to their mods, stuff like replacing all 30 TAC life support canisters with two size-tweakable canisters. The only thing they can possibly expect to get out of this is more x64 bug reports. Hopefully it's not many x64 bug reports, but I see why the modders are pessimistic about this.

"Moar delta-V" is a cheesy definition of "harder". For that matter, for large rockets, it might be easier with stock, because you can get away with cheesy asparagus-staged pancake rockets, whereas FAR will be most unhappy if you try that. FAR makes you worry about rockets too: they have to be aerodynamic, you can't bank too hard, and for optimal ascent, you also have to worry about body lift. *Particularly noticeable if you're using RSS: you would still pay only ~1.5 km/s souposphere penalty, so your to-orbit delta-V would go from ~10 km/s to ~11.5 km/s.

Not possible in stock: a Mun-synchronous orbit is outside the Mun's SOI. I'm uncertain about RSS. There's a WIP mod to do N-body physics, but that might be a little much to download just for Lagrangian points.

Well, I suppose if you count slightly higher delta-V requirements and tedious ascents as being "difficult", you could, but I much prefer the difficulty inherent in pulling off a proper gravity turn and flying an aircraft with real aerodynamics instead of a souposphere.

Desktop is definitely the way to go for gaming. It's much easier to get components and custom-build, the selection for pre-built is better, and the equipment is cheaper, courtesy of not having to be stuffed into a tiny case (this also helps enormously with cooling). The only reason I use a laptop is because I got it as an undergrad, when I kept on shuttling between home and college, and this thing is a monster: 17.3", 7 pounds, and cost me the equivalent of £750. I will be replacing this thing with a desktop now that I've settled into grad school. That was with the advantage of being in the States, where Sager does most of its business: most other gaming laptop outfits will charge you more, or do the usual stupid stuff* to pad the price. *Sell you a giant processor with no GPU or SSD, etc. Gaming laptops also make terrible everyday laptops: they are usually big, heavy, and power-hungry beasts. There are things you can do to increase the range of power consumption, but at the end of the day, a gaming CPU is going to take more power at minimum draw than a more conservative chip, and either you have to fiddle with switchable graphics* or deal with having a power-hungry gaming GPU running 24/7. *If you do go this route, the best technology I've seen is NVIDIA's Optimus technology, which can dynamically switch from the processor-onboard chip to the gaming GPU when you need it. It accomplishes this by having the screen always read from the onboard chip, and when the GPU is on, it simply dumps the screen output into the onboard chip. It isn't terribly compatible with Linux; the Bumblebee package tries its best, but it is problematic. EDIT: Sorry about giving no specific recommendations for desktops, but as mentioned, I live in the States, and I'm not sure what the good outlets are for shopping in Great Britain.

It's because, unlike in stock, where low ascent is limited by the souposphere and you design to hit terminal velocity, in FAR/NEAR, you are limited by your rocket experiencing an unplanned departure from controlled flight regime, rapid unplanned disassembly, and high-speed lithobraking. In order to keep your rocket under control in low atmosphere, you've got to limit your launch TWR. Also, because aero drag is so low, you build up speed a lot faster than in stock, even with much lower TWR, reducing gravity losses.

Or moar reaction wheels/RCS. But since most engines are gimballed anyways (with the notable exceptions of the aerospike, the LV-T30, the PB-ION, and a few of the really dinky engines), just use those.

Thine answers lie here. I'd plug in your initial transfer, and use the arrival date as the earliest departure date for the return trip. There's also a version for 6.4x Kerbin, and probably ones for Real Solar System and 10x Kerbin. Launch windows are dictated by the synodic period, which is the amount of time for two planets to return to the same angle relative to each other; for Duna, I think the synodic period is ~800 days, so it roughly repeats every 800 days*. *There are small differences due to Duna's eccentric, inclined orbit.

0i, duh. When should I deploy parachutes for a Mun landing?

Sane Strategies makes the funds<->science conversion less stupid, I am amazed that RSS/FAR/DRE/RF isn't enough for you, and you can use the Kerbal Isp Difficulty Slider to make your engines weaker. You might also try Engine Ignitor, though it does not play well with Real Fuels and large rockets.

The thing is that Mechjeb is really terrible at docking and wastes loads of monopropellant. I was encouraging ​you to fly it manually; I use Mechjeb, but not for docking.

See this post for detailed instructions. The most common trip-ups with RealChute: #1: 64-bit Windows. Chris got fed up with x64 support requests (because for some people, including Chris, Windows x64 is an unstable piece of crap), and disabled his mod for Windows x64. Linux x64 works perfectly well. Use 32-bit, use Linux 64-bit, or eliminate the check from the source code and recompile*. #2: The stock parachute configuration file (in RealChute/Module Manager) causes major issues: either delete the config, or never use stock parachutes. #3: Wait until 200-250 m/s to deploy your parachutes if using Deadly Reentry. Supersonic speeds eat parachutes, and the speed of sound is ~330-350 m/s. *It basically means reprogramming his mod yourself to eliminate the x64 check. Also, if you go this route, just be aware that Chris won't lift a finger to fix bugs for you: you recompile at your own risk with no expectation of support.

See comments regarding the Sr. docking port. Also, a 1-man pod plus a couple Rockomax adapters would weigh less than the 2-man pod. I suppose if standardized designs are your cup of tea, but you will save enormous amounts of mass and money by making more specialized designs with only as much as they need. I suppose it comes down to playstyle; I don't mind spending six hours designing and optimizing a simple unmanned Duna/Ike land-and-return mission (and I still am not done, courtesy of the unforgiving nature of 6.4x Kerbin dV). While the aesthetics are annoying, you can either stick a small probe core in between two stacks and strut the stacks together, or use a radial attachment port to slap on an OTKO2. Do be aware this would make the probe core face sideways, so you'd want to right-click and control from something pointed vertical. You do realize how blasted heavy those things are, right? They're mostly used for gigantic space stations. Are you using MechJeb for docking? I manually do it using Navyfish's Docking Port Alignment tool: even kinda sloppy, hasty docking maneuvers should use less than 15 m/s in monopropellant. It also helps to have small vehicles which don't need huge amounts of RCS to move. One suggestion: switch to your target, right-click the docking port in question, "control from here", and use Smart ASS (or eyeball the target indicator) to point the docking port to the maneuvering vehicle before killing rotation and switching back. It's also the sheer number of legs you have. It's very excessive. Not that dim. At Jool, you'll be seeing about 50% Kerbin power, and 4 1x6 panels should still be more than enough. The only things which might require more than that are ion engines and science labs; the first often requires RTGs or tons of batteries anyways for night-side operations, and the second can be buffered with a relatively small number of physics-less 400-charge batteries. Cost/mass considerations. A lot of the people here (like me) are optimizers, who try to design the smallest rocket possible to do the mission. Yours has a bunch of wasted mass.

Jool has a "surface", composed mostly of Krakens hungering for your spacecraft. As I understand, you can sometimes dive down below it for a bit, but it's definitely a short, one-way trip. Even if it weren't solid, Jool's powerful gravity well and thick atmosphere would make sufficiently deep dives impossible to return from. EDIT: Unless you infiniglided out. That'd probably work. And I'm sure there are people who've managed to launch from low Jool atmosphere back into orbit with sufficiently gigantic rockets.

Well, Toolbar doesn't do anything by itself: it is just a place for mod buttons to go, and MechJeb won't show itself unless you add either a MechJeb drone core (in command pods) or an AR202 case (under the Control tab) to your craft.

A lot of people, including me, have had great success with RealFuels and the stockalike engine configs. I would recommend FAR to remove the souposphere (it has a learning curve, but does greatly reduce dV requirements), Procedural Fairings to not-die with FAR, Kerbal Engineer Redux or MechJeb to help you construct rockets, RealChutes to give you those wonderful parachutes, and Deadly Reentry and TAC Life Support to round out the realism aspects. I also like KW Rocketry, Modular Rocket Systems, and Zero Point fairings for greater variety of parts. In any case, it's hard to get a single multiplier (Isp, funds rewards, etc) to really balance career for scaled-up Kerbin, because launcher mass has an exponential dependence on delta-V. Thus, if you try to balance it for orbital contracts, atmospheric contracts are giant sacks of money, and it's hard to make a penny for anything outside the Kerbin system.

For the most part, they'll throw up errors on load if they're mis-installed. As for the stock bug fixes, I think those are supposed to be in GameData, not in the sub-folder, but it might work either way. One thing, though: those mods may or may not depend on Module Manager, which is a pretty common add-on to assist in loading mods. If you are having problems, there is a good chance it is due to the absence of Module Manager.

Hey Necrobones, were you aware that you don't seem to be listed in the stickied mod library? Also, thanks for the parts: I am very much anticipating Raptor's configs for RF so I can use those quad-nuclear engines, the cargo bays to put rovers in, and I'm already using the 3.75m-3x2.5m adapter for my current Duna mission*. *There is a certain feeling to be had when, despite doing your level best to minimize weight, your unmanned Duna/Ike sample return mission still requires a 1400t launcher (6.4x Kerbin), right about as much as the Falcon Heavy.

As I understand, the OP wanted "the most efficient way to fly", and simply needed a bit of help in realizing that that is a hypersonic, high-altitude, high-performance aircraft which is a RAPIER and a little oxidizer away from being an SSTO spaceplane.

Until such time as the runway/launchpad durability is fixed*, I only have destructible buildings on for my sandbox, where it is amusing instead of annoying. *I suppose it might be realistic to have launchpads be destroyed by rockets which make the Saturn V look like a lightweight, but it's not fun. I dislike limits on how big I can build stuff.

Began designing an ambitious single-launch unmanned Duna/Ike land-and-return mission for 6.4x Kerbin: I'll get both probes to Duna orbit, separate both landers, do science stuff, return both science payloads to the transfer stage (discarding their engines), and take both home at once. The little Stayputnik cores on the top are just the dummy root nodes, so I can save the rest as a sub-assembly. I'll probably move the parachute off the Ike lander; that was intended to be the Kerbin landing parachute for both payload sections, but since I'm changing which end I'll have the heatshield on, it'll probably be moved to the Duna lander. I was also abruptly reminded of the rocket equation, when it turns out I save ~2-3 tonnes by having a separate Kerbin reentry heatshield on the transfer stage instead of just re-using the Duna heatshield. Part of that mass savings was because, instead of having the heatshield on the top (requiring RCS or reaction wheels to flip the whole lander over before parachute deployment), I now have it on the bottom.

Your payload wasn't 1-2 tons. It was 1-2 tons plus the mass of every empty fuel tank and engine. My guess is that, while you added fuel for the 2t payload, you did not add engines. Depending on what the TWR was, you either had an inefficient 1t launcher (too much engine for the payload), an inefficient 2t launcher (not enough engine for the payload), or both (poor TWR for both). EDIT: Really, this is important: engines and empty fuel tanks are dead weight for the delta-V calculation, so you do your best to minimize them.