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.