Yasmy

I find you relation to be highly unlikely. A first order effect like this shouldn't involve this kind of product: B * (3-A) = 2. Zeroth order approximations gives perfect keplerian orbits. Should be independent of A or B. First order effects gives resonances and deviations such as precession of apses. Should depend linearly on A or B. Second order effects would give wobbles and non-elliptical deviations. Should depend quadratically on A and B, such as the product A*B. But let's look at what your relation says. First, define the deviations from perfect resonance: Let A = T2/T1 = 2 + a Let B = T3/T2 = 2 + b Now plug these into your relation: B = 2 / (3 - A) 2 = B * (3 - A) = (2+ * (3-2-a) = 2 - 2a + b - a*b 0 = a*b + 2a - b This is a very strange relation between a and b. But note that a*b is tiny. Much smaller than a or b. Let's drop it. 2a = b Now this is much nicer. It still fits your observation, and the relation is much simpler. Of course this says nothing of causation... I wouldn't be surprised to find that the system is evolving to enforce that relation, but for now it's idle speculation.

Now from the department of nitpicking without answering the question: 1) a thousand gigawhatevers is a terawhatever: https://en.wikipedia.org/wiki/Metric_prefix 2) pressure is force per unit area. for example, a Pascal is a Newton per square meter. https://en.wikipedia.org/wiki/Pascal_(unit). If you apply the same force over a larger area, the pressure is lower. For kicks, perhaps you should submit your question to xkcd - what if?

You have not described your device sufficiently for anyone to say anything at all about it. If you want a real critique of your work, you have to show your work. Otherwise, what are you doing here? What is the point of your post? I'm not trying to be hostile. I'm saying that your claim that no one can refute you is meaningless. Of course no one can refute you (or believe you!) if you don't give a full and precise description of your experiment. The gold standard in experimental science is that you describe your experiment and results sufficient so that other people can recreate and verify the experiment on their own. It is acceptable, and even valuable, to be wrong. People learn as much from null results or failed experiments as from successful ones. Anything less than full and open disclosure is a meaningless waste of time for others to consider. I think it is great that you are doing experiments. Keep on. Just understand you need to meet a certain standard if you want a meaningful dialog.

I haven't made a tool or mod, but I did do the dV calculations from every moon to every other planet. I posted the results for Minmus and the Mun. The interesting thing to note is that from the Mun (ignoring plane change maneuvers), it is cheaper to go directly to Eve or Duna than to swing around Kerbin. For other destinations from the Mun, and for all destinations from Minmus, you save dV by swinging by Kerbin.

Looks like everything is behaving normally and correctly. Your relative velocity really is changing that much. If you turn off SAS the prograde marker should stop jumping around, but that doesn't solve your problem. The practical way to solve this problem is: 1) let the two ships drift much further apart along the docking port axes (20-50 meters), 2) line up and approach at a reasonable speed (for example, with 1 to 2 seconds worth of RCS puff). Having a small but non-zero relative velocity will make the prograde marker stay steady. 3) continue to adjust your relative velocity so that it stays pointed at the target 4) kill most of your relative velocity when you get close (a few meters). Edit: Oops. I missed an entire page of responses to your video before posting this. Now it's quite redundant.

Are you sure you didn't accidentally tweak the amount of oxidizer in the VAB? I would quicksave (F5), open the quicksave.sfs and manually set the oxidizer level to 11/9 times the liquid fuel level, then reload (F9). If it continues to happen, then I would worry.

What does ultimate mean? What are your parameters? What are your goals? If you just don't want to be found, then hands down, way out in the Oort cloud. At a lightyear away, you won't ever be found if you don't want to be found.

Tylo is a jerk. Just assume Tylo will cause problems if you sneeze in its general neighborhood, or try to sneak past when it isn't looking. I assume HarvesteR will continue to improve the conic patch solver. It's pretty good already, but this is one of its known weaknesses. It is a fairly hard problem to predict the next N SOI changes every frame or physics update. I'd love to see a modder take a crack at this problem. It's a great toy problem to play around with.

