maltesh

Strut Configuration: https://dl.dropboxusercontent.com/u/4057920/kerbal%20space%20program/v0.23/screenshots/screenshot313.png Provided vessel appears to be insufficiently strutted, with only a single strut going from each radial booster to the central booster. Attempting to Ascent Autopilot spacecraft as provided results in catastrophic failure soon after launch. Modified configuration: https://dl.dropboxusercontent.com/u/4057920/kerbal%20space%20program/v0.23/screenshots/screenshot315.png Strutting vessel at the bottom of each side booster, and adding launch clamps to the three boosters that don't have them results in a design that can at least be Mechjebbed to a 100km apoapsis, but the low probe pod torque and lack of aerodynamic stabilization in upper stages resulted in slow roll. Lack of alternate power supplies and low pod torque doomed that attempt when the probe brain consumed all on-board battery power attempting to shipwrangle towards the maneuver node while coasting. Player expecting such an occurrance could likely compensate; Mechjeb does not. Performance with typical payload was not tested, as neither specifications nor images of typical payload were provided.

Also, it's not caused by relativistic mass (Whose use seems to have fallen out of favor over the past few decades). Relative velocity time dilation is required to allow the speed of light to remain constant to all observers in all inertial reference frames. http://en.wikipedia.org/wiki/Time_dilation#Simple_inference_of_time_dilation_due_to_relative_velocity

You're also basically in freefall while the elevator's plummeting. So even if you have the Viking Space Magic Strength to shove off from the bottom of the elevator hard enough to kill your plummet, actually getting your feet onto the bottom of the elevator to do the jumping in the time you have before you hit is ma be a problem.

An Earlier Version of this post included an incorrect graph. I'd loaded the wrong one I had saved in my Desmos account. It is corrected now, both in image and descriptive text. Actually, the delta-V-to-deorbit function looks like this, assuming you're braking retrograde to do your deorbit: Desmos graph that created the above image:https://www.desmos.com/calculator/ksjeuy8ast The above graph is the delta-V necessary to put your periapsis at 70 km over Kerbin as a function of parking orbit altitude. Horizontal axis is altitude in kilometers, Vertical Axis is delta-V in kilometers per second. As it shows, it costs less to deorbit from a parking orbit up to about 350 km altitude than it does from a Parking orbit just inside the SOI. You get a similarly-shaped function regardless of the world in question. Ultimately, if you're doing an efficient ascent in your lander with the attendant gravity turn, during your ascent, you will almost certainly wind up at a point where, if you stopped burning, you would be in a low circular orbit above the body you're orbiting. It's only going to cost you more delta-V to push that apoapse higher if you wanted to, and still more to circularize. So put your parking orbit as low as you can comfortably rendezvous with.

You cannot use the classical Kinetic Energy formula when calculating kinetic energy for objects moving with relativistic speeds. You either have to plug relativistic mass into the kinetic energy formula, or you have to use the relativistic kinetic energy formula. Any object with any positive value of rest mass would have infinite kinetic energy if it was moving at 1c.

It's one of the Custom Window Menu Items. And is included in the Landing Info Custom Window Package.

One of the things you can get Mechjeb to show you is a Suicide Burn Timer, which gives you a numeric countdown to the last instant you can save your craft from impact by slamming full throttle.

There is another issue with the Mk2 Landercan: The Laddering doesn't go /above/ the door, so you can't climb /up/ from it to a Hitchhiker or Cupola mounted atop the landercan.

If you need a lot of Delta-V, using drop-tanks can crank up your Delta-V a little higher by getting rid of the fuel tanks once they're empty. The craft depicted in the image above was designed for a quick intercept of an object in an inclined solar orbit, and has a single LV-N for thrust. It had to kill 5 km/s to do so. It is shown discarding one of the two pairs of daisy-chained drop tanks it brought for that purpose shortly before continuing its deceleration.

