ThatBum

Port forwarding should be good enough. Hamachi is an unnecessarily complicated and slow method of doing effectively the same thing. Be sure you've forwarded both TCP and UDP, and use this to test if the ports are open (have the server running first).

I, uh...I'm just gonna put this in here: http://www.bbc.co.uk/news/science-environment-24429621 Yeah.

My limit is interplanetary spacecraft that can return to Kerbin from their destinations. Also, Jool.

Hiya. I've been having fun derping about with some public servers, but I couldn't really get anywhere meaningful. I could barely get to LKO without losing connection, regardless of server. My Internet isn't the best (decade old DSL on rotting phone lines...). There's probably packet loss, but it never died completely. Also the serverside persistence didn't seem to work for my ships, when I switched from one to another it eats the first ship. This might have to do with aforementioned connection problems. It's still looking really good for a pre-alpha, though, despite the lack of robustness in the netcode. Perhaps implement some interpolation, if it's not there already? Anyway, keep on doing what you're doing!

A thing I made in GIMP: I also resized the United States of Earth flag from Futurama. However, it's a different aspect ratio than KSP flags, so I made two, one that's been cropped and one that's been scaled. Cropped: Resized:

I actually use them for landings, Spirit/Opportunity lithobrake style. I decelerate the payload with a rocket (or parachutes if it's to be used on a body with atmosphere), then detach the rocket from the payload and hit the ground at speed with lateral movement, using the airbags to prevent...unplanned disassembly. The weight balance with this system is not as critical as with a skycrane, as hovering in place isn't required, just slowing down.

You could try the CP Airbag mod:

Might have something to do with Ferram and its aerodynamic model, try it without Farram installed.

You generally need two sets of 4 four-way thruster blocks. this should have at least 4 thrusters fire during any given attitude/translation adjustment. If you have less, you're likely to encounter dead spots. Exceptions are: When you intend to undock or decouple the ship into two or more ships with independent RCS systems at some point, in which case you should disable all but the outermost thrusters until you separate, to save fuel. Use action groups to do this quickly. If your ship is a weird shape like a spaceplane. What's commonly done for spaceplanes is to put one four-way block and one linear port on either wingtip, and four linears around the nose. It should provide two thrusters for yaw, two for roll, three for pitch, two for left/right, two for forwards/backwards, three for up/down. If you need more RCS power than usual, like an RCS only lander, or a hovering rover. You should use linear ports if they fit in the design, as they have a bit more thrust. It may be possible to get a full range of motion with one set of 4 four-way thrusters directly in line with the Center of Mass (CoM), such as an Apollo style CSM, but this is difficult. Try to place the ports as far away from CoM as possible, to maximize torque and therefore efficiency for attitude changes. The two sets of 4 blocks should also be equidistant from your CoM. If not, one side will push more than the other and the attitude will drift. This also causes the ASAS spazzing out when RCS is on. It's possible to get the alignment exactly right in the VAB, but your CoM will gradually change in-flight as fuel is burned. This could theoretically be fixed with an RCS balancer, a system that would vary the thrust to each thruster to prevent drift, but an official one is not implemented (yet). MechJeb 2 has an experimental one, however, if you want to try that. If you're not sure if it will have dead spots or not, put it on the launchpad, hit each adjustment, and see if thrusters are firing as intended.

Yeah, it's a lot more efficient to do an aerocapture. Let the drag do some deceleration work for you. The atmosphere is so dense it slows you down quite quickly, with spectacular entry effects. I found 60km is pretty good, 40 made me lose orbit. You could do a double dip aerobrake if you don't trust yourself to do it in one go.

Okay. Well, you probably know by now, the point is to get the two orange arrows in the map view to line up with each other. Or the two purple arrows, which is the encounter after the orange arrows. The top arrow pointing down is where you will intersect the target's orbit, and the bottom arrow pointing up is where the target will actually be at that time. You also need to get one of the green sideways arrows, the ascending/descending nodes, in contact with the orange arrows. If you don't their altitudes relative to the planet will be the same at the encounter, but their altitudes relative to each other will be different because their inclination isn't the same. Just experiment with the maneuver nodes and try and get is as close as you can, using the guidance computer isn't going to hurt anything. Another important point is knowing when to launch. If you launch when your target is on the opposite side of the planet, you'll need to spend a long time in a lower or higher transfer orbit to catch up to the station, or let the station catch up to you. It varies with different rockets and ascent profiles, but I find a good time to launch is when the target is just coming up over the horizon relative to the ship waiting on the launchpad.

You could stick them on your last stage. It's a bit of a kludge, but it works. You could also put one of the small probe decouplers between the pod and the escape tower to jettison the tower when there's no longer a need for it. This saves weight and also could expose a docking port.

Lol, when I first saw this I thought you meant attitude as in the direction a ship is pointing, rather than behavior. God, I am a giant nerd. Anyway, I've done docking quite a lot with my stations. When you get within visual range of the target, it's not worth fiddling with maneuver nodes at that point, and you would do better to try and align your prograde and target position markers on your navball. Be sure to kill horizontal speed early, to take into account the time it takes to decelerate.

MechJeb 2 integrates entirely with the stock maneuver node system. You can tell MechJeb to make a maneuver node for you and fly it manually, or make a maneuver node manually and have MechJeb fly it for you. It's much more educational and capable than original recipe MechJeb, IMO.

It's the SNAC Pack. Its purpose is to have a forward facing control point for rovers. It was underground for a few updates from a terrain art pass, but I guess it was fixed in 0.18 or 0.19. Here's me space dragster!

If you want to get your coordinates, you need some sort of mod. Simple as. If you're opposed to MechJeb, you could get ISA MapSat. The receiver module tells you where you are. Though, MapSat uses dec coordinates with only one decimal point, and MechJeb uses degrees-minutes-seconds, which is more precise.

Sounds like a good ol' Kraken attack. Apparently this is warp factor 9.978 (new scale). That is fast, indeed.

The air ducting is something that's not in KSP. It's like RCS thrusters, but using compressed air drawn in from the atmosphere instead of hypergolic fuel. Of course, this won't work in space. In KSP, to make something hover (for example a skycrane), the center of mass has to be perfectly balanced over the center of thrust. The engines don't have independant throttling, so you can't tell the side with more weight to thrust more than the lighter side. Try angling your engines out somewhat with Shift+WASDQE. Angling loses some downwards force but increases stability.

I use the spinny separations for stack mounted stages only. I tried it with radial mount separations, and it tends to collide with the thing they're separating from. It seems more reliable to position the sepratrons in such a way as to push the spent stage away from the core they're attached to.

Oh thank God, I saved this as an offline page because I use it so often. Good to know it's not dead.

Doing those is an incredible pain. With an equatorial rendezvous, you only need to launch at the right time to catch up with the station, or have the station catch up with you. KSC is already on the equator, so no weird math and plane changes are required. With an inclined orbit, you need to catch up with it and launch where your orbits will intersect. So, the whole thing involves very narrow launch windows and little margin for error.

You might want to try MechJeb 2. It's still in development but already much more capable than original recipe MechJeb. It integrates with the maneuver node system so you can see exactly what it's doing and learn from it.

106 d 12 h 32 m 24.6 s

I'd imagine it would be something like Kerbin TWR times the inverse of the gravity of the planet. If it has 1.7 TWR on Kerbin, which has 1g of gravity, and you send it to the Mun, which has 0.16g, you would do 1.7*(1/0.16), which is 10.625. Is that correct?

There was once a thread that had a completely custom Arduino or Arduino-like microcontroller based controller, using those neat analog sticks taken from a professional RC controller (like this one). It got eaten by the Kraken attack, unfortunately.