OhioBob

It's really just a coincidence that it works out that way. If you are in a minimum orbit around Kerbin, say about 70-75 km, then Mun will rise when the phase angle is about 114 degrees. This is the angle between Mun and your spacecraft as measured from the center of Kerbin. If you burn at that instant to raise your spacecraft's apoapsis to the height of Mun's orbit, it will take about 7.4 hours for the spacecraft to travel halfway around Kerbin from its current periapsis to its apoapsis. The spacecraft will have traveled 180 degrees from its starting point, but since it started 114 degrees behind Mun, it will have traveled 180-114 = 66 degrees relative to Mun's starting position. In that same 7.4 hours that is takes the spacecraft to reach apoapsis, Mun will have traveled 69 degrees around Kerbin. Therefore the spacecraft and Mun will arrive at approximately the same point in space at the same time. With just a little bit of tweaking you can have a very nice encounter.

If you really find it that interesting I can easily show you the derivation of the equation. A body moving only under the influence of gravity has constant energy (i.e. law of conservation of energy). Of course the energy of a body is the sum of its kinetic and potential energy. This is given by the following, E = mv2/2 - GMm/r where m is the mass of the body, v is its velocity, r is its radial distance from the center of the planet, and GM is the gravitational parameter of the planet (i.e. constant of gravitation G times mass M). The term mv2/2 is the kinetic energy and -GMm/r is the potential energy. If r1 and v1 are the distance and velocity of the body when it is near the planet, and r2 and v2 are the distance and velocity of the body when it is far from the planet, then, since energy is constant, we have mv12/2 - GMm/r1 = mv22/2 - GMm/r2 Dividing through by m we get v12/2 - GM/r1 = v22/2 - GM/r2 To obtain the hyperbolic excess velocity we want r2 to be some distance far from the planet. As r2 approaches infinity, -GM/r2 goes to zero, therefore we have v12/2 - GM/r1 = v22/2 Multiplying by 2 we get v12 - 2GM/r1 = v22 The equation for escape velocity is Vesc = (2GM/r)1/2, therefore we can substitute as follows v12 - Vesc2 = v22 Since v1 is the velocity near the planet we can call this the burnout velocity. And since v2 is the velocity at some infinite distance, it represents the hyperbolic excess velocity. Thus the final equation is, Vbo2 - Vesc2 = V∞2 I hope I didn't bore you with all that, but I think it really helps the understanding to know the derivation of an equation.

I agree that the ∆V savings aren't worth the trouble. In fact, if you don't get the intercept just right, you're likely to burn up whatever ∆V savings there were in having to make course corrections. Better to go into orbit first and take your time making a good clean transfer burn. I suppose it might differ from person to person on how they build their rockets and how they perform their ascents, but in my case I estimate that the ∆V savings would amount to only 30 m/s.