I had a slight post-release collision with a small asteroid I was delivering to the lunar surface. Unable to orient properly in time for a soft touchdown, the bottom of my craft was sliced off, layer by layer until all that remained was a pod and decoupler. The remains slid about 50 meters before coming to rest against something nice and sturdy...

ObsessedWithKSP gave you the correct practical answer. Geosynchronous orbits are in the wiki. None the less, you asked for a formula, so here goes: For a circular orbit at radius r, the velocity is v = sqrt(mu/r). The circumference of the orbit is C = 2 pi r. Thus the period of the orbit is T = C / v = 2 pi r / sqrt(mu/r) = 2 pi sqrt(mu) r3/2. This is Kepler's Third Law: The square of the period is proportional to the cube of the semi-major axis. For a circular orbit, the semi-major axis equals the radius. So find r such that your period T equals the planet's sidereal day: r = (T2 / 4 pi2 mu)1/3 Finally, KSP shows you altitude above the nominal radius of the body, rb. So you have to set your altitude to r - rb.

It's approximation time: Start with a 100 km altitude circular orbit, for an orbital radius of r0 = 700 km, since you have to add Kerbin's 600 km radius to your altitude to get your radius. Your initial velocity is approximately V0 = sqrt(mu/r0) = 2246 m/s. Now make a small velocity change dV to new velocity V1 = V0 + dV. This causes a small change in the radius of the opposite side of your orbit: r1 = r0 + dr. Your new semi-major axis is a = (r0 + r1)/2 = r0 + dr/2. Plug V1 and a into the vis-viva equation to find dr in terms of dV: V12 = mu (2/r0 - 1/a) (V0+dV)2 = mu (2/r0 - 1/(r0 + dr/2)) Now solve for dr, using V02 = mu/r0 to get rid of mu: dr = 4 r0 dV / (V0 + 2 dV) Since dV << V0, we can approximate this as: dr = 4 r0 dV / V0 Thus the fractional change in your radius is approximately four times the fractional change in your velocity: dr/r = 4 dV/V. Suppose for example you dock equal mass parts at about 0.2 m/s, changing your station velocity by dV = 0.1 m/s. Then dr = 4 r0 dV / V0 = 700000 m * 0.1 m/s / 2246 m/s = 125 m. If you dock from behind, your apoapsis is raised by 0.125 km, and if you dock from in front, your periapsis is lowered by 0.125 km. Enough docking, and you can move your orbit quite a bit. This is not to say that you are not also experiencing a phantom force bug. At least that force should only be present when you are focus on the station or something near it.

Allow me to introduce you to Abyssal Lurker: .Check out his second launch 3:00 minutes in, though the whole video is worth the watch. Sure, it's unmanned, but I have no doubt he could do it manned as well. I would recommend all of his videos.

You are right on that conservation of momentum says you get the same dv regardless of your velocity. Specific orbital energy determines the orbit: E = 1/2 v^2 - G M / r Make a small velocity change dv: E = 1/2 (v+dv)^2 - G M / r So the change in specific orbital energy is dE = 1/2 (v+dv)^2 - 1/2 v^2 = v dv + 1/2 dv^2 For a small dv, with dv << v, the 1/2 dv^2 term can be ignored because it is small compared to v dv. Thus dE is approximately v * dv. This is the meaning of the Oberth effect: The change in orbital energy for a given dv is proportional to your velocity: dE = v * dv.

Without using a mod, no. Try, for example, http://forum.kerbalspaceprogram.com/threads/47863-0-23-PreciseNode-0-9-Maneuver-Node-Assistant-(update-Jan-27-14)

I don't know of any situation where drag forces in a fluid are exponential in velocity. You'll have to ask your roommate for clarification. Both in air and in liquids, drag forces tend to be proportional to the square of the velocity. Though for very small particles at low velocity, the drag may be linear in velocity. In KSP: Drag

