Starman4308

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.

I was generally under the impression that basic jets were mostly deadweight on high-performance aircraft: while they are superior for low-speed, low-altitude operations, they become deadweight at hypersonic velocities. Since turbos are almost always enough to get you off the ground and up to altitude, I usually just do straight turbojets (with some RAPIERs for SSTO spaceplanes); the minute amount of fuel saved during the ascent isn't worth lugging those superfluous engines around at the hypersonic regime.

As I see it, your best bet is to burn one vehicle directly towards the other, with only small consideration for orbital mechanics. Orbital mechanics starts to screw "burn straight for it" maneuvers proportional to the fraction of an orbit completed, and you probably have at best 1/4 of an orbit to catch up. The more delta-V you have left, the better: you can make more aggressive, more direct maneuvers, and you don't have the time for efficiency. Assuming you use the trailing vehicle, I imagine your maneuver would be mostly prograde with a bit of radial-in; tweak it to get a good intercept, and don't be afraid of correction burns. Do, of course, ensure you have enough delta-V to cancel relative velocities at the rendezvous: this will have the advantage of putting the rendezvousing craft back on a Kerbin reentry orbit. If you just do not have the delta-V on your two vehicles to manage that, you're going to need to build a delta-V monster capable of meeting the troubled vehicle halfway, and then completely reversing trajectory. What I would do is mark the target's periapsis, and set a maneuver node to match the target orbit, just going the opposite way*. *Make sure you launch in the correct direction for this: you might have to launch west from KSC instead of east.

Had heard about it from XKCD a bit, mentally set it aside for a while, then, when a bit bored, decided to get the demo. I also watched some Scott Manley videos. A bit of explosive decoupling later, and I got hooked.

Been a while since I've flown stock*, but I've heard that, for maximum efficiency, you want one turbojet for every 7.5 tons, and about four ram intakes for each turbojet. *I use FAR these days, which basically means completely replacing every spaceplane and rocket you ever designed to account for its much more realistic aerodynamics.

Will do. Testing with a value of 28 revealed it was way too cautious; testing at a lower value was inconclusive, because the Kraken ate my vessel*, and I think I ran into Master Tao's persistence file bug when I switched to another vessel. Will continue when the fix to that bug is released, so I don't have to re-launch after Kraken attacks. *Vessel collided with the VAB. In high orbit​. I wonder if that's a record for that bug.

As high and fast as you can go without engine flameout: preferably ~2000 m/s at 25-30 km (and yes, that's almost orbital velocity). Once you're at that regime, you should be able to cover huge distances on tiny amounts of fuel. To get there, you're going to want to climb at the fastest rate you can manage to 18-20 km, at which point you should mostly level off and start accelerating horizontally. Be sure to have enough intakes (I think maximum efficiency in stock is 1 ramjet intake per ~2 tons of plane, though that is aesthetically ridiculous), and if you're still running short of intake air, you can dip down a bit to speed up and get to denser air. Don't worry about Isp. Really. Turbojets are so ridiculously efficient that it doesn't really matter. What you should be concerned about is atmospheric drag, and that's minimized by high-altitude flight. EDIT: Essentially, make like an SR-71, if an SR-71 didn't have cooling problems limiting it to Mach 3.4.

The most important thing has held, though: no nuclear weapons in space. ICBM launches are big, noisy, and take 30 minutes to reach the other guy; if one had nuclear weapons in orbit, ready to drop on targets on command, the deployment time goes way down, which decreases the risk of being the first one to deploy atomic weapons. The harder it is to get off an unanswered first volley, the more effective nuclear deterrence is.