mhoram

Once upon a time there was a Comic about the Oberth Kuiper Maneuver. I downloaded the V0.18 demo. The feature that made me buy the game instantly was the capability of planning series of maneuver nodes with predicted paths in mapview. It was v0.21.1 at that time. The rest is as you can say history.

@Ampere: The folders look ok. Sorry, but then I have no idea what the reason for your problem is.

This is a good indiacator that you have installation problems. Can you post a picture of the contents of your GameData\UmbraSpaceIndustries folder? As far as I know it is only possible to configure if the orange suits are affected when they run out of supplies. But they always consume supplies when supplies are available.

Just stumbled upon http://forum.kerbalspaceprogram.com/threads/124501 Looks like it would fit into this list.

1) If the target inclination is not 0°, then it gets tricky. As an alternative you can adjust your inclination after reaching orbit to match the one of your target. Adjusting a 6-7° inclination difference does not take that much dV. 2) For the transfer between two orbits you usually use a Hohmann-Transfer consisting of two burns. The dV needed consists of the following - velocity difference between your current orbit and the transfer orbit at the location of the first burn - inclination change - velocity difference between the transfer orbit and the target orbit at the location of the second burn Calculating the velocities of your ship in the three orbits is done via the Vis-Viva equation. For calculating the dV for the inclination change you can find the relevant formulas here: http://forum.kerbalspaceprogram.com/threads/69036

And regarding Maths: 1.08 u/d means 0.00005 u/s 1.00 u/d means 0.0000462962962962963 u/s would you rather have to write 0.00005 or 0.0000462962962962962962963? ;-) The first variant is much cleaner.

@forsaken1111: The teasers were a few pages back: http://forum.kerbalspaceprogram.com/threads/116790-1-0-USI-Life-Support-0-1-0-2015-04-27?p=2143004&viewfull=1#post2143004 http://forum.kerbalspaceprogram.com/threads/116790-1-0-USI-Life-Support-0-1-0-2015-04-27?p=2170973&viewfull=1#post2170973 http://forum.kerbalspaceprogram.com/threads/116790-1-0-USI-Life-Support-0-1-0-2015-04-27?p=2185310&viewfull=1#post2185310

Some mods use KSP-AVC to notify users about new releases and version incompatibilities. Some of the mods you stated did not receive an update after v1.0.4 came out but function properly. Usually I get rid of the messages by - finding the version file in the appropriate GameData folder and - editing the compatible version number to 1.0.4.

You measured the two velocities at different altitudes, you you can not simply substract them. At the higher altitude (end of the burn) you are traveling slower than at the Periapsis which is normal for Kepler orbits. So you burned more than the 588 m/s dV. And as a small side note: in a 99x101 km orbit your minimal velocity (at apoapsis) is 2242 m/s which is higher than your measurement of 2234 m/s.

@vasco: Here are the numbers: https://github.com/BobPalmer/MKS/wiki/One-Kerbal

Have a look at Jebretary to avoid this problem in the future.

And for this method, there is also an addon available: http://forum.kerbalspaceprogram.com/threads/85838

Another idea would be to go to the file GameData/CommunityResourcePack/ResourceConfigs/Water.cfg and change MaxAbundance for Minmus. However I have never done that and there might be unforseen consequences. Also this would change the settings not only for this savegame but all savegames.

search in persistent.sfs for this section: SCENARIO { name = ResourceScenario scene = 5, 7, 6 RESOURCE_SETTINGS { GameSeed = 1234567890 MaxDeltaTime = 21600 } } And change the GameSeed value. That way you can change the resource distribution of all planets. A simple add X to Minmus is not possible as far as I know.

they would crash. When you are in an 75x75 km you travel at a speed of ~2287 m/s When you are in a sub-orbital 75x0 km orbit you travel at 75km altitude ~2219 m/s So the velocity-difference between the two vessels is ~68 m/s For the calculation Vis-Viva is your friend. https://en.wikipedia.org/wiki/Vis-viva_equation

The V1.0 atmosphere became much more complex that it was before. So doing atmospheric precision landings became really tough. Even with the trajectories mod I am happy when I get within 10km of the spaceport. The following method should get you to a precision landing: 1. above the atmosphere reduce your orbital velocity to match the planets rotation speed 2. adjust your position to be exactly above the place where you want to land 3. descend through atmosphere The viability of this method is however limited by a few factors: - huge amount of dV for reducing the orbital velocity - additional dV needed for slowing down the descent - fast reentry makes additional protection against heating necessary

While the infos about the atmosphere and engines are outdated, you can find many aspects about the orbital calculations in my Physics of KSP documentation.

It is just the same with TWR, which usually is taken in the meaning "TWR at Kerbins sealevel". Usually the wording "payload fraction" is used in context of "payload fraction from the launchpad/runway to Low Kerbin Orbit".

Nostalgia is coming: http://forum.kerbalspaceprogram.com/threads/56791 ... with a bit different ruleset.

@nothingSpecial: the payload fuel was only used for orbital maneuvers after reaching a stable orbit and deorbiting the launch-propellant and engines. Sorry for the ambiguity.

In order to make this a bit more complicated, i once created a family of lifters based on the schema below. Usually the payload contained fuel for the engines of the engine deck which stayed in orbit. However the mass of the engine deck did not count in my interpretation as part of the payload.

@windows_x_seven: This is called the Lambert's problem. The wikipedia site contains the formulas for the calculation.

Great results! May I ask what software did you use for the simulation?

Usually this problem comes from browsers or internet providers, who compress the picture on the fly. So I recommend that anyone with this problem should check their settings.

Thanks for confirming my suspicion, that this is unchartered terretory. I did some tests with a 708 part monster with KerboKatz PhysicalTimeRatioViewer. With 12-sided Mesh colliders I reached 30-31% With 6 Unity Box colliders I reached 21-22% So it seems like in this case Cylindrical Mesh colliders work faster. However since I never made such a comparison before, I am not quite confident, if this measurement is reasonable. If someone wants to make some tests on their own, here is a zip containing the parts and ships: https://www.dropbox.com/s/n70awzxe3kcfy43/Colliders.zip?dl=0