Pet peeve: That's not exponential in v, it's polynomial in v. v^n: polynomial c^v: exponential I'm sure you know this. I just see rampant misuse of the word exponential.

Here are three craft files, with some unimportant stuff removed: A: pod, tank, engine, and a modded part, KER, slapped on the side of the tank B: pod, tank, engine. no KER C: pod, engine. (example of removing a part in the middle of the part tree.) Between craft files A and B, the only differences are 1) the lack of the Engineer part 2) the lack of the link to the Engineer part in the tank part in craft B: link = Engineer7500_4294809086 Between craft files B and C, the only differences are 1) the lack of the fuel tank in C 2) in C, the pod link goes to the engine, and the engine link goes to the pod 3) the position of the engine has changed by the height of the tank ship = A *deleted stuff for brevity* PART { part = mk1pod_4294824866 partName = Part pos = 0,5,0 rot = 0,0,0,1 attRot = 0,0,0,1 mir = 1,1,1 istg = 0 dstg = 0 sidx = -1 sqor = -1 attm = 0 link = fuelTank_4294819070 attN = bottom,fuelTank_4294819070 *deleted stuff for brevity* } PART { part = fuelTank_4294819070 partName = Part pos = 0,3.629272,0 rot = 0,0,0,1 attRot = 0,0,0,1 mir = 1,1,1 istg = 0 dstg = 0 sidx = -1 sqor = -1 attm = 0 link = liquidEngine3_4294816122 link = Engineer7500_4294809086 attN = top,mk1pod_4294824866 attN = bottom,liquidEngine3_4294816122 *deleted stuff for brevity* } PART { part = liquidEngine3_4294816122 partName = Part pos = 0,2.44615,0 rot = 0,0,0,1 attRot = 0,0,0,1 mir = 1,1,1 istg = 0 dstg = 0 sidx = -1 sqor = -1 attm = 0 attN = top,fuelTank_4294819070 *deleted stuff for brevity* } PART { part = Engineer7500_4294809086 partName = Part pos = -5.412827E-08,3.856584,-0.6191552 rot = 0,0.7071068,0,-0.7071069 attRot = 0,0,0,1 mir = 1,1,1 istg = 0 dstg = 0 sidx = -1 sqor = -1 attm = 1 srfN = srfAttach,fuelTank_4294819070 *deleted stuff for brevity* } ship = B *deleted stuff for brevity* PART { part = mk1pod_4294824866 partName = Part pos = 0,5,0 rot = 0,0,0,1 attRot = 0,0,0,1 mir = 1,1,1 istg = 0 dstg = 0 sidx = -1 sqor = -1 attm = 0 link = fuelTank_4294819070 attN = bottom,fuelTank_4294819070 *deleted stuff for brevity* } PART { part = fuelTank_4294819070 partName = Part pos = 0,3.629272,0 rot = 0,0,0,1 attRot = 0,0,0,1 mir = 1,1,1 istg = 0 dstg = 0 sidx = -1 sqor = -1 attm = 0 link = liquidEngine3_4294816122 attN = top,mk1pod_4294824866 attN = bottom,liquidEngine3_4294816122 *deleted stuff for brevity* } PART { part = liquidEngine3_4294816122 partName = Part pos = 0,2.44615,0 rot = 0,0,0,1 attRot = 0,0,0,1 mir = 1,1,1 istg = 0 dstg = 0 sidx = -1 sqor = -1 attm = 0 attN = top,fuelTank_4294819070 *deleted stuff for brevity* } ship = C *deleted stuff for brevity* PART { part = mk1pod_4294824866 partName = Part pos = 0,5,0 rot = 0,0,0,1 attRot = 0,0,0,1 mir = 1,1,1 istg = 0 dstg = 0 sidx = -1 sqor = -1 attm = 0 link = liquidEngine3_4294816122 attN = bottom,liquidEngine3_4294816122 *deleted stuff for brevity* } PART { part = liquidEngine3_4294816122 partName = Part pos = 0,4.32434,0 rot = 0,0,0,1 attRot = 0,0,0,1 mir = 1,1,1 istg = 0 dstg = 0 sidx = -1 sqor = -1 attm = 0 attN = top,mk1pod_4294824866 *deleted stuff for brevity* } Note how each part has a unique id number attached to the part name. If you add more parts of the same type, the id numbers will be different. Position of the part in the craft file doesn't matter (except maybe the root part.) So removing a part only effects the parts which link to it by name. Of course, if you remove a part in the middle of a structure, and attach the parts it connected to to each other, you will leave a gap. Thus you need to adjust the pos variable of any parts that need to be moved to fill the gap. If you can fill the gap with a similar sized part (by making the appropriate links), you won't have to adjust the positions of anything.

