Overengineer1

1.2.1 released for all you inclined tweakers.

GT requires a MechJebCore module on the ship to do the circularization burn. It looks like MechJeb For All just adds a MechJebCore module into all command modules. In that case, GT should see that MechJebCore and instruct it to do the circularization burn.

@vardicd Well then you have 2 problems: Lots of drag up front, and a lack of positive control. If you use the R8 fins, I think it would work. Or a Swivel engine would probably be enough. And losing those radiator panels. Any one of these would probably help, all 3 wouldn't hurt. The version currently in development is slightly more intelligent about how it handles pitch, which may or may not help in a situation like yours. But it's not ready yet.

Are you saying we are looking at version 0.9 in this video? Well, there's your problem. I'll add code in the next release to disable GravityTurn for an unsupported game version, since the aero parameters in older versions invalidate the calculations that GT does. Sorry, either upgrade your game, or keep playing the way you were before.

@mcirish3 I whipped this up from the API. X-axis is altitude, y-axis is pressure.

That ship is very long, and has lots of stuff up top for the wind to catch. In particular I really don't think you need those radiator panels. It also looks like it will wobble quite a bit. That wobbling will amplify the drag caused by those radiator panels. If you just want to go to orbit, you have overbuilt that by quite a lot. Take off the boosters, lose the radiators, and cut the lower stage in half. If you want to go to Mun, just add fuel to the upper stage, not to the lower stage that you reduced by half.

@vardicd Post a picture of your ship in the VAB. F1 button will take a screenshot for you.

The easy answer is to put fins on the bottom of your rocket. If your rocket is aerodynamically stable, it will be very easy to hold to prograde, because the aerodynamics will do it for you. You can see how it will behave by going into the VAB and enabling the Center Of Mass and Center Of Lift icons. You want the blue Center Of Lift icon to be below/behind the yellow Center Of Mass icon. This way as you fly into the wind, the wind will catch on those fins and pull the back of your ship towards the back, instead of catching on the front of your ship and pulling the front of your ship to the back.

I'm not sure. As you can see the formatting needs some work, and I hate to think of some of the comments if I release it like that. Maybe I'll have time tonight to get it cleaned up and tested. The latest version will also include persistent saved settings on a per-ship-per-planet basis, for people the who are asking for that.

@linuxgurugamer: I'll work on the formatting. But that ascent is not too shallow. Yes, it should take 1/2 an orbit to get to 80k altitude. That is the most efficient path, because overall even with these extremely shallow ascents you lose a LOT more speed to gravity than you do to aerodynamic drag. Even though it looks like there's a lot of air up there while the flames shoot off your ship, the actual numbers tell us there is almost zero drag at that altitude. Here's a sample of the latest build version that shows actual itemized losses, and you can see even for these shallow ascents the atmospheric loss is much lower than the gravity loss. And this is on a ship that you can see clearly didn't give a lot of thought to aerodynamics. Forgive some of the formatting, but I have verified the numbers.

The guesses are not optimized for FAR (as far as I know), but it definitely works. I've had other users report that it performs better in FAR than they can by hand.

You need to factor in the acceleration of the engines, that's the part that's missing. You need to figure out how fast you're going, then you can figure out what the drag is, then you need to decide what your thrust should be (because it won't be a constant), and then you can know what your net acceleration is going to be. And then you can move to the next step, some fraction of a second later and start again. While you're doing this you have to track the heating of every part vs. its maximum temperature, which by the way you have to calculate separately from drag, including heat convection to other neighboring parts... Calculating the simple zero thrust trajectory is simple enough, there's plenty of existing code out there I could just use.. Doing it under continual yet varying thrust and figuring out if you're going to melt your parachute is I think way beyond the value of what it would gain us.

GravityTurn works by maintaining a particular time to AP. This is purely based on experimentation by me, but it also happens to be a nice way to describe a trajectory that ascends in an asymptotic curve. It's also nicely translatable to something that a human can do, just watch the TimeToAP and adjust the throttle. The two other factors that influence the path are when to start the turn, and how hard to turn when you do. The answer to those would ideally be "immediately" and "very hard", but in reality if a vessel is not able to get the TimeToAP high enough fast enough, the curve will top out too low in the atmosphere. This will usually result in the vessel overheating. It seems like we are balancing between maximum efficiency and overheating, rather than just finding the ideal efficiency point. I think the only way to find the ideal point programmatically would be to actually simulate the launch a bunch of times with different parameters and find the best one that doesn't overheat any parts. But this is a pretty intense set of computations, to compute the drag coefficient on each part at a rotation that we'll have to determine and figure out the fuel consumption and staging how it will evolve throughout the launch, which all gets more complicated because we're thrusting the entire time... All of that would have to be included in any equation to try to describe an ideal launch. I think the experimental results are pretty good, and I can say for everything I've tested there isn't much room to improve.

It's only worth learning to dock and rendezvous if you plan to meet up with some other ship and/or join two ships together. GravityTurn is now available on Kerbalstuff.

The settings should open with just a left click on the icon. If you provide your KSP.log (after clicking at least once), maybe I can check to see if there's an error.

Yeah, sorry. GravityTurn can definitely cause a problem with having too much fuel left when you hit orbit. This is a known issue, but a fix will not be forthcoming.

@Joco223: Inclination is not included yet. That will come in a later release.