When radial decouplers are attatched to parts which are strutted to the craft, the struts tend to cut most of the force of the ejection. The TT-70 radial decouplers (the ones that /aren't/ flat) tend to provide just enough standoff distance on disconnection that, although I don't use separatrons, I don't have issues with boosterscrape even when automated. I also tend to make sure that the center booster is "higher" than the radial ones to give things a little room to rotate around behind the central booster.

Whenever you feel like it. No justification or apology required. I'd probably have it installed myself if I hadn't looked into how to edit the savefile manually back in the 0.14 era, and just am more comfortable doing that.

Am I missing something, or does the Science Archives not show "Recovery of a Spacecraft that...." science awards? (Example: "Recovery of a spacecraft that survived a flight" or "Recovery of a spacecraft that returned from the surface of Minmus")

floor(44/ln(4)) +4 = 35

On a new save, the first Hohmann window to Duna opens at about 50-60 days in. Assuming your path isn't too circitutious, shortly after a ship that takes that window arrives at Duna, the first Hohmann window from Kerbin to Eve opens. About 60 days after the Eve spacecraft arives, a window to Dres opens up where Dres is pretty near its descending node through the plane of Kerbin's orbit upon arrival. At least, that's what I wound up doing in my 0.22 save. Return windows from Duna and Eve open up while the Dres ship is in transit, if I recall correctly, and the return window from Dres to Kerbin opens up maybe about a month after the Dres arrival.

For larger rovers that aren't planning to be relocated after landing, I'll often use side-mounted thrusters for landing. Once the rover's dirtside, the landing engines and SAS modules can be dispensed with.

a really, really useful thing to do is to open up the games settings.cfg file, and find the line that says CONIC_PATCH_DRAW_MODE = 3 And change it to say CONIC_PATCH_DRAW_MODE = 0 When you do this, instead of getting weird squiggly lines of dubious value when your future path passes through a world's SOI, the patch will be drawn in the frame of reference of the object (So it looks like a normal hyperbola) and at the current position of the object (So you can hit Tab a few times and center on it for a really close view.) The result being that, weeks or months before you reach your destination, you can pop a maneuver node a few hours ahead of your ship, run your time accel up to 5x so things stop jumping around, center the map screen on your destination, and spend a few minutes finessing the maneuver node that will move your periapse and arrival trajectory close to where you want them, and spend maybe a 10-15 m/s of delta-V doing it. It also makes it a hell of a lot easier to plot circularization nodes inside the SOI before you reach it, if that's something you want to do. If you use Mechjeb, the Maneuver Node editor allows you to change CONIC_PATCH_DRAW_MODE in-game, and there are a couple other mods that do the same thing, but personally, I change it in the settings.cfg as soon as I install a new version, as I have no use for any other mode than Mode 0. If you /have/ waited until you just crossed the SOI boundary, and your periapse is reasonably close to the planetary surface, Then the thing to do is to perform a Radial- burn to put your periapse where you want it to be, and do your aerobraking or engine braking there. If your periapse was reasonably close to the surface to begin with, in most cases where you've just crossed the SOI boundary, the angular distance you have to move it will be small, and the cost of the burn will be low. Burning retrograde when near the SOI boundary on a hyperbolic trajectory to reduce periapse gets expensive quickly. It can be useful for fine-tuning a periapse altitude, but in most cases, should be avoided. And a retrograde burn to capture just after you cross the SOI boundary winds up being more expensive than that.

This is a Cantanker. It's a Clampotron Sr Docking Port, a Probe brain, a 2m battery, a Rockomax Jumbo-64 tank, a 2m reaction wheel and a Sr Docking Port from end to end. Arrayed around the middle are a pair of RTGs, a pair of the cylindrical monoprop tanks, a pair of Clampotron Docking Ports and a pair of Clampotron Jr docking ports. It also has 8 RCS ports. When I build a rockomax-based asparagus-stage lifter, a Cantanker is almost always the fuel supply for the central booster. On the bottom end is a Rockomax Skipper, attached directly onto the Clamp-o-Tron Sr. Like any other docking ports, a clamp-o-tron sr can be used to disconnect anything attached to its business end, docking port or not, so I use that to disconnect the skipper and let it fall into the atmosphere before circularizing. On the other end is a Tugbot. Tugbots are my typical all-purpose smace movers, using two LV-Ns, and a pair of stack-mounted docking ports for both pulling and pushing payloads. Pretty much anything I send anywhere that doesn't have its own LV-Ns for propulsion is going to wind up being pushed to its destination by a Tugbot, with an attached Cantanker. I started doing this for pretty much the same reason the OP mentions: I started winding up with partially-empty tanks scattered around without brains or docking ports, so the Tugbot-Cantanker combination was developed so that the part of the spacecraft most likely to wind up in a stable orbit could be used as fuel, raided for fuel, built into something else, or deorbited at whim. I don't actually refuel from loose Cantankers aall that often (as I typically have much larger fuel depots in-situ for those), but it's nice to have them just in case, and the probe brain means I can rename them after how much fuel they have left in them.

Aye, the delta-V difference is significant. The following graph assumes the spacecraft starts in a 100km orbit over Kerbin, and sets an interplanetary transfer course. The horizontal axis is semimajor axis distance from the sun in millions of kilometers, the vertical axis is delta-V requirement in kilometers per second for that departure transfer burn. The vertical lines are, from left to right, the semi-major axes of the orbits of Moho, Eve, Kerbin,Duna,Dres, Jool, and Eeloo. Link to the Desmos graph that created the above image: https://www.desmos.com/calculator/nrdjd8qv5x The green curve is the delta-V requirement for doing a burn-from-LKO to the specified solar semi-major axis distance. The red curve is the delta-V requirement for the two-step method of burning just to escape Kerbin's SOI, and then doing a second burn in solar orbit. The closer your destination is to Kerbin, the smaller the difference is, but even with planetary destinations as close as Eve or Duna, you're still spending 50% more delta-V on the transfer departure if you use the two-step method than if you burn directly from LKO. If you have a spacecraft design that can afford the extra losses, fine. But if you have a spacecraft whose fuel margins are thin, or if you want to shift a larger payload to the destination with a smaller spacecraft, or if you want to save delta-V to have more options when you arrive at your destinaton, or if you want to increase the chances of success when you don't know if your design is good enough, you should be burning from LKO.

I land the rover separately from the lander and drive it over. In most of the places I land manned rovers, there's enough infrastructure nearby and in orbit to bring down and extract personell. That's a KAS winch on the landing frame. It has enough delta-V to do one landing from Munar orbit with the rover, and one return to Munar orbit without the rover, at which point it will probably need refueling if the rover is needed elsewhere.

Look at the alignment of the hubs of the front wheels, and compare it to the alignment of the hubs of the rear wheels. The front wheels are actually "higher" on the craft than the rear wheels are because they were rotated on placement. As a result, the rover tilts forward like a table with two short legs.

The delta-V maps assume that you're doing the burn direct from LKO. If you are burning from LKO, aligning your departure trajectory to leave the SOI in the direction of Kerbin's travel, to put your apoapsis at about the distance of Duna from the sun, that is indeed a delta-V of about 1000m/s. If you burn just to escape Kerbin, get into solar orbit, and /then/ burn to transfer to Duna, it costs about 50% more delta-V. Do similar for a high-requirement destination, such as Jool or Moho, and you increase the delta-V requirement by more than 100%.

To expound on this, based on an adult human male needing 2500 kCal every day means the total conversion mass energy of 5 mg (about the mass of two mosquitos, according to wikipedia's Orders of Magnitude (Mass) article) would power that body for about 117 years.

In many cases, if you rotate the strut piece to be flat-side-out before placement, you can stitch two parts of the same diameter together without outrigger pieces. Can make moving the struts after you placed them a bit annoyiing, though, because the part that's best to click on to grab the strut is now inside the tank. Edit: Yes, the cubic octagonal strut is a physicsless part. The simulation doesn't consider it to have mass, regardless of the claim in the VAB, which results in all sorts of crazy things that can be done with it, including using stack separators to make one hit the Mun in 13 seconds. Back in 0.18, one of the reasons that some stations would jitter apart on docking was because a player had used a cubic octagonal strut to mount a docking port radiall, though that may have been fixed by now. In /most/ situations however, a player doesn't wind up using sufficient COSes in critical places to realize that this is so. There are a couple other physicsless parts. I think the RCS ports were similar,but I do not recall what all the other ones were, because the Cubic Octagonal Strut, by way of being a structural part, was the easiest one to accidentally build yourself into trouble with.

With Duna, dependent on your design, and your landing location, it may behoove you to drop directly down instead of doing a long aerobrake when landing on chutes. Because of the way chutes work in KSP, if there's enough atmosphere to partially deploy chutes, the regular chutes will fully-deploy at exactly 500m above the surface regardless of where you are. Full chute deployment doesn't care about local atmospheric pressure in the game as it is. If you're coming in at a shallow aerobrake over Duna, variations in the terrain when you're moving horizontally at several hundred meters per second and low over the surface can result in the ground rising up to smack you before the chutes realize that they should have fully opened. It's one of a few reasons that I started designing my chutelanders to drop straight down from up to 600 km over Duna.

Not entirely. I know Nickelodeon ran reruns of the animated series in the 80's. And apparently the Sci-Fi channel showed it at some point during the 90's.