Starman4308

Your analysis excludes one very important factor: the drag of the nosecone. The nature of the weighted average is such that your overall drag force is proportional to the sum of (part mass * part Cd): even if Cd gets magically redistributed by a weighted average, you're still adding a part whose mass will increase overall drag. By adding a nosecone, you add to both total mass and total drag, and definitely lose on overall efficiency. EDIT: In terms of your example, drag without nosecone would be ((36 + 3) * 0.2) * k, for a total drag force of 7.8 k (where k is a function of velocity). Drag coefficient with the nosecone is, as you calculated, 0.19898...: as such, total drag is ((36 + 3 + 0.4) * 0.199) * k for a total of 7.84 * k In short, you get less drag per mass, but due to the addition of mass, you have more total drag.

I will confirm that that guide is the best one I've seen for new players. The primary thing I would add is that Center of Lift is also known as Center of Pressure, and also happens to be Center of Drag*. *This explains why CoP behind center of mass gives you stability: just imagine fixing center of mass, and a force trying to push CoP/CoD backwards. If CoD is already behind CoM, that force stabilizes your aircraft: it'll try to keep CoD where it already is. Put CoD in front of CoM, and you'll have a wild ride of trying to keep your plane stable.

It's not "too early vs. too late". Gravity turns in FAR are extremely early, they just have to be handled right. You can find my typical advice for FAR ascents here. In terms of what I have been doing: a lot of silly things for Renegotiator, like figuring out how much dV is required to get to a heliostationary orbit in stock. I may have been at one point just a little bit 52 km/s off...

EDIT MODERATOR'S NOTE: This thread is cut from another, since the discussion is becoming off topic from the user's request for help. Cheers, ~Claw Maybe it's because I haven't built many planes yet, but I've never really had a problem with FAR vs. NEAR, and FAR does make some things easier (for example, more gentle reentries). The single biggest piece of advice I can give is to forget everything you learned about how to get to LKO. Using FAR/NEAR, what you do instead is design for 1.2-1.6 TWR (I strongly recommend 1.2-1.4 unless you are using short-duration SRBs), and make sure you have fins at the bottom (to pull center of lift/pressure/drag behind center of mass). You then begin a true gravity turn: at 60-100 m/s, make a 2-5 degree turn (earlier and steeper for high TWR rockets), wait for your prograde vector to catch up, and then ride that prograde vector all the way through to upper atmosphere. Once you're at 20-30 km altitude, you can begin to have your own ideas about where to point your rocket, but until then, aerodynamics will screw you if you try to deviate from prograde by more than ~5 degrees*. *Under 5 degrees, though, aerodynamics (if your rocket has fins) will tend to pull your rocket back to prograde. Thus, if you nailed the 2-5 degree turn at exactly the right moment, you can literally go "Look Ma, no hands!" all the way up. The primary factors behind this all. #1: FAR removes the souposphere, and you as such have much less atmospheric drag. #2: With proper fin placement, aerodynamic stability will return you to prograde if you stay close to prograde. #3: Regardless of fin placement, moving far from prograde in low atmosphere is a quick way to flip out. #4: A consequence of #1-3: you've got to start your turn early, because otherwise you will waste a lot of dV going straight up, because you'll be unable to turn horizontal until very high atmosphere. #5: Another consequence: you can generally get away with a lot less TWR than in stock, because you're not losing nearly as much to atmo drag. #6: Build for 1.2-1.6 TWR (probably best in the 1.2-1.4 range), have fins at the bottom, and turn 2-5 degrees at 60-100 m/s. #7: You will probably want to use KIDS (KSP Isp Difficulty Scaler) or some RSS config, because your dV to orbit will shrink drastically and make your LKO boosters seem laughably small. I personally use 6.4x RSS and RealFuels with the stockalike config. *From personal experience of building many 1.6 TWR rockets: not worth it. You will struggle and curse to get your velocity vector closer to horizontal. EDIT: Also, fairings. You'll need them for anything except already-aerodynamic payloads: I tend to remove fairings around 45km altitude, but I'm really not sure where the crossover point is. There will be some point at which the reduced atmo drag is no longer worth carrying the mass of the fairings.

