PetWolverine

That fellow looks concerned. Are you sure that vehicle is safe?

My new SSTO, the delta-winged Epsilon: I completely guessed at where to do my deorbiting burn, and I wish I'd written down my longitude at the time, because my first approach absolutely nailed the Space Center. And it went perfectly! Erm, no, I caught the edge of the runway and was falling too fast anyway. Bob, you're my most experienced spaceplane pilot, how could you let this happen? Fortunately I had quicksaved in the upper atmosphere, but my aerobraking maneuver put me in a little different spot on the second try. I noticed I was about to pass right over the Space Center at 15 km up and moving at about Mach 3.5, so I went into a dive (wish I'd thought to take a screenshot), which shook the craft so hard that some parts broke off inside the cargo bay. I think SAS was trying too hard to fight the plane's tendency to point into the wind, and one of the reaction wheels tore itself loose. Still, I brought it down softly for my first-ever runway landing (normally I miss and land on the grass). In the last screenshot, "Highest Altitude Achieved" is showing where I was when I quickloaded. Those 10.5 Gs must have been while pulling out of the dive. Mods involved: FAR, B9, Modular Fuels, Real Fuels, MechJeb and TAC Fuel Balancer. Oh, and the struts are from NovaPunch, I think. B9's SABRE M engines get me to Mach 5.4 at around 32 km altitude before I switch them to rocket mode, and with Real Fuels they run on H2 and O2, just like real life.

I have Bob paired with Bobbart as my SSTO test flight crew. They've had some fun adventures, rescuing each other from planes whose engines spontaneously fell off in orbit or, in one case, before the orbital burn. (Bob used jetpack RCS to reach orbit and wait for rescue from Bobbart.)

This is extremely effective. Many of my rovers have managed to stop during testing despite the steep slope of the side of the runway. Even repeatedly repairing the wheels did not impair their ability to break again and keep me on the runway, proving the reliability of this braking method.

This sounds like a testable hypothesis. To the lab! We should expect that if I move the wings forward and back, it should have a noticeable impact on the products of inertia (or at least Ixy, the one I'm interested in). That seventh image is telling. I don't know why I didn't try it before - I tried a single B9 wing, but not a p-wing - but notice that Ixy in that shot is roughly half what it is in all the previous p-wing shots. It certainly makes sense for it to be non-zero in this case; the "craft" is unbalanced. But adding another one on the other side should balance it, returning it to zero, and instead it doubles it. So it would seem that adding more p-wings always changes Ixy in the same direction, regardless of where the p-wings are. Is it always the same amount? Well, no; in the eighth shot we see Ixy more than doubling when we go from 1 wing to 2. But when we add a third wing, bringing the craft back into balance along the x axis (but way out on the y axis), it is now almost exactly triple the value for one wing. Will it return to zero if we mirror each wing? No; even though it is now perfectly balanced along the y axis, and no more out of balance than before along the x axis, Ixy doubles again. You can see how this would add up to thoroughly destabilize a plane of any appreciable size. I suspect that the y offset of the wing's mass is always being given the same value, regardless of its actual position. Of course, this could be a problem in the p-wing code rather than yours, but I think at this point the conclusion that it's a real bug is inescapable. Also, I understand the necessity of struts; I didn't intend to leave them off, but saw my wings flopping as I was lifting off and thought hey, just roll with it and see how it flies. My point was that the B9 wings with horribly, uncontrollably variable geometry were more stable than the very rigid procedural wings of the previous iteration. This is of course just my perception, and if the numbers in the hangar are just for reference and aren't used in any in-flight calculations, then I would have to look for another explanation for the difference between these two planes. But there's still a mistake in those numbers. Sorry for the wall of text. Anyway, don't get me wrong, I love this mod and appreciate the work you're doing. I'll just stick to B9 wings rather than procedural for the time being.

Craft files in KSP are trees, in the computer science sense. This means that if you draw a diagram of your craft with each part represented by a point and connections between parts represented by lines, there are not allow to be any cycles. The VAB and SPH don't let you violate this rule. If you do so by editing the .craft file, it's no surprise that KSP might crash, because it's going to open up that file and start parsing it with the assumption that it's a tree. Essentially, you've corrupted the file. There is a way to effectively have a craft with cycles in it, though: Use docking ports. When you build it in the VAB, it will still be a tree, but if you line up two docking ports without having them actually connected, then when you take it to the launchpad, they should dock. So in your example, instead of trying to attach the lower quadcoupler directly to all of the decouplers, put docking ports there. Then put another docking port under one of them, flipped the other way around so that it looks docked. Put the flipped quadcoupler under that decoupler. Then add the final three docking ports - make sure that they're actually connected to the quadcoupler, but they should line up perfectly with the docking ports above, and should dock when you go to the launchpad. There's lots of stuff you can do by editing .craft files, though personally all I've done with it is get some surface-attached things positioned and oriented more precisely than was possible in the SPH. Edit: Hah, beaten to the punch while I was typing, and with exactly the same solution too.

Racist much? Anyway, you came here and essentially accused people of being dishonest: Claiming to have landed planes that they hadn't actually landed. There is absolutely nothing at stake here, no incentive to deceive, just people sharing cool designs of things they've built in a video game. It would be absurdly petty to lie in such a situation, so you've accused a bunch of people of extreme pettiness. Maybe you were joking, or maybe you just didn't think about how it sounds when you say something like "Then how am I to believe you've landed it?" - certainly your other posts don't make it sound like you're trying to stir up trouble - but there's no reason to expect a good reaction from that. Speaking of reactions, what did Rune actually say? This doesn't sound touchy; it sounds indifferent, which is, in my opinion, the appropriate response.

Personally I'd rather yaw than pitch to start my gravity turn. That way I can watch the curve more easily. I find it harder to judge pitch than yaw from watching the craft, so if I were going for a polar orbit, I would turn the camera. Of course, I'm mostly just watching the navball anyway. @Amazonys: The launchpad is a few arc-minutes south of the equator, so if you don't correct on your way up, your orbit will indeed be slightly inclined. You can use MechJeb's surface info readout to get your latitude; I know the runway is 2' 24" S, and the launchpad is a little south of that, so maybe 4' S. But if you're ending up a whole degree off, it's because you're not heading perfectly east as you turn. Here again, it may help to use MechJeb's surface info; the centers of the markers on the navball tend not to be quite where they look like they are, at least to my eyes, but if MechJeb says my heading is 90.0 degrees (which is almost never) then I believe it.

@ferram4: So, I think I figured out why my Ixy was so high with that plane: Heavy use of procedural wings. I'm not sure if these mods are meant to work nicely together yet, so you can consider this either a bug report or a data point when you get around to making them work, as appropriate. But actually I'm not sure the behavior is correct with B9 wings either, since I don't really know anything about this stuff. So, as I understand it, nonzero products of inertia result from uneven mass distribution around the relevant axes, so that when you try and rotate the plane around some axis, it wants to rotate around another axis as well, or really, around some line that has a component along both axes. Maybe this isn't quite right, but what I'm fairly certain of is that two wings of very similar shape should have very similar behaviors. I took these screenshots with 0.9.5.5, but tried it again after updating to the latest, and saw the same behavior. I did all this with Editor Extensions's "vertical snap" option as well as angle snap, to make sure the wings were exactly centered in all cases. (Maybe Editor Tools is part of the problem? I haven't tried without, but maybe somebody else can check this.) I don't see any reason why a fuel tank with two perfectly matched wings should want to pitch when it rolls. On the other hand, I'm not sure how the single B9 wing doesn't have some inertial coupling - maybe the game puts its center of mass at its center, rather than toward the back as it should be. I'm also not sure I'm understanding any of this correctly, but when I took a plane (not the same one I showed before) that had been very unstable with pWings and rebuilt it with B9 wings while keeping the same shape as much as possible, the result had an Ixy much closer to zero and was much easier to control (and I haven't even added struts yet, so it looks sort of like an ornithopter when it lifts off).

@ferram4, thanks for the suggestions. It sounds like at the design stage when I kept adding more and more wing, I should perhaps have stopped and thought about what I was doing. The CoL is indeed a ways behind the CoM, but pitch authority isn't really an issue except between about Mach 1 and 1.5, which I tend to just blast through on my way to higher speeds anyway. Rolling back and forth, on the other hand, combined with roll-induced pitching, is a bit of a problem. Maybe my next design will be less outlandish.

This mod is essential. I don't think I would want to play without it. I've done some experimenting with spaceplanes in the last few days and developed a plane that can reach Mach 5.3 at (if I remember right) about 25 km before I switch the Sabres to rocket mode and punch into orbit. It feels fairly stable at all speeds, as long as it's going in a straight line - I can turn on SAS and not get any wobble, at which point I can basically walk away. I got it that way largely by tuning the numbers in FAR CAS, but there's one that I can't seem to get right: Ixy should be near zero, but mine is consistently a large negative number. From the tooltip, it sounds like this means that when the plane starts rolling, it should become easier to pitch, and vice versa, which matches my experience in flying it: It's certainly not impossible to turn, and I've even managed to turn it all the way around at about Mach 2 while keeping a fairly steady altitude (I overshot the Space Center). But turning is a constant battle with pitch. Here's the bird: Ixy is -99.12 kg * m^2. I've tried moving the center of mass around, moving more mass closer to the center of mass, adding more vertical stabilizers, changing the span of the tail to move those vertical stabilizers, changing the sizes of the wing tips and the stabilizers, but none of it seemed to help. I'm wondering if the problem is something more fundamental to the design, like the way the wings curve upward, or if there's some tweak I just haven't thought of yet. Any suggestions? Edit: I found this article on inertial coupling that ferram4 linked to a ways back (waaay back, around page 60-ish). So I guess, roughly, having the wings curve way up like that makes it so that the axis that the plane wants to roll around is pitched down compared to the axis that I want it to roll around; so rolling away from center makes the nose droop, but rolling back to center should raise it up again. Seems like a fix would not be trivial, although moving the center of mass forward might decrease the effect (while also making it turn even more slowly, but then I'm not expecting this thing to ever be super-maneuverable).

My first spaceplane to orbit and land safely on the same flight. I have another called Little Wing that got up to Mk. 6, which had an orbit and crash, as well as a fly-in-a-circle and land safely, but Mk. 1 of the Freebird is my first real success with this - and it even has a cargo bay. Main mods present are B9 Aerospace, Proceduring Wings, FAR and MechJeb. Freebird Mk. 1

Nobody's saying not to add it to the stock game. This is a separate, purely pragmatic question of how to deal with the situation right now, when the stock game lacks this feature. The answer is that mods can help. If you don't like the rest of B9 or Firespitter, but you do want this piece, the directory structure of the mods makes it look like you can pick and choose what parts you add - though I haven't actually tried this, so I don't know for sure that it won't break things. If you "just prefer native", your options are to remember your action groups, write them down, consult your persistence file, or just wait for Squad to implement something like this in the base game.

You're not the only one, but it's a matter of how software development works. As Donald Knuth famously said, premature optimization is the root of all evil. In context, it's more about optimizing the wrong parts, but it applies equally well to optimizing at the wrong point in the development process, and for the same reason: Once something is optimized, it becomes much harder to change. Optimizing the physics, or anything else, at such an early stage in development would lock it in to a large extent, or at least make later changes more difficult (read: longer time between updates). And considering the physics model currently lacks reentry heat and has only a placeholder for drag, there is much that needs to be done before optimizing. To some extent that's because that's all there is to do in the game right now. It's easy to forget that despite KSP's relative polish, it's still in alpha. Career mode doesn't even exist yet; when it does, hiring crew will probably be an important part of running a successful space program. More generally, features that seem like "silly stuff" now will coalesce into an actual game in the future, whereas right now all we have is a sandbox with the only goals being whatever you decide you want to do. Believe me, I'm frustrated by part count limits as well, but the reality of the situation is it's going to be that way for a while. If we get to release and 400 parts is still a slideshow, that's when I'll be disappointed.

Maybe it's one of the mods I'm using, but the game already does this for me, as long as the ships I'm switching between are within physics load range (2.5 km I think). Very helpful when I'm doing a docking dance, rearranging parts on a big station.

My favorite successful failures have been the result of having FAR, but having no understanding of aerodynamics, and trying to do a gravity turn with a high-TWR vehicle the same way you would in the stock game. Go straight up to 10 km, okay, got it. Now lean over heavily to the east and start turning. Then keep turning, and turning, wait no, stop, the nose shouldn't be below the horizon! Okay, kill the engines. It's still turning. Here it comes, give it a nudge and it'll come upright again. Open the throttle, good, we're accelerating, turn to orbital prograde... stop turning... I said stop turning! Here we go again... I think I've done up to three flips and still ended up in orbit. I found some good advice on gravity turns over in the FAR thread and my last few launches have gone better, but there is fun to be had in close calls like that.

A poll like this needs to be taken with a huge grain of salt. Perceptions of performance can differ greatly from what actual numbers would say, not to mention that a performance change could alter the likelihood that someone would participate in the poll (e.g., my framerate decreased and I have a bone to pick about it, vs. my framerate increased and I'm playing the game rather than browsing the forum).

Topographic maps as mentioned by Drunkrobot would solve the landing difficulties Mefi282 mentions, and I would love to see that in the game. The thing I most often tab to the wiki for though is terminal velocities, so I can know when to ease up on the throttle for a more efficient ascent. It would be great to have a device that would give a readout for this, perhaps relying on data from the barometer and the gravity meter. It would also be helpful to display equatorial nodes in map view, to help plan inclination changes. I'm not sure if either of these is strictly a knowledge base thing though.

Physical time acceleration continues to simulate the full physics of your craft, with each part tugging or pushing on the parts it's connected to and so forth. So the vessel can wobble, bend, rotate, accelerate, and so forth, but at up to 4x speed. To get this higher speed, it uses a larger timestep, which can be dangerous because it magnifies the unavoidable, but normally small, imprecisions in the relative positions and velocities of parts, which can lead to more dramatic wobbling, uncontrolled spins, rapid unplanned disassembly and rapid, violent expansion of parts one might prefer to keep intact. With non-physical time warp, your craft is put "on rails", meaning rotation stops, engines can't be used, and the parts of your ship don't interact with each other, they just stay fixed in place like they would in the VAB. The vessel just keeps going on its trajectory, with gravity being the only physics that remains relevant. Time warp of this type isn't allowed when you're in atmosphere, since drag is constantly altering your trajectory. This is the time warp that can go to very high multiples of the speed of time.

I launched a SSTO yesterday to take a 41-ton lander to a Mun encounter. It's on its way back now, with enough fuel left to deorbit if I wait for it to go around to its apoapsis again (it should be able to land unpowered, with parachutes and reaction wheels alone, though I haven't tried this yet). Alternatively, since its periapsis is around the same altitude as one of my stations, I might be able to grab it with a tug, slow it down and dock it - but this would bring my part count to around 600 probably, which is not much fun when docking large vehicles. Or I could refuel it with the aforementioned lander, which is a kethane mining rig. More practically I'll need a bigger drilling operation though. It's funny watching the thing's TWR change. It started off less than 2, but now that it's almost empty and still has 7 mainsails, it's something like 160. If I told MechJeb to execute a maneuver node, with the way it likes to slam the throttle all the way open instantaneously, it would probably just explode. At about 2 frames per second.

I second this, and it's not a purely aesthetic matter. For example, I need to be able to tell if my landing legs will clear my solar panels as they extend, keep the engines off the ground once extended, and leave my kethane drills close enough to the ground to work. Of course these things can already be tested on the launch pad (and then "revert flight" and add a launch vehicle), but some testing in the VAB would be much nicer.