Somerled

The dead zone sometimes doesn't register. For mine, I just tap the stick a few times in different directions whenever I see a joystick-assisted-tumble. It usually picks up the dead zone after that mini calibration.

"Make a mod" is riffing on the theme of building your portfolio. Even better: you're learning Unity, so make a game in Unity. Lots of indie devs got a huge start building small one-offs in Unity, Unreal Engine, Source, etc. You want to break into the industry? Smash your way in with some solid ideas and sincere execution. Also build levels, make art assets, script game modes, whatever takes your fancy. Show what you can do, then ask to join a team like Squad. And don't forget to please tell us all about what you've made/are making. We want to enjoy it, too.

Anyone try a stock tug? A rocket with a large flat plate in front, line up as best you can with the target's center of mass, and push it into re-entry. I used to deorbit my final lifter stage like that, but that was a basic orange tank+rocket. It's super tricky, but cool when it works.

A direct answer: Tosh Sunbeam mod. I don't know how well this works in .21.

True, but it's only as advanced as keeping the yellow x close to the purple three-pointed cross by burning on the opposite side of the yellow x every now and then. No skill or knowledge involved beyond that, really. The stop, burn, stop, burn method is easier to perform in theory, but can be much more frustrating to first-timers due to the unintuitive orbital ballet that's happening at all times. [edit: I only just realized that the retrograde, target retrograde, and maneuver markers are all designed to visually line up on the nav-ball during a perfect approach. Same for the two prograde markers. Neat!]

Apollo13, First: You don't need to get to zero velocity all in one burn. If you burn early, consider only cutting your relative velocity in half. As you get closer to the target, cut it in half again. This lets you manage approach speed and direction without slowing down so much that your closest approach moves way off. Second: Notice in that video, around 1:45, how the retrograde marker tilts off and away from the target marker? You don't want that to happen until you are very close to your target. A good way to ensure that doesn't happen is to not slow down too much (especially stop burning when it starts moving away). Also, the retrograde marker tilts away from the direction you're pointing on the nav-ball, with it tilting faster the farther away from the marker that you burn. Use this to your advantage: if its tilting away, burn on the other side of it to push it back towards the target marker and keep you moving in the right direction. If you end up moving too slow doing all these small burns, just flip around and burn towards the target to add a little speed. Third: It may be more awkward doing these burns in map mode. You can visually see targets within 100km, so you can track your distance from them by sight. If you place a maneuver node at the intersection point (no need to actually set up the node, just place it), the "Node in T-" time gives you an idea of how much time you have until the closest approach. As you keep doing burns, this gets more and more inaccurate, so use it just for your first one or two burns.

On the nav-ball, they look just like the prograde and retrograde markers. In fact, they replace the prograde and retrograde markers. If you click on the speed display just above the nav-ball, you switch between orbit, surface, and target (relative) speed readouts and it changes the markers on the nav-ball as well. If you have a target set, this should switch to target mode automatically around, I think, 75km away from the target, but you can always do it manually if you need to. Yes and no. You can't set up a maneuver node that will take into account target velocities. But, if you set up a maneuver node at or very near the intersection point between you and the target, then adjust the maneuver until the two orbits match as close as possible, that gives you a pretty close estimate on the dV meter, plus burn time and burn direction.

Okay. Thanks to all of the very helpful and intelligent people who have posted here, I've improved my understanding and fixed my designs. Having wings supplying lift both forward and behind the CoM fixed most controllability issues. All my pitch stability problems seemed to be caused by a confluence of poor balancing of lift vectors (and not just cumulative lift) and how KSP treats control surfaces. Oh, and a little research lead me to discover that in aerodynamics a "canard" is actually a small, forward wing. Neat! For future aeronauticists: http://en.wikipedia.org/wiki/Longitudinal_static_stability http://en.wikipedia.org/wiki/Canard_(aeronautics) ...and all the posts above, which are top-notch.

Math? Psshh. Launch to 30k. Decouple landing stage. Deploy parachutes. Did it crash? Yes: more chutes! No: less chutes? For other atmospheres, adjust deploy altitude (or just add a whole lot of chutes and land at low elevations for Duna).

