Starman4308

That's not what I'm asking for. I know about the margins, and they usually work perfectly well, dropping you out of time warp basically on the dot. What I'm asking for is whether there's an option to make KAC more aggressive about slowing time warp, because I've missed alarms by 45 minutes at high time warp: it's not stepping down quickly enough.

If they're burning up during re-entry, your heatshields are having issues keeping your pod cool. If they're burning up when you deploy them, take a second, contemplate the fact that 330 m/s is the speed of sound, and start deploying your chutes at subsonic velocities (I usually wait for 200-250 m/s at the maximum).

Is there any way to force KAC to start killing time warp sooner? I've been overshooting several alarms, and I suspect it might be because RSS over-writes the default timewarp settings, so KAC takes too long to kill timewarp.

Were you using stock (dinky) planets, though? The delta-V requirements for 6.4x Kerbin are brutal, the delta-V map I use tends to overestimate how much you need, I engineered a healthy safety margin on top of that overestimate, and I was limited to half-Jumbo tanks, the Skipper, and 1.25m engines. Regardless of whether I should have used fewer parts, the deal is that, at least when I have RealFuels going, Engine Ignitor is what is limiting the size of my craft. A single mod should not so badly crimp what you can do in KSP. EDIT: For perspective, in stock, one can engineer a Minmus round-trip mission on ~6.2-6.5 km/s (slightly uncertain on how much dV is required to go from Minmus orbit to Kerbin reentry). In 6.4x Kerbin, even with FAR to remove the souposphere, you need 7.4-7.6 km/s just to reach orbit. I think I built in 14.3 km/s to that mission (calculated 13.5 km/s from the map, added 0.8 km/s safety margin). In theory, that's a rocket 9.67x larger for the same mission (assuming average Isp of 350s). I also double-checked: while my second stage used highly efficient (Isp = 440) hydrogen-liquid oxygen engines, everything else was at 320 Isp (there are problems with LH2: it's not very dense, so the tanks are colossal, and it's subject to boil-off, reducing its utility for engines not used for ascent or initial transfer).

Figured out what was going on with the liquid methane boil-off. #1: I didn't account for the fact that very low Kerbin orbit is warmer: up to about -60 degrees Celsius, enough to boil methane. #2: there are weirdnesses with temperature calculation during time warp: it doesn't properly update, so if start timewarp at very low orbit, the tank/ambient temperature will persist through timewarp, even if most of your orbit is in the -200C zone. Ergo, for now, it should suffice for me to lift up my methane-propelled rockets to the -200C zone, and kill time warp once I'm out of the boiling zone.

Okay, sorry, liquid ammonia propellant is not, for practical purposes, subject to boil-off once you get it to orbit. Also, is sub-boiling evaporation/sublimation modeled? The ambient temperature in LKO is -200C, which should be colder than methane's boiling point (its melting point too, for that matter*), but I did see loss of methane from that tank in LKO. *There's probably somebody who'd get a kick out of having to melt frozen propellants before use.

Hey Nathan, would you mind mentioning on the first page that liquid ammonia is the only non-cryogenic* nuclear fuel? It's kind of an important consideration for interplanetary missions. *Unless a minute of max timewarp isn't enough to see boiloff. But even if there is slow boil-off, it's so slow that it wouldn't matter for 99% of missions.

Given your description, I think the issue is that, for RF, it might be O(M*N*F), including F fuel types to check for. It would very adequately explain why it only happens when RealFuels is installed. Also, given the raw speed of modern CPUs, the game should hardly even notice 23*140 operations/tick; even assuming 100 cycles are needed for each operation and there are 50 ticks/second, that should be only 16 million cycles/second spent on Engine Ignitor. I think the rocket I first found the problem on was my first manned Minmus mission*: because I didn't have the Mainsail yet, I was running clusters of LV-T30s on my bottom stage, which was what was responsible for most of the engines. I also had limited fuel tank size to work with: I think I was limited to the half-Jumbo tanks. Regardless, 20 engines and 100 fuel tanks should be within the realm of sanity for large rockets. *Rocket size also ballooned by taking the delta-V map at its word and engineering a healthy excess onto the rocket: I think my (launched later, completed sooner) Mun mission came back with 1.2 km/s delta-V at the Kerbin reentry. EDIT: If I've got some time over Thanksgiving break, I'll take a look at the source code and see if I get any bright ideas about how to optimize it. The possibility that springs to mind is, on physics load, staging, and docking, generate an array of tanks for each engine to check, so each engine only checks the tanks it's connected to. Would probably need to catch the C# equivalent of NullPointerExceptions (I'm a Java programmer, mostly) for situations like "fuel tank destroyed by bad decoupler physics and heavy SRBs".

Go to the Crew tab in the VAB, and just drag Kerbals into the Hitchhiker. No mods required.

I happen to favor onion. Not the greatest fan of asparagus, though.

Delete them one by one and figure out when it stops breaking. If you don't want to affect your main game, make a copy of your KSP folder (literally ctrl-C ctrl-V), and change mods/run the executable from there.

Well, deal with the demo is that there is only a sandbox mode, with only the Kerbin system, and only a handful of parts. There's not really much you could lose: I suppose if you built a giant Mun colony in the demo, you'd lose that, but otherwise, all you would lose are a handful of rocket designs which you'd probably replace anyways with much greater part selection.

It seems roughly balanced, but by definition, it'll make stuff easier, because there might be a KW Rocketry part which fills a niche better than a stock part. An analogy: if you need a 5x1 Lego piece to connect something, you could stick together a few 2x1 and 3x1 Legos together, but if you have a 5x1 handy, why, use the 5x1. One thing you'll notice with FAR is that, once you figure out how to not explode, ascents require much less delta-V. Regex has a 1.7x Kerbin config somewhere as a "FAR fixer", and if you ever get sick of tiny ascent rockets, I suggest using 6.4x Kerbin, and to help with the increased scale, Real Fuels with the stockalike config (which makes fuel tank/engine weights more in line with reality).

