mhoram

I wanted to make it more comprehensive and think that overview fits more. And that is exactly the reason why I think that they are not used in the best way possible (main diffrence to Asparagus staging). I do not want to include mixed staging strategies, as this would complicate this whole tutorial: there are so many different possibilities. Agreed, but for the simplicity of this overview I keep the pictures as simple as possible. Timing of starting engines is a concept that I do not want to include for simplicity reasons, but this sounds a bit like serial staging with a horizontal build form. After thinking for a while about this, it makes sense, to distinguish serial and parallel staging by the question "Do engines from different stages burn at the same time?" and leave the fuel routing out of the question. Will update the pictures accordingly. Thanks for the info about slack tanks ... will add it. According to the original post where Breadcrum staging was mentioned, mutiple tanks were dropped ad the same time. So I think that it makes sense to call drop tank stages "Breadcrumb staging" no matter if only a single or multiple tanks are dropped at the same time. And Bamboo/Train staging is just a subcategory of this.

Thanks for adding my staging overview.

Calculating it by hand is not easy. If you don't use FAR, then you can find good information in these threads: I need someone help me do some math for launch optimization Finding the best ascent path for rockets Launch Efficiency Exercise V0.21.1 Ascent Komputron (Standalone Software, not open-source, did not try it myself)

Actually no, since the SAS module tries to rotate in itself. The following picture shows the forces that RCS and SAS produce when turning counterclockwise. Edit: @Kasuha nice test setup

Nicely done! For Kethane the calculation will probably be a bit trickier, since the field of view depends on the altitude. I would take the following approach: Around the equator there are 160 cells So each cell has a minimal diameter of 360°/160. Possibly the pentagon cells have a smaller diameter. But since there are only 12, lets forget about them. The field of view should be calculated so that it views an area on the planet that has this diameter. a = altitude of the scanner above sealevel d = 360° / 160 (diameter of a single cell) rc = rplanet * cos(d/2) (radius to the place of the cell) hc = rplanet * sin(d/2) (height of the cell) b = a + (rplanet - rc) (distance between scanner and place of the cells) The field of view can then be calculated as f = 2 * tan-1(hc /

I concur that all SAS units of the same type provide equal force. However positioning has an effect upon how this force is utilized. This force can not only be used to induce a rotation but also a movement. Imagine a long rocket, say 20 tanks and at both ends there is a SAS module (do not forget energy and command module). Rotating this ship with SAS will bend it, so that it looks like a very slim "S". Bended objects in KSP will try to return to their original form. It is similar to a spring that oscilates until it is in it's original position. This means that there is some kind of friction that reduces the oscillation. So less than 100% of the physical energy generated by torque is used for the rotation. Some is lost in this fricion. I have however no idea about the magnitude of this loss. For positioning I had the following impression: "the farer away from the CoM SAS modules are placed the more the parts bend." So I try to place them as near to the CoM as possible. Another thing to keep in mind is that a SAS unit can apply three times its torque at the same time (one for each rotation direction) but it uses also three times the energy from batteries.

While there is a good description about the workings of gravity assists in the thread http://forum.kerbalspaceprogram.com/threads/54294-Gravity-Assists I miss somehow a condensed visualization of the process. The wiki page also scratches only the idea. For this I created this small set of pictures of a gravity assist with the Mun inside Kerbins SOI. Scaling and trajectories are a bit off, but should suffice as a simple visualization. While trying to keep the information to the bare minimun, I had hoped for much simpler pictures. This case describes a gravity assist that accelerates the ship. Simple rule: Pass the Mun behind it's oribital course to accelerate. Pass the Mun in front of it's oribital course to decellerate. Suggestions for improvement welcome.

Would you like to include this thread: http://forum.kerbalspaceprogram.com/threads/74501-Showcase-0-23-5-Lifter-Designs There were a few launchers above 1000 ton payload capacity. I managed so far 520 ton.

Welcome to the forum! 1) For landing you should orbit the planet in the same direction as it rotates (heading should be 90° and not 270°; same is valid for launch). The reason is that in this way you need less dV to land as if you were going the other way round (this is especially important for planets without atmosphere). 2) Try and error or http://alterbaron.github.io/ksp_aerocalc/ 3) Gravity assists only take effect when Sphere of Influence changes are involved. Since you only want to stop at Duna, there is no gravity assist. 4a) http://forum.kerbalspaceprogram.com/threads/39812-Landing-and-Takeoff-Delta-V-vs-TWR-and-specific-impulse 4b) This is a very complex question - best answer I can give is: it depends. But the question "At what point to burn to use least amount of fuel?" is more easily answered: The faster you go, the more you get from your fuel. It is called Oberth effect (explanation) 5) there are dV maps available: http://www.reddit.com/r/KerbalSpaceProgram/comments/1iw30a/a_more_accurate_deltav_map/ http://wiki.kerbalspaceprogram.com/wiki/Cheat_Sheet http://forum.kerbalspaceprogram.com/threads/25360-Delta-V-map If no atmosphere is involved, then the dV for the return direction is equal to the departure direction.

