Yasmy

I will assume you mean after transferring from Kerbol SOI to outer planetary SOI, since going from Kerbin to Kerbol SOI, you are pretty much already at your Kerbol periapsis (if you exited Kerbin's SOI reasonably prograde.) The standard answer to your question is that you don't. The game does it for you. Changing your periapsis at the target planet takes a tiny bit of delta-v when you are far away, if you already have an encounter. It won't be part of typical delta-v calculations or mission planning, other than "now I should adjust my encounter periapsis." But I enjoy all things nerdy, and if you wish to calculate everything, read my next reply...

The vis-viva equation is all you need. You applied it correctly at one spot to find the semi-major axis: a = μr/(2μ - rv2) Now apply it again at periapsis, by plugging the periapsis and semi-major axis in: vp2 = μ(2/rp - 1/a) = μ(2/rp - (2μ - rv2)/μr) = v2 + μ(2/rp - 2/r) Note that this is the same equation in your reply (post #5). You've shown that the vis-viva equation implies conservation of energy. In the future you can calculate just about any orbital operation by applying the vis-viva equation. Plugging in your numbers, I get vp = 9722 m/s.

Gravitational potential energy is negative: E = - G M m / r, where M is the planet mass, m is the spacecraft mass, G is Newton's constant, and r is the distance between them. So the closer you get to the planet, the smaller r becomes, the more negative your gravitational potential energy becomes. Gravitational potential energy is negative because it takes energy to escape the gravitation potential. Infinitely far away, the potential energy is zero, because the gravitational force is zero. As long as you don't spend any delta-V, your total energy, kinetic + potential, is constant: E = 1/2 m v^2 - G M m / r Thus as you get closer to a planet, r decreases, making -1/r more negative. To keep E constant, v must increase.

After losing everything once, I started periodically, automatically backing up my persistent.sfs and quicksave.sfs files. Some people would consider this cheating or impure, but I enjoy being able to back up any number of quicksaves at any time. I use: 1) git - a tool which keeps track of changes to sets of files 2) a shell script which I leave running all the time calls git to save quicksave.sfs and persistent.sfs whenever they have changed. If you are interested in doing something similar, but have never used revision control software, I would suggest looking at mercurial. You really only need to know a few things to get started: creating a repository, saving changes, and checking out previous versions of files.

Let's forget the delta-V issues for a moment, and the drifting over time issues. Suppose you want to set up N roughly equally spaced satellites in a ring, all on the same circular orbit of radius R, dropping them off from a single spacecraft. Suppose the satellites are responsible for the delta-V required to circularize. The easiest way, if you know the period T0 of a circular orbit at R, is simply to set your spacecraft apogee to R, and at apogee, move your perigee until your orbital period is a reduced fractional number of orbits: k/N * T0, where k and N are relatively prime. (k runs from 1 to N-1, and k and N have no common factors.) Or you can do the math ahead of time to determine the correct periapsis: Let T0 = the period of the circular orbit at radius R. Let T1 = the period of the delivery spacecraft. Put your delivery spacecraft on an orbit with its apoapsis at R, and choose its periapsis, r, so that its period is a reduced rational fraction of the circular orbit period: T1/T0 = k/N T0 = c * (2R)^(3/2) T1 = c * (R+r)^(3/2) T1/T0 = k/N = ((R+r)/2R)^(3/2) r = R * (2 (k/N)^(2/3) - 1) Then just try a few values of k. You can pick the first value of k relatively prime to N that gives an r outside the parent's atmosphere. Or if you want to minimize the delta-V for each satellite, choose k = N-1. Note that r and R are distances from the center of the parent, not from the surface of the parent like the Ap and Pe markers in game. If you prefer altitudes like KSP, set your periapsis marker to Pe = (Ap + Rp) * (2 (k/N)^(2/3) - 1) - Rp, where Rp is the parent's radius.

To calculate the delta-v required for most non-atmospheric maneuvers, use the vis-viva equation. For your particular problem, the answer is well known. It is the second burn in a Hohman transfer orbit: And, of course, to calculate the comsat delta-v: dV = 981 ln(m / (m - 2*0.06)) m/s, where m is the initial comsat mass, 981 = g * Isp for sepratrons, and 2*0.06 is the fuel mass for 2 sepratrons. Note that altitudes reported by ksp are relative to the planet sea level, so you have to add in the planet's radius: So pick some low Kerbin initial orbit, such as r1 = 90,000 m altitude + 600,000 m Kerbin radius. Then solve for r2, and subtract off Kerbin's radius to find your desired comsat altitude. Surprisingly, this gives a cubic equation, rather than the quartic I was expecting, but given the nastiness of the general solution to the cubic equation, I would still solve this numerically.

What a great idea. I'm going to use this all the time to prevent dead rockets due to forgetting to extend solar panels!

Hi Tank. This is all correct. You do have to redo the calculations each time you change the payload, since the two engines have different masses. As you guessed, there isn't a proportional change in dV, when you remove a fixed amount of payload. There is a logarithmic change in dV: proportional: dV = a * m0/m1 logarithmic: dV = a * ln(m0/m1) (a = g * Isp) Remove some payload mass dm: dV = a * ln((m0-dm)/(m1-dm)) m0 and m1 are different for the two rockets with different engines, thus there is no simple proportional change in dV when changing the two different rockets by removing some payload.