In either method we are creating a parking orbit from which the spacecraft is injected into its transfer orbit. In your method you are establishing a parking orbit around the sun (Kerbol), while the method used by others is to establish a parking orbit around Kerbin. The latter is far more efficient. In both cases there are going to be gravity and drag losses while ascending from Kerbin, but let’s ignore those and call it a wash. Let’s consider only the velocity needed to escape Kerbin gravity, which, from an altitude of 75 km altitude, is 3235 m/s. (I’m using 75 km because that’s my typical parking orbit altitude.) Note that it actually takes a little less to escape Kerbin because the game uses a simplified patched conic method. We don’t actually have to reach escape velocity, we just have to reach the sphere of influence. In your method we need to reach about 3235 m/s to escape Kerbin and enter into a solar orbit. The resulting orbit would essentially be the same size as Kerbin’s orbit around Kerbol. We then need to perform a second burn to either decrease our periapsis (if traveling to an inner planet) or increase our apoapsis (if traveling to an outer planet) in order to establish an intercept with our target. Let’s say we want to go to Duna, this would require a ∆V of about 950 m/s (varies about 850-1050 m/s), resulting in an orbit with a periapsis near Kerbin and an apoapsis near Duna. The total ∆V, therefore, is 4185 m/s. (With gravity and drag losses this would be closer to 6450 m/s.) When using the Kerbin parking orbit method we again need to reach a velocity of 3235 m/s to escape Kerbin, it’s just done in two steps. We first reach an orbital velocity of 2287 m/s (75 km) and then perform a second burn to escape. The big difference is that from Kerbin orbit we can take the time to create a maneuver node, establish a good intercept with our target planet, and inject directly into our transfer orbit. Let’s say that from our Kerbin parking orbit we increased our velocity to exactly escape velocity. Once we’ve left Kerbin space we’d be traveling at zero velocity relative to Kerbin. In order to reach Duna we’d need to add another 950 m/s (same as your method). Let’s now say that as we leave our parking orbit we accelerate to little bit greater than escape velocity. In this instance when we reach the edge of Kerbin space we’d have some left over velocity. This residual velocity is called hyperbolic excess velocity. We can plan our burn so that our hyperbolic excess velocity is exactly the 950 m/s we need to reach Duna. The equation for hyperbolic excess velocity, V∞, is (that subscript is the 'infinity' symbol if it's too small to read) V∞2 = Vbo2 – Vesc2 where Vbo is the burnout velocity and Vesc is escape velocity. In our Duna example we know that escape velocity is 3235 m/s (75 km parking orbit), and the required V∞ is approximately 950 m/s. We can therefore calculate the required burnout velocity. Vbo = SQRT( 9502 + 32352) = 3372 m/s Thus we see that by performing our transfer orbit injection from low Kerbin orbit, it takes only a small amount of ∆V to produce the V∞ needed to reach our target planet. In this case the ∆V needed to reach Duna is only 3372 m/s (or about 5635 m/s including gravity and drag losses). This is considerably less than it takes to perform the transfer injection from a solar orbit. Of course it is theoretically possible to launch directly from the surface into an escape trajectory that has the required V∞, but it’s nearly impossible to obtain the proper intercept with the target planet with the tools available to us in KSP. This is why the Kerbin parking orbit method is preferred. It allows the use of maneuver nodes to properly plan and execute the transfer burn while still being highly efficient in terms of ∆V.

You're not alone. I always prefer SAS for attitude control. I'll include RCS only when translation is needed. I don't see the need to switch off the SAS. I usually keep the SAS on all the time while I toggle only the RCS on and off. One thing you can try doing is to not use the 'RV-105 RCS Thruster Block'. Instead use the 'Place-Anywhere 7 Linear RCS Port'. Place four of them around the ship's center of mass pointed radially outward to provide translation. With this positioning the thrusters don't provide any rotation, thus they won't fire when rotating.

This topic was discussed in detail in the following thread: http://forum.kerbalspaceprogram.com/threads/102850-Particularly-minute-minutiae-of-nosecones-in-stock-aerodynamics

That's how I lost my first one. By the time I realized it he was already past the point of no return. My other loss came when I missed my targeted landing site and my Kerbal ended up tumbling down a mountain side.

I try to take good care of my Kerbals. I don't go overboard with safety precautions, but all my missions are planned with the safe return of the crew as a primary objective. Heartbroken is too strong of a word, but I certainly don't like to see them perish. I lost a couple in my first few days playing the game, but since then I have an excellent safety record.

I think most people just use the vacuum ISP in their calculations. For instance, it is typically stated that it takes 4550 m/s to reach Kerbin orbit, which is based on vacuum ISP. The loss resulting from the reduction of ISP due to atmospheric pressure is about 150 m/s. In other words, it takes about 4400 m/s to reach orbit if you perform the computation using the actual instantaneous ISP integrated over the ascent. I find that if you use the average of sea level and vacuum ISP for the lower stage, and vacuum ISP for the upper stage, you'll get a pretty good estimate of what the actual ÃŽâ€V will be. It easier just to use vacuum ISP for all calculations. ÃŽâ€V caluculations are performed using "standard gravity", which is 9.81 m/s2 (though I've read that it's actually closer to 9.82 m/s2 within the game). Local gravity has nothing to do with ÃŽâ€V calculations. There are some general staging rules of thumb that go like this: 1. Stages with higher ISP should be above stages with lower ISP. 2. More ÃŽâ€V should be provided by the stages with the higher ISP. 3. Each succeeding stage should be smaller than its predecessor. 4. Similar stages should provide the same ÃŽâ€V. I have my own rules of thumb for designing a good launch vehicle. See below. It depends on the stage. I've done quite a bit of research into TWR in an effort to optimize my payload fraction. Here's are OhioBob's rules of thumb: 1. Stage 1 TWR = about 1.65 2. Stage 2 TWR = about 1.30 3. Ratio of Stage 2 thrust to Stage 1 thrust = 0.35 Stage 1 refers to the lower stage that ignites at liftoff (KSP numbers the stages from the top down, which is the reverse of how it's done in the real world). If you are using SRBs or other strap-on stages, then the TWR refers to the combined liftoff TWR. I figure it only takes two stages to reach Kerbin orbit. If you have any upper stages they are most likely used for orbital maneuvering or ejection from orbit. These upper stages can be of much lower TWR, generally <1. These numbers apply to stock aero only. If using NEAR or FAR, then different rules apply. I like to kill my horizontal velocity at as low an altitude as possible. The lower you are, the less you have to fall, thus the less vertical velocity you have to kill. I just make sure I'm high enough to give me the time necessary to get reoriented and make a good landing without crashing. I don't like to be rushed. Personally, I like to start my ascent vertical and then transition into a horizontal burn, accelerating up to about 250-300 m/s. This will usually put me into a sub-orbital trajectory with an apoapsis of about 10-15 km. I then circularize the orbit at apoapsis. Once in orbit I preform my "transKerbin injection" burn at an ejection angle of about 135-140 degrees. In other words, if Mun is moving toward the 3 o'clock position, and Kerbin is in the 12 o'clock direction, then I start my burn at about the 1:30 position. The burn will send me off into the 9 o'clock direction. The above is my personal preference, I don't know if it's the most efficient.

I haven't used a leveled-up scientist on any of my missions yet. How do I get the science bonus from him? Does he just need to be included in the crew of the vessel that collects the science, does he have to physically take the science from the experiments, or something else?

No jets. The first stage uses a cluster of five Rockomax Mainsails and the second stage uses a single Kerbodyne KP-2L. Below is a picture, without payload. It may look like I'm using asparagus staging, but that's not the case. The four outboard engines are rigidly attached (no decouplers). The propellant feeds from the center tank to the outer tanks. When the center tank goes dry, the center engine cuts off to lower the TWR. The four outboard engines continue to run until they drain their individual tanks (in about 38 seconds), then the entire first stage drops away as a unit. I ran some computer simulations to try to optimize the TWR and ascent trajectory. I think that's the reason I'm getting an impressive payload fraction.

On any planet with an atmosphere, then a one-stage lander is better. You'd be landing with parachutes, so very little of the lander's mass is dedicated strictly to the landing. The only mass that is really disposable is the landing gear, parachutes, and perhaps some science experiments. Since most of what you're landing is needed for the ascent, then two-stages is rather pointless. You might consider using decouplers to jettison the landing gear, etc., but you'd have to do the math to see if the gain is worth carrying the mass of the decouplers. It is on the airless bodies that two-stages might make some sense. Although I've landed on most planets and moons, the only ones I've taken off from are Mun, Minmus and Duna, therefore I don't have a lot of experience. Of course Duna has an atmosphere, so I've already commented on that. For Mun and Minmus, I don't think two-stages is worth the trouble. Those bodies don't require all that much delta-v, so both landing and ascent can be accomplished with a pretty low mass ratio. Low mass ratios can easily be obtained with one stage, so why add the complexity of two? Even at Moho you can probably land and take off again with a mass ratio of about 2, which is easily obtainable with a single stage. If you can find a way to build two stages, each with a mass ratio of about 1.4, for less money and less mass than a single stage with a mass ratio of 2, then use two stages.

I don't like really big launchers. The largest I've launched to date is a 2-stage expendable with a liftoff mass of 458 t, of which 80 t is payload.

I've done something similar to what you are describing without any problem. It's possible you put too much distance between the pods and that is the reason you can't switch between them. I don't know what the number is, but I do know that there's a maximum separation beyond which you can now longer toggle between the ships. I waited until very late in the descent (shortly before parachute deployment) before I separated the pods and had no problem switching back and forth between them all the way to landing.

Yahoo! Jebediah and friends are finally back home again, after 4 years and 50 days adrift in space.

I haven't flown a mission with exactly the capabilities that you spell out, but I just slapped together something in the VAB with comparable capability. I used 'middle-level' technology, i.e. a Mk1-2 command pod, Rockomax brand parts, etc. I was able to throw something together for about 67k in funds. Of course this included only one Mystery Goo and one Materials Bay. Adding some of the more expensive science instruments and we can easily exceed 80k. The vehicle has a delta-V of a little over 8,000 m/s, which should be plenty to fly a basic Mun landing and return.

I considered using two panels but I went with three to play it safe. One is just crazy talk! There's actually plenty of delta-v in that vehicle to get the job. The biggest problem was control, or lack of it. That OKTO core barely had enough torque to keep me flying straight while under RT-10 power. I also had no fine thrust control, so fine tuning the final orbit was tricky. I had to use extremely short pulses from the main engine. Sweet! You certainly have a lot of capability squeezed into a small package. I don't know if it would work in your case, but here's trick I've used to give small probes a very low-mass propulsion capability: Use a small RCS fuel tank and place two or more 'place-anywhere' RCS ports around the perimeter angled rearward. The ISP is low but you have no engine mass. The downside is that for long burns you have to continually hold down the H key.

I just completed a "position satellite in a specific orbit of Minmus" contract using a very minimalistic vehicle. Advance funds: 41,321 Completion funds: 237,598 My cost to complete: 3,205

You can always terminate it in the Tracking Station.

The following are the first 25 threads that are returned when searching "scansat". Can you find the SCANsat threads in that list? Kethane Pack 0.9.2 - New cinematic trailer! - 0.25 compatibility update [0.90] TextureReplacer 2.1.2 (20.12.2014) [0.90][Release-4-3][Dec 16, 2014] Active Texture Management - Save RAM! [0.90] Ferram Aerospace Research: v0.14.5.1, 12/19/14 Show off your awesome KSP pictures! [0.25] Kerbin Shuttle Orbiter System v4.09 [0.90] Real Solar System v8.4 Dec 21 14 [0.25] RasterPropMonitor - putting the A in your IVA (v0.18.3) [8 Oct] [0.25] Extraplanetary Launchpads v4.4.0 Firespitter propeller plane and helicopter parts v6.3.5 (Sep 1st) for KSP 0.24.2 [PART, 0.90] Anatid Robotics / MuMech - MechJeb - Autopilot - v2.4.2 [0.23] Atmospheric Sound Enhancement What did you do in KSP today? Mission Controller 2 (Version 1.10.1) (KSP .90) (Updated 16 Dec) [0.25] TAC Life Support v0.10.1 [10Oct] [No Win64 Support] [0.90/0.25] Near Future Technologies (NFSolar, Construction updated to 0.90) [0.25.x] Sum Dum Heavy Industries - Service Module System (V2.3 / 10 October 2014) [0.90] Deadly Reentry v6.4.0, Dec 16, 2014 [0.90.0] Fusebox - electric charge tracker and build helper. 1.2 released 22nd Dec 14 [0.90] Kerbal Alarm Clock v3.0.6.0 (Dec 18) [0.90] Procedural Dynamics - Procedural Wing 0.9.2 Dec 21 [0.25]Better Than Starting Manned: Career Mode Redefined (v1.64999 - Nov 4th) Kerbal Realism (Modded Career Series) [0.25 & 0.90] Kerbal Engineer Redux - v0.6.2.12(0.25) and v1.0.13.1(0.90) [0.24][7-4] Sep-9-2014 EnvironmentalVisualEnhancements

Finding the relevant thread and the correct version is not as easy as it sounds.

I had that problem too, though it was a mission that was already in progress before updating to 0.90. Before starting a new career game I decided to finish up a game that was I already in the middle of. I've had at least one mission rendered inoperable because of this issue. I hope I don't find that more of my probes won't work when they get to their destinations.

Yes. You can also check the inclination of the orbit in your contract. If it is less than 90 degrees then you will be in a normal prograde orbit. If the inclination is greater than 90 degrees then you will be in a retrograde orbit.

I just upgraded from SCANsat from v9.2 to v9.4.1 and that seems to have fixed the problem.

I'm playing an old career game that I had in progress before updating to 0.90. I've already got all the tech and upgrades. I'm just finishing up my existing missions before I start a new career game. I tried SCANsat in sandbox and experienced the same problem. Thanks, I didn't know that. I'll search for that thread and download the update.