No there is not. This is a sandbox game, where everyone has his own goals and for each goal there are multiple ways to achieve it. I think it is an acomplishment to have such a station. And about the debris: one of my goals is to keep the orbit clean of it, so I design my rockets and refueling-ships accordingly.

I played around with different transfer orbit periapsis altitudes and the differences for the graph are not large in the range 70-100km. One additional information is quite relevant: when to use exactly a single and when to use a double burn via a 80km x current altitude transfer orbit. This graph shows it. (GPL V3 licensed source code) It uses basically the same setup as Starstrider42: Take the altitude of your circular starting orbit and locate it on the horizontal axis. Take the desired excape velocity at SOI and locate it on the vertical axis. Be aware that this is not the dV value you see on the dV-charts. The markers on Starstrider42s graph should help you get the magniture for different planet targets. On Starstrider42s chart you can see by the color of the resulting x-y-point how much dV you have to spend to achieve this transition. On my chart you can see, when to use a direct burn and when to use a double burn via a 80km x current altitude transfer orbit. Say you are on a circular orbit near Minmus and want to go to Jool. Starstrider42s graph tells you that you need an escape velocity of ~2750 m/s for Jool. According to my graph, a double burn is more efficient. The total dV you need in order to reach Jool is then about 1250 m/s. Edit: And in order to get back to the OP's question: If you want efficient single-burn post-refueling transfers, then a refuelingstation near SOI is not recommendable. If you want a refueling station from where to start most fuel efficiently, then placement near SOI is recommendable.

By putting the refuling station into an 80x80000km orbit you gain some benefits, but you lose the ability to to chose the phase angle for departure - or would need to make the ejectionburn not at the 80km periapsis of that orbit, but at a higher altitude where the oberth effect is not that effective. And also the rendezvous with that refueling station will be harder to achieve than with a circular station.

Found this problem at the same time as you. And at this point you assume that the velocity difference (between Kerbin and the transfer orbit periapsis) can be set equal to the escape speed at the SoI boundary. From there it is quite easy to calculate the needed velocity at 80km periapsis within Kerbins SOI and calculate the difference to the 80 x altitude orbit. Thanks for the explanation. Clever idea! I also don't think this is much of a stretch.

My mistake - you are right. I am familiar with these formulas as far as no SOI-changes are involved, but the point I do not understand yet is the transition between Kerbin's SOI and Sun's SOI. As far as I understand it, a Hohmann transfer is only a valid approach, if no SOI changes are involved, but in this case there is a SOI-change between the burn at the 80km Kerbin periapsis and the arrival at the target planet. So in this case it is at best an approximation and I can not tell, how good this is. Let's take an example as I understand the method according to your description: going from Kerbin to a circular orbit near Duna (values are very much rounded) Please correct me, when I deviate from your calculations or make an error. Kerbins Semimajor Axis: rK = 13599 Mm Sun'S mu: 1.1723328×1018 m3/s2 Let's chose the target orbit around Duna Target Semimajor Axis: rD = 20000 Mm (assumption of a circular orbit) From here we can calculate: Kerbins orbital velocity: 9285 m/s Eccentricity of the transfer orbit: eT = (rD - rK) / (rD + rK) = 0.19 Semimajor of the transfer orbit: aT = 16800 Mm Velocity at periapsis of the transfer orbit within Sun's SOI: = sqrt(μ/aT) × sqrt((1+eT)/(1-eT)) = 10130 m/s Subtract Kerbins orbital velocity within Sun's SOI: 845 m/s At this point I am stuck what to do with this velocity.