Well, I accidentally completed this challenge today in a SJTO (Single Jeb to Orbit). One jet engine. One fuel tank. Three air intakes. 27 parts including a launch stability enhancer left on the runway. I was testing a plane w/o chutes or landing gears. When my periapsis popped up out of the ground, I decided to go orbital. The plane didn't make it out of the atmosphere (it's 18.7 km below Jeb in picture 2), but Jeb did, and he got into stable orbit. So then a team of Kerbals assembled the Dammit, Jeb and rescued him in orbit. Except, well, they packed too many snacks in the Dammit, Jeb, so they let him refuel his jetpack and returned to Kerbin. The Double Dammit, Jeb was packed with just as many snacks, but one fewer kerbolnaut, so the second rescue attempt returned Jeb safely to Kerbin.

Nope. You can't have the pressure perfectly even on all sides if there is a gravitational field anywhere nearby. (Or a heat source, either.) If the sphere is lighter than the displaced air, the sphere will rise. Due to gravity, the air pressure is higher at the bottom than the top of the sphere. Air pressure in the atmosphere at some height can be thought of as the weight of the air (per unit area) above that height. The sphere is pulled down by gravity, and pushed up by the pressure difference between the bottom and top, and the difference determines which way the sphere moves. BTW: Most smartphones come with pressure sensors these days. If you get an app to read the sensor, you can see the difference in the air pressure at your head vs. your toes.

Jeb is about 10 days out from Kerbin's SOI after sciencing it up on Gilly. He has about 4 units of fuel left. Just enough to tune his atmospheric reentry.

Hi again, Tank. Now you know the math. Let's talk design. m0/m1 = (M0/M1)^(V/v) for equal delta-v. Quiz: Figure out which of these scenarios is preferable: Which produces enough delta-v for ship 2? A) m0/m1 < (M0/M1)^(V/v) m0/m1 > (M0/M1)^(V/v) Let's assume now that you have designed ship 1, and are happy its delta-v, but want a version with at least as much delta-v, changing only the engines and the amount of fuel. In KSP, most liquid fuel tanks have a full to dry mass ratio of 9. In the real world, the ratios depend on a lot of things, such as fuel type and cryogenic needs. I'm going to use 9 below like KSP, but you could use a variable or a different constant for a different tank mass ratio. m0 = rocket mass with full fuel m1 = rocket mass with no fuel Let's define a few more variables: mP = mass of the payload (minus the tanks): everything on the rocket that is not a fuel tank, fuel, or an engine mT = mass of the empty fuel tanks mE = mass of the engines empty rocket: m1 = mP + mT + mE full rocket: m0 = mP + 9*mT + mE Presumably, mP = MP: the payload is the same on ship 1 and ship 2. mE and ME are not the same: mE = 48-7S mass. ME = LV-909 mass, for example. mT and MT are also not the same: ship 2 will need a different number of fuel tanks I'm leaving the final bit of algebra to you: Solve for mT, the mass of the empty tanks, (or 9*mT, the full fuel tank mass), (or 8*mT, the fuel mass). Good luck!

Hi Tank. I'll go over the math for you. A) The exponential function, exp, and the natural logarithm, ln, are inverses: exp(ln(x)) = x, and ln(exp(x)) = x Try it on a calculator. exp(x) is also written e^x. Logarithms remove exponents: ln(a^ = b * ln(a) Note that if a = e, we get back the identity from above, since ln(e) = 1: ln(exp() = ln(e^ = b * ln(e) = b Assume upper case letters for ship 1, lower case letters for ship 2: 1) V * ln(M0/M1) = v * ln(m0/m1) Bring the powers inside using rule B above: 2) ln( (M0/M1)^V ) = ln( (m0/m1)^v ) Exponentiate both sides: If a = b, e^a = e^b: 3) exp(ln( (M0/M1)^V )) = exp(ln( (m0/m1)^v )) Use rule A: exp(ln(a)) = a 4) (M0/M1)^V = (m0/m1)^v Take the vth root of both sides: (the power of 1/v) ((M0/M1)^V)^(1/v) = ((m0/m1)^v)^(1/v) This simplifies to: 5) (M0/M1)^(V/v) = m0/m1 Now you know how to find the ratio of initial to final mass, m0/m1 = (M0/M1)^(V/v), that ship 2 needs in order to have the same delta-v as ship 1.

Inspired by HOCgaming's charity drive to the north pole, I drove a jetcar to the north pole from KSC. On most terrain, it can go 20-25 m/s at 2x physical warp without exploding too frequently. On the polar icecap or similarly flat terrain, it goes just under 60 m/s at 4x physical warp. Room for one pilot and two external passengers.

Rotate the central engine by 45 degrees.

I have had the same problem selecting the current (blue) trajectory for placing nodes, when the post-encounter trajectory is very similar to the pre-encounter trajectory. The purple trajectory is the post-Kerbin encounter trajectory, which is useful for planning gravitational assists and various other things. There are two potential remedies: 1) Zoom way in, and mouse around until a blue sphere appears on the trajectory, rather than a purple sphere. Then click as usual. You may have to swing the camera around a bunch and zoom in and out. Sometimes it helps to create the node a few hours away from your vessel, then drag the node to where you want it. 2) I haven't used that particular maneuver node editor that you are using, but it looks like you could change the time in the top box. I'm sure there is a quick way to find the current time in the game, but I don't know it at the moment. You can quicksave, then open the quicksave.sfs file and find current time. Right after FLIGHTSTATE in the quicksave there is a line which says something like: UT = 546698.584827724 Add a couple thousand to that number, and enter it into the maneuver node editor. Happy trails