-Move the tower to the correct position -Quicksave -Open the quicksave file and copy the launch tower vessel's configuration to somewhere else, like a text file -Move the tower away so you aren't forced to delete it -Start the new flight -Quicksave -Open the quicksave file and copy the saved configuration to the launch tower vessel -Save the file -Quickload The first few steps only need to be done once. You can also save two tower positions: one at the launch pad and one moved away. When you're ready to launch a new flight, use the quicksave edit trick to move the tower away instead of moving it manually. Or, Hyperedit the launch tower to the desired position? That might be easier, but I've never done it before.

antbin, does that require the adjusted wing to be entirely or mostly forward of the rest? I haven't tried multiple wings along the axis yet (it's just not long enough). Honestly, I forgot how useful it is to have a forward pair. Maybe not having control surfaces balanced in front and back of the CoM is problematic.

(short version: any ideas on how to minimize infinigliding?) If builds are transferable between SPH and VAB using the sub-assembly manager, then I'll try that next. It's not too hard getting mirrored symmetry in VAB though. It doesn't need to be perfectly symmetric except near stall speeds. Below are pictures of the most successful glider I have to date. I've added bits and bobs to give it weight (and purpose, it can eject the wings to act as a mini rover). It can take yet more weight using only the two canards as lift. This is tested entirely on Kerbin, the one picture is just from its latest mission to Duna. The small size may be important, i.e. better torque control, but I haven't tried anything larger yet. It's not difficult to control, it can even recover from stalls and tumbles, but landing is a huge pain because of the infinigliding. Any pitch up starts adding speed. That means no S-turns, no steep climbs (yes, it gains speed in a climb ), and no gliding just above the surface to slowly bleed velocity without very careful controls. It takes very, very long to get down to a safe speed for landing. Any ideas at all about how to stop this madness? Maybe a joystick? If not, I'll have to find ways to retroburn or add drag (chutes being a last resort). A weird drawback of the low CoM: this baby has no problem flying sideways. That means even the tiniest roll and it's heading off course. Not too great. I've run into one more funky problem. If the CoM is vertically aligned with the CoL, the control surfaces act very weird. Sometimes they'll turn opposite directions when trying to pitch. Sometimes one or both will twitch violently for no reason. So, setting CoM slightly forward/backward of CoL is necessary in this setup. And here it is in the VAB. You can just barely see that the CoL is above and slightly forward of the CoM.

I'm having some trouble making a glider, an unpowered plane. I'm making this in the VAB, and I don't know if that creates any issues. All my tests are below 1000m, too. I'm sorry don't have any craft to show since the design keeps changing constantly. Any design I try with the common technique of putting the center of mass just in front of the center of lift is not working. The planes just nose down no matter how many wings I add, weight I remove, or how close I put the CoM to the CoL. After experimenting, I found that putting the CoM just underneath the CoL at least keeps me steady. It's like the CoL is acting as a kind of pivot, and the CoM just wants to settle underneath it. Putting it below and just behind/forward makes it easier to nose up/down, respectively. Does this make sense to KSPers? In a powered aircraft you want the CoM, CoL, and CoT all aligned axially. But, without engines to push the craft, does that change the situation? Could there be some problem in the design with weight vs. lift vs. drag? A side question: any way to turn off/suppress/work around the infinigliding behavior? On my most successful designs I gain 5-10 m/s any time I pull up with the wings on fine controls, making landings very tedious. Any insight is appreciated.

same here, plus space stations at 400km.

If this is somewhere near the north pole, then it could be the same one that I just landed at today. The monolith is maybe a dozen meters below the surface at the center of the crater. Clip the camera through the ground and you'll see it.

The added RCS tanks will make it take longer to reduce velocity, and flying straight at the Mun will mean you have to burn earlier to cut your high descent rate in time. But, it's all good. Glad you made it!

It largely depends on the craft, the asymmetry of the flameout, the available lift and thrust before and after, the balance of the CoM, etc. Since flameouts can be so violent, it's best to set up action groups to turn off jet engines before they flameout.

