mhoram

I can confirm this strange behaviour. Another way to deal with this situation is to add an unmanned command module to the ship. So it is not enought to have two kerbals in the Mobile Processing Lab.

A quick entry with 3183 m/s in orbit. There is more possible ;-)

You can find a good desctiption about efficient landing here: http://forum.kerbalspaceprogram.com/threads/39812-Landing-and-Takeoff-Delta-V-vs-TWR-and-specific-impulse

So I gave this Lifterfamily an update for 0.24.2. Some parts had their configuration changed in the latest update and this made some changes necessary. Also the TR-38-D is now fully functional and can be used. Added a logoflag. And finally in most cases reduced the partcounts of the lifters (Lopac 18 - Lopac 52 need less than 1 part per 3 ton payload).

If you are interested in simplicity more than efficiency to reach other planets, have a look at this info on simple flightpaths.

Dunas orbit has an apoapsis of 21783Mm and Periapsis of 19669 Mm. Kerbin has a circular orbit with a radius of 13599 Mm. To calculate the duration for a Hohmann-Transfer for the shortest and longest possible paths, the following formula is used: ShortTransferTime = SiderealPeriod(Apo=19669Mm, Peri=13599Mm)/2 LongTransferTime = SiderealPeriod(Apo=21783Mm, Peri=13599Mm)/2 And the sidereal period is calculated by 2À * Sqrt(a3/μ) where a is the semi-major axis of the transferorbit and μ the Gravitational Parameter of the Body that is orbited (in this case Kerbol). This result in transfer times of 288 and 316 Kerbin Days for Hohmann-Transfers from Kerbin to Duna. If you want transfer times of 150 days or less, then you definitively do not use Hohmann-Transfers. A good indicator for the question if a transfer is a Hohmann-Transfer is that Kerbol lies on the line between departure and arrival. No because transfer windows in the usual meaning have nothing to do with closenes. For a Hohmann-Transfer there exist ideal points in time where the ÃŽâ€V needed is smaller than in the range around it. The farther away you are from this ideal time, the more ÃŽâ€V you need for the transfer (local Minimum). The Transfer window is the timeinterval in which you need for the Hohmann-transfer less than "ideal-ÃŽâ€V + X", where you have to specify X.

Well ... not on the moon, but I had a similar idea. I had no problems with Lithobraking at a velocity of 50m/s ;-) (The Cathedral alone has 272 parts & ~72ton)

In order to get the new travel duration, just multiply the number by 4 (Earth Day = 24 hours, Kerbal Day = 6 hours). The ÃŽâ€V-Values did not change, so they are still in a reasonable range. Here are some other ÃŽâ€V-Maps.

The definition of KSP days has changed in 0.23.5 and the chart you use is from a time before 0.23.5. As for ÃŽâ€V: You will need according to the chart 1060 m/s to get an intercept with Duna. And additionally 370 m/s are needed to get into a low Duna-Orbit. A quick test on http://alexmoon.github.io/ksp/ also shows a way longer transfer-time to Duna of around 270 days. Another thing you should consider is that you need life support for a longer time than "flighttime to Duna + flighttime back", because usually there is no transfer-window for the way back at the time you arrive on Duna.

During KSP 0.16 there was a challenge for exactly this problem. If I remember correctly, the best solution for solving this Goddard Problem during the challenge was an autopilot that adjusted the ships velocity to match the terminal velocity. I played around in Career mode with different combinations of Altitudes/Velocities/Items to test. The craziest combination I had to try several times in oder to get the flight path right in a single launch - so try and error is another approach to solving this problem ;-)

Currently only the name of the part to be tested is displayed in the briefing. Since I don't know the names of the parts and have to look them up on the wiki-stockparts page, I want to suggest to include a picture of the part in the briefing description for a more simple recognization which does not require me to Alt-Tab out of the game.

@qazsedcft: Do you use jet engines on your ship? Calculation of their fuel usage is even more complicated than for rocket engines.

A while back there was a discussion about the efficiency of a two-burn strategy for leaving Kerbins SOI from a circular orbit. Such a "first burn retrograde, then burn prograde at Periapsis" approach can be more efficient than a single burn method. Have a look at this chart and the discussion for details. Decreasing Periapsis by a radial burn is an interesting idea ... never thought about that. However I believe that setting up this burn in a way that the Apoapsis points in the right direction is a difficult task - counterexamples welcome.