.craft files are different from save files. The order of the parts in the .craft file doesn't matter. Each part is linked explicitly to other parts by a unique part id, rather than by the order of the part in a vessel like in a .sfs file. Thus you do not have to renumber all the parts and links in and to parts after the removed part. You just have to remove the part, and references to it from other parts if nothing is attached to it. (So yes, you do have to do slightly more than remove the part.) But yes, sometimes it is easier to edit the part to be a different part. You still have to edit the links in the new part and the part it is attached to.

.craft files should be pretty easy to edit in any text editor. If nothing is attached to the part, just delete the entire PART section for that part. (That is, the part was placed on something, but nothing was placed on the part you want to remove. Edit: Then delete the name of that part (partName_number) from the PART section of the part it was attached to. If something is attached to the part, it gets trickier. In a PART section there are a few variables that describe how the part is connected to the other parts of the vessel. I suggest you go to the VAB and make a very simple rocket: 1 pod, one fuel tank, one engine, and slap one solar panel on the side of the fuel tank. Then go to the VAB and make a second very simple rocket: the same pod and engine, without the tank and panel. Now you can compare the two to see what is needed to remove a part. In the PART section for the pod, it will contain a link to the tank. In the PART section for the tank section, a link to the pod, a link to the engine and a link to the panel. In the PART section for the engine, a link to the tank. So to get rid of the tank and panel, replace the engine's link to the tank with the tank's link to the pod, and the pod's link to the tank with the tank's link to the engine. Then delete the tank and panel PART sections. Then you may have to edit the position of the part in the "pos" variable. It seems the second coordinate is the z coordinate, which is the distance from the floor of the VAB, or something similar. The z coordinate of all parts attached to moved parts should be adjusted by the same amount (which should be the height of the removed part.) If the part you care about was attached with symmetry, attach the solar panels above with symmetry to see how symmetric parts are linked in .craft files.

The four numbers are a quaternion representation of a rotation, which avoids the potential loss of a degree of freedom when using Euler angles, often referred to as gimbal lock.

You're ignoring or misunderstanding Newton's laws of motion. If you had to pick one topic in physics, learn Newton's laws. Your device would have to break Newton's first and third law to work the way you describe it.

Strange. I've not run across these junk science journals before. A little snooping around turns up tons. Lots of plagiarism from the Wikipedia article for Gravity Turn, from versions predating this article. I'm guessing that you will find that same for the other listed sources. The good news is that we (the world) are slowly are gaining some legit open-access journals. It is unfortunate that publicly funded science sits largely a) behind paywalls and in the copyright hands of private corporations. Anyway, sorry to dampen the mood. Congratulations on getting it to work!

