mhoram

I just stumbled on this thread about calculating lift.

I did some tests with hohman-transfers from a Kerbin-like Orbit around the Sun to the other planets. Since Moho is on an eccentric orbit, the ÃŽâ€V for circularization depends on where Moho is on it's orbit when you reach it. If Moho is near its Periapsis around the Sun, I needed ~2000m/s for the circularization burn. If Moho is near its Apoapsis around the Sun, I needed ~3100m/s for the circularization burn.

The exact stock calculation of drag is described in the wiki page about atmosphere.

@Justin Kerbice The intended Payload mass of the Lopac 24 is 180-240 ton. Your payload seems to be around 40 ton, so the Lopac 04 should be able to lift it into space. I did not test the ships with underdimensioned payloads. It is also known that the new large decoupler TR-38-D has some problems.

A while back I held a challenge about efficient rockets with respect to payload fraction. You might find a few ideas there. I usually design my rockets from top to bottom and try to keep TWR as low as possible while still being able to fulfill the goal I have in mind for the respective stage. A low TWR means less mass for engines. If you don't use addons, try to reduce the number of engines and see if you can still get to orbit. If not, then you probably need the engine. Another thing to keep in mind is the ISP of the engines. A engine is more efficient, if it's ISP is higher - this value is visible in the VAB.

A while back Tavert did some calculations on the topic of efficient landing using this horizontal trajectory method.

About the looks: I focus rather on function than design ;-) so I know that the Moonshine lifters will win in that category. Thanks for the info about the unexpected rotation. I tried to build them with large payloads in mind and tested them as displayed in the OP and here are pictures from a launch with a massive payload and they worked resonably well. If you PM me your ship, I could look into the reason for this behaviour.

On several occasions I had a design with a TWR near 2 during the vertical ascent and wanted to squeeze out a little bit more dV and reduce mass while still being able to reach orbit. In nearly all of these cases I reached this goal by removing engines and adding fuel. I always assume that the payload does not participate in the ascent. This means, no fuel or engines from the payload is used during the ascent. I never counted the engines of my upper stages as part of the payload and payload fraction - the ability to use them for the payload is just a bonus of that particular design. I had a picture of this designconcept in this thread.

While building rockets optimized for payload fraction and hosting a payload fraction challenge, I came to the conclusion that it is more efficient to have more fuel and less engines (TWR starts at about 1,5 at liftoff). If the focus is not payload fraction, other values are probably more fitting.

I think it is this one:

I have a few ideas: How fast is the velocity difference between the two ships? It should be less than lets say 1m/s Do you use the same docking ports on both ships? (there are three different ones: junior, normal and senior) The docking ports should be aligned to each other (angle should not be larger than lets say 5-10°) Each docking port has two sides and only one of them is capable of docking, but not the other. So be careful with the orientation. (pictures would be helpful for finding the problem)

In a recent interview Felipe gave a reason for not including a Delta-V display in stock KSP. http://forum.kerbalspaceprogram.com/content/280

While there are good Delta-V (ΔV) Maps available, they all rely on departure burns in Low Kerbin Orbit (LKO) and an understanding of Phase and Ejection Angles. Beginners that do not yet feel comfortable with these concepts might try to reach other planets without these advanced maneuvers and ask themself if their ship has enough fuel/ΔV to accomplish the task. While Stock KSP does not display the ships ΔV, Plugins like Kerbal Engineer Redux can help with that. So I put together a ΔV map for the most simple flight path to other planets: Get from the launchpad into a 75km LKO Escape Kerbin's Sphere of Influence Change the inclination to match the one of the target planet Perform the first Hohmann-Transfer burn Fine adjust the trajectory to a low orbit around the target planet Perform a circularization-burn in the low orbit around the target planet Pre V1.0 Version: The ΔV-Values are just a bit larger than the minimal amount needed, so build your rocket with spare fuel. Since most planets are on an eccentric orbit around Kerbol, I gathered data for the minimal and maximal ΔV needed in the columns "Intercept / first Hohmann Burn" and "Circularization @ altitude". I did not include Moons, because the ΔV needed to reach them is smaller than the ΔV needed for the circularization burn at the Low Orbit. Efficiency Here is a comparison with the values of this ΔV-Map for a flight from the launchpad to a low orbit around the target planet. Planet Advanced flightpath Simple flightpath Moho 10040 10550 Eve 6280 6950 Duna 5100 6150 Dres 7260 8800 Jool 8570 10400 Eeloo 8190 9150 So the method described here is a lot less efficient, but at least more easy to accomplish. Reduction of needed ΔV There are several kinds of maneuvers available to lower the amount of needed ΔV. Departure Burn in LKO to utilize the Oberth Effect Aerobraking to reduce the circularization burn to nearly zero m/s at planets with an atmosphere Gravity Assists Version 5, License: The best part for me about putting this map together was, that for the first time I laid my eyes on Jool and it's moons. :-)

