Chronosheep

Look closer:

My experience so far is the exact opposite: RAPIERs and turbojets have been heavily nerfed (which is a fact. Their ISP is halved, and their thrust heavily reduced). Hardly any of my SSTOs (that were able to get to space with ease in 1.0 and 1.02) are able to get to space anymore, and it takes ages to climb. Seems like i'll need about twice the number of engines I've been using before.

Even if you don't consider this a gameplay problem, is this a reason to be opposed to a more sensible and realistic fuel flow logic? I get the impression that my suggestion would be much better received if I never mentioned rockets flipping at all.

First of all: Yes, it is possible to work around this, but this is not an excuse for having an illogical default fuel flow system in the game. And no, this is not only an issue with poor rocket designs (though this is certainly often the case); it is also largely due to the way fuel is drained. No, this would not at all be unrealistic. You are making the assumption that fuel is contained in a single tank with the length of the entire rocket. In KSP, the fuel is contained in multiple small tanks, and is pumped between tanks. If such a system was used in real life, no sane person would ever start by draining the top tanks. Even if you make the argument that the many small tanks linked together in KSP should be considered to be a single large tank, liquid fuel and oxidizer are in real life contained in separate tanks at different heights in the rocket, and these two tanks would be drained proportionally. In this case, the center of mass stays roughly in place (of course depending on the payload).

Since 1.0.2 many players have complained about their rockets flipping when reaching a certain altitude. The main reason for this is that the center of mass moves to the bottom of the rocket as fuel is drained from the top tanks. A simple fix for this issue would be to change the fuel flow logic to drain fuel from the bottom tanks first, not from the top tanks. The center of mass would then move towards the top as the rocket ascends, and the rocket would remain stable. EDIT: It is obvious that this needs some clarification: In a real life rocket, liquid fuel and oxidizer are located in separate tanks at different heights in the stage. These tanks are drained proportionally, and the center of mass will therefore not move nearly as much is it does when the tanks are drained from top to bottom. In KSP, we have multiple fuel tanks per stage, that drain into each other. If such a system was used in real life, no sane person would start by draining the top tanks. This is not only a problem of poorly designed rockets, as some like to claim (though this certainly plays a role), but is largely a problem with the default fuel flow.

This doesn't seem to be the case. The arrows are still rendered (inside the tanks), but with zero length -- they look like red pancakes.

Thankfully seems to be a rendering bug. Will edit the first post to avoid misleading.

After some further testing, it seems like this bug is circumstantial, and I haven't yet been able to determine exactly what triggers it. I've been using surface attachment, but using the radial attachment point will in some cases also do it. In this case, some tanks are dragless, while others are not: I suppose it's also possible that it's a rendering bug on the arrows. I guess it requires some more testing.

I've been experimenting a bit with the aerodynamics in 1.0.2, and found some interesting, and hopefully useful results. 1. Nosecones: All air intakes, all 1.25m nosecones, and the shielded docking port all produce the same amount of drag. This doesn't seem quite right, since some of the parts should realistically be more aerodynamic than the others. The 1.25m parachutes only produce slightly more drag than the nosecones. 2. Mk2 to 1.25m adapters: Contrary to what you might think, the long adapter produces (slightly) more drag than the short adapter. 3. Back-facing surfaces: A back-facing flat surface produces the same amount of drag as a forward facing flat surface. 4. EDIT: First assumed to be an aero bug, but turned out to be a rendering bug. Sorry about the confusion. Drag arrows do not always render properly when objects are perpendicular to the air stream.

Thanks for the suggestion, but I'm afraid it won't help. Because of the absurdly high lift of the mk2 parts, the center of lift will be too far to the front when there is little fuel left, even if you put all the fuel in the frontmost tank.

The game currently has 3 sizes of (retractable) landing gear: Small, large and gigantic (a.k.a. small, medium and large in the game). It would be really nice to have medium sized landing gear that actually is medium sized. The current medium landing gear is way too large for most medium sized planes.

While Laythe-return SSTO flights appears to be out of range in 1.0.2 (except perhaps for ion or ISRU based SSTOs), getting an SSTO to Duna and back is possible with good margins. This craft has about 5.3 km/s delta V available from LKO, carrying a fair bit of unnecessary oxidizer. I wasted large amounts of fuel during the trip, and still had 1.5k delta V to brake with when returning to Kerbin. Unfortunately, the plane turned out to be completely unmanageable on empty tanks, which resulted in a very Kerbal landing back at Kerbin. Back to the drawing board, I guess..

Let me introduce the future of spaceplane SSTOs: Seriously. I built this as a joke, but it turned out to be one of my most successful designs in 1.0.2. There is absolutely no need for wings anymore. You might think that this thing would drop like a stone when landing, but nope; it floats slowly through the air like a blimp.

I must admit I'm a bit frustrated by this re-balance. Not so much because I don't like it, but mostly because I had finally figured out how to build an SSTO that most likely would be able to return from Laythe in 1.0. Such major changes should come as a patch less than a week after release. In 1.01, returning from Laythe (is at least for me) slightly out of reach. Duna should be possible, though.

Fun challenge. Here is my contribution: going for the unmodded time record.