For some low delta-v transfers from some moons, the ejection orbit is not hyperbolic but elliptical. Essentially, the SOI is too small compared to the size of a slightly sub-escape elliptical orbit. For example, a Minmus to Mun transfer burn is still an elliptical orbit around Minmus with apoapsis outside the SOI. Thus you can't use the hyperbolic orbit escape angle calculation. Here's an snippet from the source for http://ksp.olex.biz/js/kspcalc.js for elliptical escape burns. if (e < 1) { // maltesh's solution for elliptical transfers var a = -o.mu/(2*eta); var l = a*(1-e*e); var nu = Math.acos((l-o.soi)/(e*o.soi)); var phi = Math.atan2((e*Math.sin(nu)), (1+e*Math.cos(nu))); //eject = (270 - (phi*180/Math.PI)) % 360; // Kosmo-nots fix to maltesh's solution eject = (90 - (phi*180/Math.PI) + (nu*180/Math.PI)) % 360; } It's the same answer I got when I did this problem, so I use the code as a quick reference.

Thermometers don't work in space for similar reasons that barometers don't: there is (almost) nothing there to measure. Thermometers work by exchanging heat with their environment, both through collision and through radiation. In an atmosphere, air molecules hit the thermometer and exchange heat with it. There are particles in interplanetary space. Almost entirely the solar wind. The solar wind is predominately protons and electrons ejected from the Sun. At Earth-like distances from the Sun, the solar wind density is tiny: often in the range of a few to tens of particles per cubic centimeter. At that density, they can not come into thermal equilibrium with a thermometer. If you slapped a thermometer on a spacecraft, all you could measure is the temperature of the spacecraft due to solar radiation. That is valuable info, but not a measurement of the environment. Yes they have, but not with thermometers. Here's some data going out to about 70 AU for the solar wind proton temperature: ftp://space.mit.edu/pub/plasma/publications/jdr_radial_temp2/jdr_radial_temp2.withthumbs.pdf TL:DR: until about 30 AU, the proton temperature falls off at about 1/T^0.5 to 1/T^0.7. After that, it starts to heat up again. So this brings up the question of what temperature means. One thermodynamic definition of temperature is the average kinetic energy in a system. A glass of water at room temperature is surrounded by air molecules with the same average kinetic energy as the molecules in the glass and the molecules of water. Thermal radiation and particle collisions even out the average kinetic energy until all parts have the same temperature. In space things work a bit differently. Solar wind particles don't interact the way gases interact for multiple reasons: they are low density charged particles in a magnetic field. In fact, the solar wind electrons and protons typically have different temperatures! The electron distribution and the proton distribution don't interact so much on a particle by particle basis, but instead as a group. As a result they don't readily come into thermal equilibrium with each other. One way you measure plasma temperatures is by measuring the velocities of a large sample of solar wind particles and fitting the distribution of velocities to a Gaussian distribution to determine the bulk properties: density, average velocity, temperature, pressure. This is one of the ways Voyager and many other spacecraft measure temperature. You can also measure temperature by looking at plasma waves. You can associate a temperature with the solar radiation spectrum, but really it's the intensity or energy flux that matters. That temperature won't change as you get farther from the sun. You can sample the relative flux vs distance from Kerbol with a solar panel though. I haven't checked, but I hope they follow a 1/r^2 relation. That is just measuring the fact that the solar panel is catching a smaller patch of sunlight farther it is from the sun. The temperature difference between sunlight and planetary shadow isn't really a sensible question. The temperature of what? Solar radiation just passes through space more or less unimpeded. It doesn't have a big effect on the plasma temperatures. Space isn't so much hot or cold as it is empty. The temperature of a spacecraft or a Kerbal on EVA on the other hand is a sensible question. So I think it's good that thermometers only function near bodies. Though I do agree that they could give a zero science value report, rather than an error message.

Another method which can be used sometimes is to target another body with a known inclination, and mouse over the ascending or descending node to see the difference in inclinations. Example 1: Once you know you have something at approximately 0 inclination around Minmus, you can target it to determine your inclination. Example 2: The Mun is at 0 inclination, so when orbiting Kerbin, you can use the Mun to find your inclination. You just have to drop a maneuver node and play with it until you get the line of nodes to appear.