It seems like the texteditor in this forum is based on ckeditor and there are recent latex addons available. I would really like to see latex-support added in the coming forum-update.

Cool tool! Have you had a look at GitCraft v0.9b2 -- .craft revision management using Git?

I also find this calculation a bit hard to understand. So i tried to do it by hand. The goal is to calculate s, given FOW, Alt and R. We get s by the equation R*cos(s) = d. d can be calculated by setting the path of the planets surface equal to the edge of the field of view. Path of the Planet's surface: y2 + x2 = R2 Path of view's edge: y = (R + Alt - x) * tan(FOW/2) Merging the two equations: (R + Alt - d)2 * tan2(FOW/2) + d2 = R2 This is a quadratic equation in d. So lets bring it into normalform. ((R+Alt)2 - 2 (R+Alt)d + d2) * tan(FOW/2)2 + d2 = R2 (1 + tan(FOW/2)2) d2 - (2*tan(FOW/2)2 * (R+Alt)) d + 2R*Alt + Alt2 = 0 The solution to a quadratic equation of the form ax2+bx+c=0 is x = (-b ± sqrt(b2-4ac)) / (2*a) In our case a, b and c are: a = 1 + tan(FOW/2)2 b = - 2*tan(FOW/2)2 * (R+Alt) c = 2R*Alt + Alt2 And we get d by d = MAX(-b+sqrt(b2-4ac), -b-sqrt(b2-4ac)) / (2*a) (the edge of FoV intersects with the planets surface up to two times, in this case we need the larger d) And s by s = arccos(d/R) In the case that b2-4ac < 0, there is no solution, meaning that the Field of View contains the whole planet. Hm ... guess I am still not wiser about the cot in the original code, although it seems a similar procedure is appiled to calculate the swath not by d but by S that is most likely S = sqrt(R2 - d2) - the vertical distance between the right end of d and the planet surface intersection. hFOV is likely the half of FOV. Two things I find strange. One is why Alt does not appear in the first term within the sqrt. And the other is that the b-term in my calculation is quadratic, while in the original code it is not.

1) Onion Staging is a superset of tri-symmetry. 2) I did not want to mix the staging methods for simplicity of this overview. 3) A quick search for Zistu staging was not successful. Du you have a link with a description of that method?

I like this heavy stuff! Since you asked in your video, there was a video with a payload of 750 ton (coming from a previous KSP version) and the heaviest payload I know about so far is 2034 ton. About the partcount: with the new parts, a payload-tons : lifter-partcount ratio > 3 can be achieved (see also my Lopac 52).

You could try alterbarons aerobraking calculator.

I think my Lopac Lifter Family would fit nicely here 10 - 520 ton to a LKO Partcount is quite low. The 520 ton lifter has 159 parts. The Downloadarchive on the main forum site contains the ships, ships with payloads and subassemblies.

Yes, in that graph the red and green lines are pitch of thrust and prograde (wrt. planet's rotational frame of reference) respectively. and the red line is below the green line.

A while back I was working on an autopilot system for ascents with the help of PSOPT. It consists of two parts that communicate via Sockets (both released under GPL V3): - An Optimizer named Aptor Server that uses ships data to approximate the ideal ascent trajectory with the help of PSOPT. - A KSP-Plugin named Aptor that reads in the VAB the ships data and exports it to the optimizer. Originally I intended to extend this system in order to automatically receive the ascent path description and perform the ascent, but I was unable to solve some kinks of the optimizer that made the system very userunfriendly and other stuff got more important. Since I probably will not continue with this project I wanted to share it ... just in case someone finds it interesting. I did not test the plugin with V0.23.5. The optimizer is based on alterbarons work and the major improvement is that ships with more than a single stage are supported.

and if you do want to go into such technicalities, I can also recommend these threads: I need someone help me do some math for launch optimization Launch Efficiency Exercise V0.21.1 Most of my simulations suggested to thrust slightly below prograde during the majority of the ascent with Kasuha's example ship being the only exception because of it't low TWR in the last stage.

That sounds much more simple than what I suggested in my post ... Did not know about the swath width. Sometimes I happen to travel "between" two kethane hexes, so perhaps it might be necessary to use a smaller swath width than 2.25.

I finally understood of the Oberth effect from the answers in this thread: http://forum.kerbalspaceprogram.com/threads/60250?p=814201#post814201