Maybe it's because I haven't built many planes yet, but I've never really had a problem with FAR vs. NEAR, and FAR does make some things easier (for example, more gentle reentries). The single biggest piece of advice I can give is to forget everything you learned about how to get to LKO. Using FAR/NEAR, what you do instead is design for 1.2-1.6 TWR (I strongly recommend 1.2-1.4 unless you are using short-duration SRBs), and make sure you have fins at the bottom (to pull center of lift/pressure/drag behind center of mass). You then begin a true gravity turn: at 60-100 m/s, make a 2-5 degree turn (earlier and steeper for high TWR rockets), wait for your prograde vector to catch up, and then ride that prograde vector all the way through to upper atmosphere. Once you're at 20-30 km altitude, you can begin to have your own ideas about where to point your rocket, but until then, aerodynamics will screw you if you try to deviate from prograde by more than ~5 degrees*. *Under 5 degrees, though, aerodynamics (if your rocket has fins) will tend to pull your rocket back to prograde. Thus, if you nailed the 2-5 degree turn at exactly the right moment, you can literally go "Look Ma, no hands!" all the way up. The primary factors behind this all. #1: FAR removes the souposphere, and you as such have much less atmospheric drag. #2: With proper fin placement, aerodynamic stability will return you to prograde if you stay close to prograde. #3: Regardless of fin placement, moving far from prograde in low atmosphere is a quick way to flip out. #4: A consequence of #1-3: you've got to start your turn early, because otherwise you will waste a lot of dV going straight up, because you'll be unable to turn horizontal until very high atmosphere. #5: Another consequence: you can generally get away with a lot less TWR than in stock, because you're not losing nearly as much to atmo drag. #6: Build for 1.2-1.6 TWR (probably best in the 1.2-1.4 range), have fins at the bottom, and turn 2-5 degrees at 60-100 m/s. #7: You will probably want to use KIDS (KSP Isp Difficulty Scaler) or some RSS config, because your dV to orbit will shrink drastically and make your LKO boosters seem laughably small. I personally use 6.4x RSS and RealFuels with the stockalike config. *From personal experience of building many 1.6 TWR rockets: not worth it. You will struggle and curse to get your velocity vector closer to horizontal. EDIT: Also, fairings. You'll need them for anything except already-aerodynamic payloads: I tend to remove fairings around 45km altitude, but I'm really not sure where the crossover point is. There will be some point at which the reduced atmo drag is no longer worth carrying the mass of the fairings.

You look in your Kerbal Space Program/GameData folder. If you have mods installed elsewhere, you messed up installtion.