Have a look at http://forum.kerbalspaceprogram.com/threads/66216-0-23-GitCraft-v0-9b2-craft-revision-management-using-Git and http://forum.kerbalspaceprogram.com/threads/72212-Jebretary-Automatic-Version-Control-%28backups%29-for-craft-and-saves-v0-3-2

More is always More! And do not try to land on Minmus. You will encounter the Kraken.

There are differences in total delta-v usage. Starstrider42 made some calculations about this question. See http://forum.kerbalspaceprogram.com/threads/75542?p=1072850&viewfull=1#post1072850 Further on in that thread the idea of 1) drop Periapsis to 75km 2) rise Apoapsis to escape SOI was discussed. As it turned out this method can be more efficient.

The staging issue can be solved by adding empty stages 1,2,3,4,... to the saved subassembly. If your new craft uses stages 1 to 5 and your subassembly uses stages 10 to 15, the resulting empty stages 6 to 9 get deleted automatically after attaching the subassembly and the staging of new rocket and subassembly do not mix.

Most Delta-V Maps assume that you burn the 950+80 m/s in Low Kerbin Orbit. If you want to first leave Kerbin's SOI and burn afterwards to Eve, have a look at this Delta-V map that handles exactly this case.

The slower you are, the cheaper inclination changes are. So I would suggest: 1. Drop your Periapsis to the target-orbit (so that you have an elliptical orbit). 2. Change the inclination at Apoapsis of the now elliptical orbit. 3. Drop your Apoapsis to the target-orbit. As a side note: If you want to change the inclination by a lot (>60°) it might be more efficient to raise the Apoapsis up to SOI.

@lunait: Thanks for your submission. According to the craft file, you used KSP Version 23.5. But as stated in the OP this challenge closed with the arrival of KSP 23.5, because of ingame-engine-changes. If you want to start a new payload fraction challenge, go for it but I would like to keep the results of this challenge 23.0-consistent for fairness.

You can also find some info in this thread. Warning: contains physics and code.

Too bad I will be on vacation, so can not participate. Since I want the forum to win, pick teams with experts in - rocket building - gravity turns - plane building - plane flying & landing - VTOL building - VTOL flying & landing - rover building - rover driving - interplanetary transfer - landing on airless bodies - gathering Science data - precision landing - gravity assists - aerobraking - other possible areas ... and who have time. Good luck to all. Sounds like a great competition!

Most KSP-relevant terms (including prograde) are explained on http://wiki.kerbalspaceprogram.com/wiki/Terminology. Otherwise wikipedia or an internet-search can be used to find answers for these kind of questions.

I just remembered a configuration guide for rocket clusters by Temsrar for asparagus staged rockets. He explains how to calculate the thrust needed for different stages to get into orbit. There is also a calculator available based on this description. There is no single right combination of ascent parameters that fit all rockets. Each rocket has it's own ideal ascent path. These are Perl scripts. You will need a Perl interpreter to run that program. If you manage to get "liftoff.pl" to run and need an introduction guide, feel free to contact me. Trial and error seems the way to go. If you find a way to automatize the building procedure of rockets to get perfect gravity turns, I would be interested.

This writeup might answer your question. http://www.projectrho.com/public_html/rocket/multistage.php Calculating the gravity turn could be done by simulating ascents based on real-life gravity turns. The real-life gravity turn consists of the following stages: 1. Vertical ascent 2. Pitchover maneuver (Orientation of the ship is no longer vertical) 3. Downrange acceleration (Orientation of the ship is equal to prograde, Prograde changes because of the gravity force applied to the ship) 4. Circularization (Circularization when the orbit altitude is reached) This gravity turn can be described (in a simplified form) by the following parameters: - Altitude where the vertical ascent stops - Angle of the orientation during the pitchover maneuver - Duration of the pitchover maneuver - Altitude of Circularization (other parameterizations are possible as you like, for example duration of vertical ascent) (more details could be: turnrate of the ship during pitchover, how long before reaching the orbit the circularization burn begins, ...) With this parameterization an ascent can be simulated based on the three forces that have an impact on the rocket: - gravity - air resistance - thrust (Don't forget that planet and atmosphere rotate) Calculating them for small timesteps the course of the ship can be approximated quite good. And at the end of the simulation you know if the chosen parameters were good or bad. Based on the quality of the parameters, in an iteriative procedure better parameters can be found until you get parameters that satisfy your needs. In this post you can find a link to a program I have written that does an optimiziation of such a gravity turn with respect to fuel usage for stock KSP. I know that this is not exactly what you asked for, but it might give you some ideas. Air resistance in FAR is quite more complex than in stock KSP, so for designing such a simulator, you will need a way to calculate it.