mhoram

They were originally optimized for partcount and not for costs. Optimizing for cost requires a completely different approach and would simply not fit into this line of lifters. If you are looking for cost effective lifters, you can get a few ideas in the Cost-Effective Lifters Challenge.

The speed of an object at periapsis and apoapsis is quite eays to calculate. Have a look at chapter 11 Orbital Mechanics of the PDF here: https://github.com/mhoram-kerbin/ksp-physics-documentation/releases I did not yet try to calculate the speed on other points on the orbit.

Thanks! They are just the numbers needed to configure the Mech-Jeb Ascent Path in the order of appearance in the MJ-GUI. Orbit altitude: 75km Turn start altitude: 10km Turn end altitude: 75km Final flight path angle: 0° Turn shape: 40% I always assume of the Orbital Inclination to be 0°. If you use a different value, then you will need more fuel. I did all my tests with Corrective Steering switched on, but it should also work, if it is turned off.

Thanks for sharing. Another dV-Map that has a good reputation is: http://forum.kerbalspaceprogram.com/threads/41652

Have a look at my Lopac Lifter Family. 10-520 ton Payload With a quite low partcount. http://forum.kerbalspaceprogram.com/threads/74395-Low-Partcount-Lifters

Use the Tsiolkovsky rocket equation dV = ve * ln(Mass Full / (Mass Full - Used Fuel Mass)) with ve = ISP * g0 You get ISP friom the description of the engine, and g0 = 9.82 m/s2 according to http://wiki.kerbalspaceprogram.com/wiki/Specific_impulse#Conversion_factor From all this you can calculate the Used Fuel Mass. Edit: 13.06kg/s is consistent with my calculations

Try f4. It toggles the ship labels. http://wiki.kerbalspaceprogram.com/wiki/Key_bindings

@WildLynx Another Exception are Fuel Ducts. Docking also does not lead to a circular station. There is always a single Docking Port that has the connection in the part-tree.

You will find all Karbonite related information in the Karbonite-Thread. Especially: So you should have no problems.

You might find some info on that issue in this thread: http://forum.kerbalspaceprogram.com/threads/29788-How-to-calculate-lift In Stock KSP drag is directly proportional to the mass of the ship, so you do not have a big influence on the mass/drag ratio.

Have you had a look at the following mods? I find them quite essential. http://forum.kerbalspaceprogram.com/threads/72212-Jebretary-Automatic-Version-Control-%28backups%29-for-craft-and-saves-v0-4-0 http://forum.kerbalspaceprogram.com/threads/47863-0-24-2-Precise-Node-1-1-0-Precisely-edit-your-maneuver-nodes http://forum.kerbalspaceprogram.com/threads/50524-0-24-Enhanced-Navball-1-3 http://forum.kerbalspaceprogram.com/threads/35018-0-24-2-PartCatalog-3-0-RC7-%282014-08-18%29 http://forum.kerbalspaceprogram.com/threads/92511-0-24-2-PartArranger-1-2-Arrange-your-part-list-however-you-want!

Description of KSP-relevant physics is distributed on many places. I made an effort to gather them: http://forum.kerbalspaceprogram.com/threads/93426-Physics-of-KSP

According to "The Definitive Guide" to all obtainable science in the universe the global maximum is 56981.

As soon as you start your inclination change burn, your velocity vector changes, so you would need to adjust your heading continously in order to burn at an angle of 90°.

Once I had a closer look into ideal ascent paths for a ship from Kasuha that had a very low TWL-upper stage. The optimal ascent strategy for reaching a 75km orbit was to first get to an altitude of ~95km so that it had enough time to circularize at 75km. So I agree that steep ascents are advisable for low-TWR-late-stages.

Very cool sites! Thanks for sharing.

That is true, but Tavert is: Mass-optimal engine type vs delta-V, payload, and min TWR

@Pecan Thanks for inviting me to join the discussion, but I belive that I can not provide any additional knowledge about the OP to what has already been said. @EdFred Keeping the Time to Apoapsis small during certain phases of the ascent can be efficient, since this is the most efficient way to rise the Periapsis. So I would not worry about being very near to the apoapsis especially since this means that you don't have too many engines. And I agree that MJ is bad at bringing certain rocket-TWR-configurations in an efficient way into orbit - especially when low-thrust-stages are involved. This brings me to the idea that it could be interesting to extend my Ascent research with PSOPT to include a display for "time to apoapsis" but this would require some serious calculating to be done.

A while back Temstar wrote a good guide on selecting and configuring engines based on payload mass.

Short answer: yes all orbits in this patched conics implementation that is based on Kepler celestial mechanics intersect the equator. The Bit Longer Answer: An object in KSP can be represented by two methods: -Kepler Elements -Cartesian Coordinates of a 3D-Position and a 3D-Velocity vector. For Kepler Elements it is easily visible from the picture in the linked site that the orbit intersects the equator. For Cartesian Coordinates consider the following: The only force that is applied to the object in space is gravity from the central planet. This force induces an acceleration in the direction Obejct -> Planets Center Of Mass. So the Velocity Vector changes in the direction of the Planets CoM. Lets take the following: - Position of the Object - Planets CoM - Velocity Vector of the Object. These three together describe a well defined geometric plane in the 3D-space. And since the Gravity-Force is a vector that is parallel to this plane, the gravity changes the velocity-vector, but also only within this plane. This means that the movenent of the Object happens only within this plane. The equator also defined a plane in 3D-space. And the Planets Center of Mass happens to be in both planes, so both planes intersect. Two planes that intersect have a common line that lies in both on them and the flightpath of the object intersects this line in two points. So the object crosses the equator in two points. QED ;-)

For me the combination KAC + Precise-Node made external tools unnecessary. From KAC I get an estimation when the next Transfer window is available. Then I setup a transfer node around that time (+/- a few days makes usually no big difference). Using the Time- and Node- "+/-" buttons of Precise-Node I search for the departure burn (within a single orbit) with the lowest dV that ends up within the target's SOI and has the lowest Periapsis (Centering the view around the target body hepls with this). For target bodies that are on an inclined orbit the procedure gets a little bit more complex since it mostly involves a mid-transfer-course-correction node, but the basics are the same. If I want the transfer time to be shorter, then I just perform the departure burn a few days earlier and if I want to make a transfer later, it costs more dV and lasts longer. And the cool thing about this procedure is that I do not have to know anything about ejection and phase angles. The ejection angle comes automatically from playing with the "+/-"-buttons and the phase angle from the KAC departure-time estimation. The KSP-Node-GUI is unfortunately not exact and predictable enough to use this procedure reliably, so trying Precise-Node for the first time was really an epiphany for me.

Try to adjust the departure node to the other side of Kerbin. You can use the Precise-Node "+/-"-Button in the UT: line to do this. The Time of the node should be around 15 minutes later. While doing this you can also see the transfer orbit change to get nearer to Duna.

Nice job on the other planets. Have not seen this done before. About the approximation for KOS import: Have you had a look at Lagrange polynomials with a Legendre Gauss Lobatto grid? That is the way PSOPT approximates the solution and is described in chapter 1.6 of its manual. I find the method very promising and should get rid of the trigonometric functions. And thanks for the KOS script. I will have a look at it.

I made an overview of the different staging methods. have a look here: http://forum.kerbalspaceprogram.com/threads/75669-Staging-Methods-Overview?p=1073989&highlight=Onion Basically it is similar to asparagus.

Most stock 20%+ payloadfraction designs are extremely specialized and lack in other fields like cost or partcount. here are a few examples.