Yep! It's a little more manual, and there's no magic "auto fill to exactly the right mix" button, but you can manually edit resource volumes in the tank GUI, up to a total of the tank volume. What you might try doing is making a dummy "engine" (or fuel configuration for an existing engine) which happens to consume your various resources in exactly the right proportions, and use that to auto-fill your tanks. EDIT: Uh, unless you mean mixing cryo/service module types. You might want to define your own tank type in this case. Go to RealFuels/Resources/RealTankTypes.cfg, copy the cryogenic tank type (that'll get the cryogenic rates right), give it a new name, your desired basemass, and any resources you may want. Not sure how to incorporate TAC:LS resources yet.

Squad can't fix what Unity (the underlying game engine) broke. Squad can only wait for Unity 5, which will hopefully fix the x64 instabilities present in the current version of Unity. In the meantime, do your best to reduce RAM usage or play on Linux.

What you're probably seeing is part duplication. Mod-click (alt-click for Windows, right-shift-click for Linux, I forget for Mac) when mousing over a part, and you can duplicate the part and any parts attached to it. As to saving a craft in sub assemblies, you just click a section of your craft and move it into the sub-assembly saving section. This section cannot include the root part (the first part placed). You must build your craft from a dummy root: the SelectRoot mod can help you change over to a dummy root if you've already built a craft. Notice the fuel tank (and engine) I am dropping into the box at the lower-left.

My gut instinct is that you might shave a few m/s off with a very perfect ascent which goes straight from the launchpad to rendezvous without bothering to circularize into a parking orbit first. It's unlikely to save dV in practice, though, because unless you're a robot, you'd have to correct your course a bit, whereas with the circularize-first approach, you can make very accurate maneuver nodes and spend basically all of your dV on going towards the rendezvous. The important things, as I see them: #1: Launching into the correct orbital plane. The closer you are, the less dV you have to spend on inclination changes in orbit. #2: Correcting remaining inclination changes in high orbit when practical. #3: Performing your Hohmann transfer from low orbit, where you can best take advantage of the Oberth effect. #4: Nailing the rendezvous distance as closely as possible, and not accidentally over-burning when matching velocities. EDIT: Ninjas. Ninjas everywhere. Also, while I use MJ, I've never used it's auto-rendezvous option: I've used it to set up inclination match, Hohmann transfer, and velocity match maneuvers, but never went to full autopilot.

1. No, it's just the simplest, easiest, and laziest way to do it manually. While using MechJeb is even lazier, I still recommend watching it go once or twice, because it'll do a reasonably good turn, and helps show you how to do it right. 2. The technical term is "pitch profile"*. And yes, TWR profile very strongly affects how you pull your ascent, either in stock or FAR/NEAR. If, for example, you have a low TWR second stage, you need to get more upwards kick on the first stage: if you have a high TWR second stage, you can go more horizontal on your first stage. This assumes the presence of atmosphere: if there is no atmosphere, the only​ reason to go up is to not crash into terrain. 3. It depends on the rocket, particularly as I use FAR/NEAR, which is really sensitive to TWR profile. In stock, I usually start tipping over at 7 km, and gradually work my way to 10-20 degrees on the way up, doing my best to imitate what I've seen MechJeb do. *Technically, a true gravity turn requires realistic aerodynamics, because a true gravity turn is "make one slight adjustment close to the ground, abuse aerodynamics to keep it on course all the way up". That only works with FAR/NEAR.

Those are the standard guidelines for Kerbin ascents, correct? He doesn't need something optimized for Kerbin ascent: he needs something optimized for a Duna round-trip, one which is capable of just barely waddling to orbit before tanking up on LF/O for the interplanetary portion. In that case, he'd probably want fewer turbojets, fewer intakes, more wings, and as much LF/O as he can possibly cram on there. It's probably possible to make something which can do both reasonably well, but I would still emphasize making a Duna spaceplane instead of an LKO spaceplane, and refueling from a separate SSTO in orbit. Also, I'd advise against including Basic Jets at all: they're basically worthless for anything other than low-atmosphere, low-speed maneuvers.

Silly, uninformed opinions on how we could move Pallas. Don't forget a whole bunch of people sitting under the impact site, because if they're going to die, they might as well go out with a bang. I know I'd be tempted.

Because the code is a complete mess with special-case handling everywhere for struts and fuel lines, and by creating a standardized class to handle both of these part types, they make it much easier to add other types of parts with similar behavior, and to debug if something goes wrong. As to your general worry about save-game breaking: it probably won't happen, and it's kind of what you get when you buy a game which is still in development. If this happened for the release version, you might have a point, but for now, you pretty much have to live with the possibility that any patch may break everything. If you really want to be sure, just copy your Kerbal Space Program folder, and you'll have a 0.25 version you can go back to. I know I'll be starting over in 0.90.

Unlikely. As mentioned, in KSP, fuel is cheap: you can use a huge amount of fuel for an SSTO and still come out with a big profit. In real life, fuel is even cheaper: Elon Musk estimated that fuel accounts for ~0.3% of launch costs.

There were confounding factors for the Space Shuttle, like the extraordinarily poor decision to make a manned vehicle with no launch escape system, thus requiring incredibly expensive inspections prior to each launch.

It won't. Stable x64 will come (hopefully) when Unity 5 comes. I don't see Unity 5 in the 0.90 patch notes, and I'm pretty sure Squad would make a giant banner with fireworks all around for their Unity 5 patch. Also, I'm a bit surprised there was a need for an upsized launch clamp. I tested launch clamps once, and no matter what sort of crazy rocket I put on there (at one point, a couple dozen KW Griffon Century engines), I couldn't get them to break, either by weighing them down or trying to launch from them.

Only if they're recovered. If they're not recovered, MSTOs are more cost-efficient, because they use less mass to get to orbit. And that's the rub: SSTO rockets are very impractical to recover (any heat shielding would basically eliminate their remaining payload), and Skylon is the first SSTO spaceplane that might work with something approaching an economic payload.

Like almost everything with ascent, the answer is "it depends". Delta-V favors shedding every kilogram of mass as soon as you possibly can. However, a higher TWR lets you get to orbit with less fuel/dV wasted to atmo/gravity*. The mass/cost-optimal solution will thus be a matter of trial-and-error, trying to find the right amount of engine (and how best to arrange engines/tanks) to get you to orbit with the lowest cost or mass. The more engine, the less dV is wasted, but the less engine, the more dV you have to start with. *Within certain constraints, such as vertical ascents staying at or below terminal velocity. In practice, you try to start with a TWR around 1.6-2.0, with upper stages starting at 0.8-1.0 TWR, but these are more suggestions than hard-and-fast rules.

You might try launching into a parking orbit, and then use KSP TOT to design a mission to go from your parking orbit to your destination orbit.

So you have a nuke powerful enough to redirect what amounts to a planetoid, massing 2.11*10^20 kg? Come on, at least try to run some basic numbers first. Tsar Bomba would barely even scratch the thing. The entire world's nuclear arsenal would barely scratch it. Mighty Pallas laughs at your puny mortal efforts to move it.

Every real-world mission planner ever says "hi". Either give broader tolerances in your mission planning, or launch early into a parking orbit, allotting time and OMS fuel to tweak your orbit to be in the right place for your planned maneuver. The Space Shuttles never launched directly to an ISS rendezvous: they would always evaluate the orbit the Shuttle got to, and then plan ISS rendezvous from there. EDIT: For reference, the Falcon 9 manual says +/- 10 km accuracy for LEO perigee/apogee.

Two possibilities spring to mind, because you're clearly not on a hyperbolic trajectory. #1, you need to clear out a prior maneuver node. #2, you're trying to use it to transfer to the Mun or Minmus. You need to do a Hohmann transfer for that*. Planetary transfer is between two bodies orbiting a third body (Kerbin and Duna, orbiting the Sun, or Tylo and Laythe orbiting Jool, etc). *Or something like a bielliptic, etc, but Hohmann transfers are what's programmed into MechJeb.

A, that technology is very implausible. We aren't even close to von Neumann machines, there's no reason to try "3D printer" when all you would need is a coat, and it'd probably be more practical to have a factory converting regolith to reflective material (then spread by robots) anyways. B, Pallas is simply not large enough to be its own solar sail by at least an order of magnitude. The square cube law works against you for trying to move large objects: you would need absolutely colossal solar sails to move Pallas, much larger in area than Pallas itself. EDIT: This raises interesting questions on how one would support such a solar sail. You might need something which looks more like a space elevator than a tower.

It's been completely merged into Realism Overhaul. If you want Real Engines, you install RO.