I am sorry, but I am not sure if I understand the intention of this graph correctly. Lets assume X (horizontal axis) is the starting altitude above sea level and Y is the desired delta-V relative to Kerbin's orbit around the sun (vertical axis). I believe there are two burns involved. One from a X*X orbit to a 80km*X orbit within the SOI of Kerbin A second one from a 80km*X orbit within the SOI of Kerbin to the target orbit that differs by Y from Kerbin's orbit around the sun. I would find a graph interesting that sums up both burns, but your graph does not display that value (at Minmus starting altitude the needed dV would be larger than 900m/s for all target dV-values, because that is about the value needed to get into a 80km*Minmus orbit). So does the graph only display the value of the second burn? If one assumes that the refuelling station is in a circular orbit, this value alone is however not so important. I tried shortly to find a formula for the calculation of these interplanetary target dV values, but was not successfull. Can you point me to a documentation or paper.

@Red Iron Crown: thanks for the hints - never heared these names before. But I think Breadcrumb is not the same as Train and Bamboo.

I just put together a description of staging methods.

Based on this thread I thought it might be interesting to have a description of the different staging methods. Corrections and additions welcome. There are two classes of staging methods: serial staging and parallel staging Serial staging Serial staging is the classic way of staging. Each engine burns only during a single stage and is dropped after the fuel of this stage has run out. Pro: Allows a lean design for decreased drag in real life (has no physical relevance in KSP 0.23.5). No fuel routing required. Con: Engines are not put to best usage Parallel staging Parallel staging allows engines of different stages to burn at the same time. In most cases all engines are started at the begin of liftoff. Fuel routing between stages is optional. Pro: More efficient than serial staging. Con: Large shear forces at the end of stages. Fuel routing needs to be set up. There are two widely used subforms of parallel staging with fuel lines between stages: Asparagus and Onion staging. In some cases solid fuel boosters are used to help with the ascent. Asparagus staging A 2-times symmetry is used for dropping tanks. Fuel is only drawn from the outermost stages, that are ejected next. This method allows a fast dropping of unneded fuel tank hulls and engines while still maintaining a symmetrical rocket. Someone researched the origins of the name (forum post no longer available) (see here or here). Wiki Page Onion staging In onion staging rocket the stages are dropped like an onion in circular layers. Fuel is only drawn from the outermost stages, that are ejected next. While it is less efficient than asparagus staging because unused fueltanks are dropped later, it is more easily set up. Side booster staging I could not find a name for this method - any suggestions?. It adds the advantage of serial staging (no fuel ducts). The stages can be set up for a specific TWR-profile. Here is an example. Rarer used staging methods Drop tank / Slack tank / Breadcrumb staging This method is used if a decrease in TWR in later stages is not needed. Origin of the name Breadcrumb Bamboo / Train staging It is a subform of drop tank staging where the droptanks are in the axis of the ship. It is also similar to twisted candle staging where the engines are only placed at the last stage. Origin of the name Bamboo Origin of the name Train Pancake staging It is a subform of serial staging where each stage has multiple engines. (Original video is no longer publicly available) Twisted Candle staging A staging method that is more efficient than asparagus staging, since tanks are dropped at twice the rate than in asparagus staging. The setup is however even more complicated because one has to consider placement of engines. Origin of the name Twisted Candle.

@Starstrider42 Great chart! To see the optimal starting altitudes for high dV targets, a logarithmic horizontal axis could be more appropriate. Do you mean by height the altitude above sealevel or radius of the orbit?

I placed my refuelling station in a 300km orbit. I had two reasons not to put it to a 75km orbit. 1. 75km is the standard orbit for my launches, so I might accidentially crash into it. 2. A rendezvous between ship and station via a Hohmann transfer need some time until the angle between both objects fit (this time can be reduced by adjusting the launch time, which I often do not care about). The time spent waiting decreases with the difference between the orbit altitudes.

Nicely done - I know that it is a docking-nightmare. Back in 0.21 I tried to build a cube as my first space station, but abandoned and did not finish it because of partcount based lag.

With 0.23.5 I found that it is time to replace my old main station with a new one. Here is "Lin Core 2".

This page should help you with your question: http://wiki.kerbalspaceprogram.com/wiki/Key_bindings

I am going to try out this puller design with Class E asteroids

Just stumbled over http://kerbalspaceprogram.com/speed-unit-changer/ Did not try it however because SI units are much more natural.