Latest version 1.2 released. The major update that many people were asking for is that it now does a MechJeb circularization burn at the apoapsis. This will only happen if MechJeb is available on the ship, otherwise the plugin will continue to function as before without a circularization burn. @mcirish3: The stage calculations are done many times per second, but they're just some basic arithmetic. The total CPU load for the entire mod is vanishingly small next to the overall load for the game. If you're asking about how I calculate the TWR, then it is only the launch stage that is taken into account here. For now. @Joco223: I'm not familiar with that mod. The 1.0 release would end as soon as it left the atmosphere. I'm not sure about 1.1, it might have had this problem. But this 1.2 release should work better, since I added support to launch from moons without atmosphere. It should now not complete the ascent burn until the apoapsis matches the destination height.

It handles auto-staging, and has an option to disable it It works with RSS Earth and probably any other planet. My test RSS launch with stock parts used under 9k m/s of delta V. It kinda works with Realism Overhaul. But since the whole mechanism of the mod is adjusting throttle, it doesn't perform all that well with the unthrottlable engines. It would be just as easy to do by hand. Best Guess is calculated based on launch TWR and my experimentation. The higher the TWR, the sharper and earlier it will turn to initiate the gravity turn. It definitely seems to beat MechJeb's default settings. But that's not something I can promise for every ship. And I don't want to advertise GravityTurn by talking about MechJeb. I have other ideas for the "launch complete" actions. That will be a different, unrelated mod. MechJeb already has everything you need to do circularization burns. This mod is really not meant to go that far.

There is a video.

Launch a craft into a low orbit with a few customizable settings. Performing a Gravity Turn is arguably the most efficient launch procedure. The plugin will take care of the entire ascent for you by maintaining a strict hold to prograde (as much as possible) and varying the throttle to keep the desired ascent curvature. The circularization burn will be up to you, but it's normally less than 50 m/s. The "Best Guess" button tries to find the best settings for a particular rocket. Here's the best I've seen it do so far, 80km orbit in 2987m/s: http://gfycat.com/WellmadeDefiantBlueshark Download the mod Here View the source Here Get the unstable 1.1 pre-release DLL Here License: GPL V3 Requirements: None. (Optional: MechJeb for circularization burn) Features of this version: Learning system: Learn from previous launches, trying to find the most efficient settings Staging improvements: New StageSettings window to fine tune to your preferences Lift improvement: No more wobbling during initial lift, delay pitch correction until after 45 degrees SRB improvement: Fade HoldAPTime down from wherever the SRB burns out, instead of cutting the throttle all the way back Previous updates: MechJeb Integration: If a MechJeb module is on board, order it to do a circularization burn after ascent (by popular demand) Auto-detect launch TWR and guess best ascent settings. Destination orbit inclination. Persistent settings per-ship per-planet Detailed loss/burn info for fine tuning settings More aggressive ascent guess for SRB rockets based on max TWR. Better tracking of initial turn heading. Pitch adjustment in upper atmosphere for very low TWR upper stages. More intelligent triggering of procedural fairing stages based on dynamic pressure. Maintain control through to atmosphere exit Some notes on numbers: Gravity will continue to reduce your orbital speed up until AP. That has to be accounted for, otherwise the numbers wouldn't match up between what you burn, the coriolis you started with, what you end up with at orbit, and the calculated losses. A steeper ascent will result in a much higher gravity loss after the burn than GT's shallow ascents. Gravity drag is calculated as the dot product of gravity's downward force and your normalized orbital velocity. This is tracked up to the current moment, and then extrapolated into the future to the AP by simply taking the velocity difference between now and the AP. Thrust vector drag is the difference between your thrust vector and your orbital velocity. You'll notice that thrust vector drag starts off being very large, because you're burning orthogonal to your orbital velocity due to coriolis. Gravity loss starts at zero, because gravity is also orthogonal to your orbital velocity for the same reason. Each drag value is summed into an overall loss by multiplying by the time interval (a fraction of a second at a time) as the launch progresses. Total Burn will not match what you see in KER or MechJeb vacuum stats. GT will show you the actual total burn, not the idealized vacuum burn. Because your thrust is always lower at launch than it is in vacuum, the actual Total Burn delta-v will thus be lower than the same amount of fuel burned in vacuum. This number is tracked just like drag and loss, by summing the instantaneous thrust divided by the instantaneous mass times the time interval many times per second. You should notice that your final orbital speed will match Total Burn - Total Loss + Coriolis (175 for a zero inclination launch) within a few m/s.

Quick update: SlingShotter is now available by CKAN.

I just put in a pull request to get it added to CKAN (via netkan). So whenever they pick it up, it'll be available.

I'm glad people seem to be liking it already. I edited in a quick demo video.

This is a very simple Kerbal Space Program plugin to display the positions of all planets, moons, and the current vessel after a selected time interval. It's helpful especially for gravity slingshots, for example not having to "sweep" your node path across the orbit of a Joolian moon in order to find an encounter. You can simply select the time where you would intersect the moon's orbit, and the plugin will show you where the moon actually is. This in particular is the functionality I really wanted, so this is why I created the plugin. It's also helpful for visualizing the position of two planets as time progresses, to better plan interplanetary transfers. There are other tools that will do that calculation for you, but this is a more hands-on approach. This project uses the GPL license, which is included in both the source and the binary package. Download the plugin Here Download or fork the source on Github Here View a demo on how to use it Here.