I can see it being useful in a time-limited rendezvous when you don't have enough time for a full orbit, but your craft will gorge on fuel to slow down or speed up an appreciable amount. I have been thinking of trying an "orbit race" challenge where you try to keep near LKO at all times but travel round the planet as fast as possible. But you'll always be at one of the apses if done right, so [edit: I'm a klutz, this isn't true for orbits with eccentricity, but still -->] a simple prograde/retrograde will fix your orbit.

Yup, you got it. Half the burn time before, half after is a solid rule of thumb. Alternatively, you can start at t-90s plus a bit in your example and adjust for distortion during the burn so that everything lines up much better at t-0s, not t+45s. For example, you're approaching periapsis and attempting to circularize. If you burn directly at your target vector you'll lower your periapsis and distort your orbit from desired (a little or a lot, depending on the maneuver and craft). But if you pitch up just a little bit, you can maintain your periapsis altitude at the cost of taking a little bit longer to slow down. If your periapsis rises too far, pitch down. It's less fuel efficient than the half-&-half way, but it makes up for the fact that you planned your maneuver assuming an impulse burn, which is unrealistic.

Of course you can slow down in an orbit. You balance thrust between retrograde and outward radial vectors and you'll slow down in your orbit while maintaining your desired orbital trajectory. You can do the same for speeding up in an orbit. The apses only mark a resting orbit. So, once you've changed your orbital speed, you must maintain thrust at the precise pitch and throttle setting. It would be silly to do this though. Silly silly silly silly.

Delta-v shouldn't be very different. The key is you pull against gravity as little as possible by minimizing vertical thrust in favor of horizontal thrust. It's why delta-v for Hohmann transfers is independent of ship mass or TWR [edit: see note]. However, at the beginning of an ascent or end of descent, you need to exchange vertical and horizontal speeds, at which your TWR will be an issue and you will get some delta-v loss one way or another. The optimum trajectory saves that for the last possible moment. It's up to the pilot and the surface when that moment occurs. [Note: For very low ISP craft, this is most definitely an issue, but it's still the optimal trajectory]

You're talking about fuel consumption giving higher TWR over time, yes? It's true that you'll have different thrust profiles, but the optimum trajectories will still more or less match up, you'll just be traversing them at different rates. Optimum takeoff in zero atmosphere is a nearly horizontal burn, and it's the same trajectory for landing. That way you don't fight gravity most of the way up or down, just your own horizontal inertia.

Easiest way is to open up your .craft file and add 80000 to the y value (second of two numbers, for the cartesianally challenged) for the 'pos' of all parts. Also, play with the 'height' value of the Launch Clamp part, though it's not necessary. Why would you want to do this? To impress the ladies with the size of your launch tower. And for inverted launches, of course. Launch upside down at 80km (Scott Manley said any higher makes physics go phwonk) and generate velocity with the help of gravity. After all, the best place to raise your periapsis is your apoapsis. [Where I saw it, Scott Manley himself: http://youtu.be/JLxMda_tVPg?&t=791]

It's not a noob mistake. It's advanced design for research in underpowered hard Mun landings.

The shallow descent method works pretty well for hitting a target in no atmosphere. Adjust your orbit until it intersects the surface at your target. A shallower descent is more efficient, but runs the risk of hitting higher elevation areas. You burn retrograde as you get close, pitching up and down slightly to keep your intersect at your target location. As you near the target, you can switch to vertical descent, which is practically necessary in rough terrain. How close you are when you switch to vertical is up to you and the surface. The only concern is when you have long burn times to reduce velocity. The same shallow descent method works, but needs more care. Scott Manley showed a cool way to do it. Set periapsis [edit: see note below] directly above the target by only a few km. Set a maneuver node that kills all horizontal velocity so you drop down directly on the target. Take the reported burn time, and when you're that far away (in time) from the maneuver node, that's roughly the closest you can get before you need to start burning at full throttle. That keeps you from overshooting when you follow the shallow descent method. [Note: doesn't have to be periapsis, but the less vertical speed you have in the orbit above your target, the more accurate the estimate of your burn time will be. At periapsis, the vertical speed is zero.]