I can tell you the answer already: "hell no". Chris basically stopped maintaining his mod because of somebody who did exactly what you did: an unauthorized x64-enabled fork. Please take down x64-enabled FAR. You did not receive the author's permission, and just because his license lets you do this does not mean you should​ do this.

Optimal TWR is a complicated bag of kittens. During ascent from a body with thick atmosphere, you want a launch TWR of ~1.6-2.0. You want to be ascending at terminal velocity, which would suggest a TWR of slightly > 2 (1 for gravity, 1 for atmosphere, a sliver leftover for acceleration), but a number of factors reduce that. #1: as you burn fuel on your first stage, it's TWR goes up. If it's mostly a solid stage, this is particularly noticeable (look Ma, no throttle!), whereas for liquid stages, it's more subtle: while you can throttle to remain at terminal velocity, the moment you do, you have wasted engine mass: dead weight causing gravity and atmo drag. For the upper stages, TWR depends on how nice a gravity turn you pull. An ideal gravity turn should have initial TWRs declining steadily from 2.0, as the dV cost of engine mass and the decreased need for thrust begin to counteract the need to minimize gravity/aero drag, but that depends on skill and the overall TWR profile.

The lower the TWR on your lander, the more you lose to gravity drag. In the case of Tylo's beastly gravity well, this might become such a concern that one of the conventional 370-390 Isp rocket engines might be more efficient overall, due to the LV-N's poor TWR.

A, as mentioned, are you staging to activate the contract? B, a bunch of Sepratrons firing at liftoff should give you a good kick. C, to some extent, I prefer liquid-fuel engines for these sorts of contracts: you get 100% recovery anyways, and you get to throttle to the appropriate speed instead of praying that you got the amount of fuel and thrust limiter exactly right on your SRB.

The launchpad durability is very, very silly; either hang the whole thing from clamps, or shut off destructible buildings.

Have you deleted the stock parachutes config for RealChute? That is is RealChute/Module Manager; for some reason, having RealChute functionality enabled on stock chutes causes major loading errors. Otherwise, do try narrowing down which mod or mod combination is responsible.

The orbit you should be trying to get to during ascent is Low Kerbin Orbit (LKO): which is roughly 70-90km apoapsis and periapsis. For most purposes, the lower, the better. Once you're in a parking orbit in LKO, you can go anywhere, and courtesy of the Oberth effect, it is often most efficient to start from the tightest orbit you can manage. In order to get there, just pull a gravity turn (a simplistic one is to turn 45 degrees at 10 km; for more sophisticated turns, you might try watching how MechJeb does it), cut your engines you get apoapsis to ~75-80 km*, and make a maneuver node at apoapsis to circularize. It doesn't matter if your periapsis is inside Kerbin during ascent: you will bring that up when you reach apoapsis. *If you're still deep in the soup, you might want to fire a bit more to account for loss of speed to atmospheric drag. Also, the higher the apoapsis, the more forgiving the process is for time to make and execute the node, plus the less chance you might accidentally dip back in the soup during the process.

What I used to do when I was first learning was to have a stack decoupler between my cockpit and the rest of the craft, such that in an emergency, I could separate the cockpit and parachute it down. In any case, these days, I usually recommend this guide to building spaceplanes.

Originally diagnosed on 23 engines and ~140 fuel tanks (6.4x Kerbin, career mode, only 1.25m parts, etc, etc), amply replicated with the above barrel of 77 tanks and 20 engines (LV-909 with an FL-T800 above 19 LV-T30s fed by 4-5 FL-T800s). It seems to scale on both fuel tanks and engines*, though you do need a respectable number of fuel tanks: it also disappears entirely if your engines cease to exist (say, you forgot to turn indestructible buildings off, and your test rocket decided to collapse the launchpad). *Tested quadrupling the fuel tanks on 19 LV-T30s + 19 FL-T800s: it slowed down. Tested adding 30 radial engines to 28 fuel tanks + 7 LV-T30s: it slowed down.

Thanks for the effort. I can always pretend I'm using Engine Ignitor and forbid myself lower-stage restarts in the meantime. Whatever it is, it had a massive effect: rockets which should never have come close to straining my system were slowing it down to 1-2 frames per second.

I did catch that. For any body with a thick atmosphere*, vertical ascent TWR should be 2.0 for that body, and your vehicle seemed a little short. The math which says "terminal velocity is the best speed to ascend vertically on Kerbin" is just as valid on Eve, though trying to shave engine mass at the cost of TWR will be a greater concern for an Eve ascent than a Kerbin ascent. *Duna's atmosphere is so thin that your ascent is more like something from an airless world. Another way to think about it: staying at terminal velocity will require TWR of slightly > 2.0 (1.0 TWR to fight gravity, 1.0 TWR to fight air resistance, a little bit more to accelerate as terminal velocity increases), and the most delta-V efficient ascent is one which remains at terminal velocity throughout. It might not be the most mass/fuel efficient ascent: factors like mass of engines and staging equipment tend to favor less TWR, but in pure delta-V land, you want to stick to terminal velocity.

Fly it a few times, try and figure out its flaws, and design your own. Most of the stock craft were deliberately designed with illustrative flaws. For example, the Kerbal X, while demonstrating asparagus staging, has very tiny asparagus tanks which are depleted very rapidly, leaving you to do most of the ascent on a single engine. It also, before a buff to Rockomax parts, did not have quite enough delta-V for a Mun landing and return mission.