PKing Zombie Spy

I design more or less the same basic lander as you, except I reversed the position of the lander can and the materials bay. (At least, I'm assuming the thing below the can in your picture is a materials bay.) Lander can is 0.6 tons (no mono-propellant of course), materials bay is 0.2 tons, so I figured I'd put the can on the bottom so the lander wasn't "top heavy." I've used this since my first career play in 0.23.5. It has a touch over 2300 m/s dv, which makes it plenty versatile: hops from biome to biome on Minmus are how I unlock the majority of the tech tree. I think the hardest place it's seen service is Moho, and even with that I could afford to be really careless. I typically make two per playthrough: one once I exhaust much of the science in and around Kerbin and need a Mun lander, and one when, from the fruits of that, I have enough science to acquire every (non-atmospheric) science instrument and an OKTO2. This is the only design I consciously reuse across multiple playthroughs. So simple, easy to fly, dock, and land, and at only 180/220 l/ox it really sips the fuel. I call it a runabout. I don't know why but I really have a soft spot for this little guy: so useful. Even when, in some year, I stop playing KSP I think I'll remember him for quite some time. I don't reproduce anything else from playthrough to playthrough, at least, consciously.

I guess, but no more so than KSP "stole" the general idea from Orbiter. The gaming universe would be very, very dull if the first instance of a game in a genre had to be the last one.

In terms of gain: An orbital refueling station means many missions must concern themselves only with how to get to and from LKO, rather than factor in all the subcomponents of their mission. Through my so-called "Nuketug" fleet (dockable nuclear engines captures the idea), I have to think very little about how to get any given payload to any given point in the Kerbol system, assuming I can get it to LKO. So this simplifies my thinking and mission planning. Also, when considering a contract: those ridiculous contracts for measuring temperature or whatever here and there look a lot more reasonable if you have a fully capable reusable science lander already in orbit of the relevant body. Temperature on Gilly with no station meant reject, since it'll take me years to even get there from Kerbin; but with a station, assuming of course I have one of my trusty re-usable "Runabout" science landers, I'll accept in a heartbeat. And, if it's something like a rescue contract, I know I can do whatever it asks even without designing and launching a special mission, since I presumably have something capable of intercepting whatever it is, close enough to wherever it is. On too many contracts to count now, I've made many millions of credits in Kerbal hours for which, without the station, I'd have had to wait Kerbal years to earn. On the other hand, some things become more complicated: I think a lot more when designing a mission about how to break it down into things that can be used for future missions. plus of course the basic idea of how to dock. My fleet of the aforementioned Nuketugs and reusable craft/landers are in fact artifacts of previous missions. I designed them differently and with some more complexity than if I had expected to just throw them away. With stations, KSP becomes a different game, a real sense. Even if I wasn't exploiting opportunities with these guys that would be troublesome to exploit with no station, that would be worth it: frankly after grinding career to the point where I could consider putting one of these babies into orbit, I was really, really ready for a different game. Also it's fun designing a station for a change: a space vessel, you think a lot about the stuff you can toss out, so they become spartan. Space stations you just have to get somewhere, then you intend to leave them alone, so you're a lot more free to indulge in frills an inessential designs without suffering from a persistent inefficiency, so you can go pretty wild with these guys. Look at this thread: people are very excited about designing something like this! Also, because this became a sharing thread, despite your intent : here is my LKO station. (You see, in addition to the station, re-usable landers, as well as a single spaceplane.) Look at that ridiculous spaceplane fin on the gibs, you'd never see that in anything not meant purely for flair: Mun/Minmus station (both identical):

My normal naming is unsystematic beyond just being a descriptive name followed by a version number: e.g., Rescue Rider-6 is my current generation of LKO Kerbal rescue system, Plane-2 is my current spaceplane LKO personnel shuttle, etc. The only thing even remotely interestingly named is my "nuketug" system, a nuketug being set of dockable reusable nuclear engines I use to push stuff around. The designation is:Nuketug <N><A> <Dry>-<Wet> where <N> is thenumber of nuke engines (omitted if N=1), <A> is the attachment class (oneof S, M, L, for the size of docking port, or K for the klaw). I know a nuclearengine has 800 Isp, and generates 60 kN of thrust, so based on this informationI can determine quite easily which of my "fleet" I should couple witha given payload that requires a certain amount of delta-v to reach. E.g., Nuketug M 4.07+4 is a single engine tug with a medium docking port, and is 4.07tons dry and 8.07 tons wet. Nuketug4L 15.63+12.5 is a four engine tug with a large docking port, and is 15.63 tons dry and 28.13 tons wet.

Maybe. This could be a problem, but the way I solve this problem is I don't do the final "lineup" burn at the target, but some altitude above the target. This is slightly wasteful, but it mitigates this problem. You also have a couple advantages given your problem setting: your fuel shuttle, whatever it is, is presumably landing mostly empty, which means your turn and thrust capability is as good as it's ever going to be. If you can get to Minmus orbit if your tanker is full (an obvious design requirement), you must have reasonably sizable Minmus TWR when empty, right? At least this would be my expectation. (So for example, even though when full my VTOL rover has a meagre ~1 m/s acceleration, when almost empty it's about 8 m/s, which is pretty good for a Minmus landing even when I'm being careless.) Here's how I solve the same problem, for my fleet of Minmus fuel shuttles: I first obviously designed something really easy to land, and dock. So for example, my fuel shuffle is basically a giant VTOL rover, with well balanced downward pointing engines, and a probe core in the exact center pointing up, a port on one end, and a klaw on the other. It looks downright stupid doing transfer burns (see here), but it's also very easy to land. If I start my descent 10 minutes before impact, that means that the point of impact is going to be slipping about 5.5 kms on me (if at equator), which is about five-ish degrees. I eyeball it, naturally erring towards overshooting by a bit. The navball makes very clear to you when you're about to be right over the target -- at this point to be clear I am still high over the target (perhaps as much as 500 meters or so, hopefully a bit less), but once I get lined up vertically pretty much all I have to do is drop, which makes things much, much easier -- this is wasteful of a few dozen m/s deltaV or so, but then again, I'm about to refuel with the "free fuel" anyway, and my safety margins aren't that tight. Again, because the fuel shuttle is empty in your problem setting, killing horizontal velocity should require rather a relatively short burn, so you should have plenty of warning so you can "time" it right. (Versus the lift back into orbit when full. But there timing doesn't really matter at all.) Then of course the vertical landing is very easy. I usually land within about 100m or so. (I obviously try to "miss" a bit so I don't destroy everything.) Then I line up and dock. See here.

Regarding flyby: one thing I noticed is that in order for a tourist to consider themselves a flyby, you have to be controlling the craft with the tourists as you enter SOI. (Interestingly enough the same restriction does not hold for spacecraft flyby contracts.) Just another small bug in the pile.

Hmmm. Not pleased with this; even if I liked the feature it's a really bad sign that people are this confused about how it will work. It's sort of like whoever designed this adopted the same incomprehensible complexity of the overhauled science lab and new ISRU, two inessential parts of the game. The trouble is this new artifact of complexity is applied to controlling spaceships, the most essential part of the game. I've always consciously held this exact abstraction in my head as to how I was able to control probes even when they were many lightseconds or even lightminutes away. The game does not allow me to create a probe control system in game, so it compensates by pretending I am the probe control system. Seems fair to me.

Not to derail the thread by bringing it slightly closer to the original question, but I'm curious: how did people become convinced KSP is using a 32-bit int of seconds to track time? I've never modded KSP so I'm less familiar with this DLL than some, but if I just pop open KSP's "KSP_Data\Managed\Assembly-CSharp.dll" with Visual Studio's object browser, I'm seeing a lot of methods and members like this: public double UniversalTime { get; } ... Member of Game public static double GetUniversalTime() ... Member of Planetarium public void WarpTo(double UT, double maxTimeWarping = 8, double minTimeWarping = 2.5) ... Member of TimeWarp public double TimeDeadline ... Member of Contracts.Contract public double missionTime ... Member of Vessel public Vector3d getOrbitalVelocityAtUT(double UT) ... Member of Orbit It's possible I'm being misled as I'm not familiar with their codebase, but from the above, it sure looks like they are, as a rule, using doubles to track time for anything that could possibly work over large timescales (UT, mission time, etc.). But this evidence aside, clearly KSP cannot use an integer number of seconds for its time tracking, since the simulation obviously works at a subsecond resolution.

So how efficiently can you do a Minmus-escape-Kerbin-return burn, from Minmus orbit? (I forget myself. Is it 200 m/s? 300 m/s?) Anyway, you'd get for "free" back the usual 930 m/s, minus whatever that is. Maybe 600 m/s, 700 m/s? And then you're really, really lucky and good, the Mun lines up just right so you can use its 542.5 m/s orbital velocity to extract another ~1100 m/s, for a total gain of ~1700 m/s. Right. But of course there's the more appealing answer: moar boosters.

Missions to put an object on a Kerbol escape trajectory are satisfied by putting the required object into a parabolic or hyperbolic trajectory (as opposed to a nice periodic elliptical or circular orbit). I'm thinking especially of those crazy missions to eject a class E asteroid from Kerbol. They do not depend on a finite SOI. You do not escape the SOI of course, but that is not the definition of escape KSP uses. Doing a suborbital is an interesting strategy. That would require that at the point you leave Kerbin you have an orbital velocity of 1803 m/s around Kerbol (so your eliptical orbit is below Kerbol's surface). This means I guess escaping at about 7481 m/s retrograde. Using the same strategy as I outlined above that means 8122 m/s at 100km, so if done from orbit it would require ~6000 m/s delta v? Still doable, but harder?

Well, by the wiki Kerbin has no eccentricity and a 9284.5 m/s orbital velocity, so if you wanted to "escape" the sun, which I guess means having at least a parabolic or probably hyperbolic trajectory, so we can say you would need to escape Kerbin itself along prograde at (sqrt(2)-1)*9284.5 m/s ~= 3845.8 m/s. And if you want to escape Kerbin's SOI with that velocity, since its SOI distance of 84,159,286 m, at the time you're at distance 700km for example (so 100km above Kerbin's surface) you'd need to be traveling at around 4979.6 m/s. Given that it's a lot easier to do these fine "aims" from orbit where you have the luxury of setting up manuever nodes just right, rather than a straight shot from the surface (at least, easier for me), and at an LKO 100km circular orbit (with a 2246 m/s velocity), maybe budget for having another 3000 m/s DV from LKO, ideally more, to account for the fact that you'd doing this from orbit and so won't have an exactly straight shot on Kerbin prograde? (I would hope the loss of efficiency wouldn't be more than 10%. I'm not quite sure how to adjust the simple calculations to account for when you leave from orbit instead of from straight shot, you won't escape exactly prograde. Maybe someone smarter knows.) Anyway that all seems doable. Though admittedly that's a cheap thing for me to say since I've not tried to do it.

All these craft are yours -- except the ones with heat shields. Attempt no landing with them.

Thank you. Thank you so much. My flights are normal again. I've reverted to my old save (I at least had the foresight to preserve my save folder), re-saved in 1.0.3, and edited them along these lines (more or less). One very small addendum to the reddit instructions: it only says to add "attN = None, -1", but also, if "attN = bottom" is missing (in case you have a craft with nothing attached to the bottom of the heat shield, which I do), you also have to add a line "attN = bottom, -1" for that as well, or the issue will not be fixed for that craft.

Does anyone else observe that 1.0.3 ruined some crafts? Anyway this is what I saw. It looks like every craft I had, with a heat shield and a decoupler on that heat shield, became uncontrollable in a very peculiar way. If I attempted to "fly" that craft, then: some parts of the craft would appear in strange places, no aspect of the craft would appear controllable, I could right-click on parts and observe their status but the usual buttons would not appear, no crew would appear to the bottom right, if at real time (no warp), time would stand still both in terms of MET, and the crafts position would not change one jot, if I used warp forward the camera would focus on the "root" part (whatever that might be) while the remainder of the craft appeared to "fly" behind it (as if the "root" part was still in orbit, but the remainder of the craft had undergone a total dead stop), it was totally irresponsive to all commands, Kerbin appeared to be a flat white circle if close, and turn into concentric white circles with transparent regions if further away (see pictures). All crafts without heat shields attached to decouplers were unaffected, and appear (so far) to be working normally. (The heat shield/decoupler thing could be a red-herring for all I know, it's just the only common factor between all these craft that I saw, that was not shared by other craft that continued to work fine.) Unfortunately, the ones with heat shields attached to were also my crewed craft. So this was incredibly annoying, because I thought for a second I'd have no choice but to declare my dozens of in flight kerbals dead. See some pics (linked, not IMGed to keep the post short): Image 1: Here is one where the center of my craft got "shoved" to the side (note the gap in the middle, and the fuel tank that *had* been there hanging off the side to the right): Image 2: Here is one where my craft was kind of just generally screwed up, and uncontrollable. This one was especially heartbreaking because it had a lot of science on it, with the reusable landers having visited all biomes on Minmus, and all but four biomes on the Mun. The weird white circle is where Kerbin should be. Image 3: Here is a space station in LKO. Note that Kerbin shows up as a flat white circle. Combined, all of my "ruined" craft had 45 kerbals on them, and a total of 9039.5 recovered science from the Mun and Minmus. So it's a good thing I know how to edit the save files. (I've had to edit save files to work around bugs before, but this was by far the most extreme. I built an empty craft on the pad with lots of hitchhiker seats, "moved" the kerbals and science into it from wherever they had been, then recovered the craft.) Otherwise I probably would have had to stop playing KSP for a good few months, because that would have been so heartbreaking. As it is, it was mostly immersion breaking to have to "edit" people into a situation where I could possibly rescue them. Shocking at first -- when I thought I'd lost everyone and 9000+ science, the product of probably man-days of effort, I felt actually like I'd been punched in the stomach -- but I feel better now that I've made a successful recovery through hax. And now I'm filled with a bit of glee that I have 9500 total science to spend. I run Windows 8.1, 32-bit KSP, and my mods are EngineerRedux, Kerbal Alarm Clock, and Contracts Window. I haven't seen any reports of this, and I think people would be slightly more vocal if they had seen I saw, so am I actually unique?

This is very annoying certainly. You hover over a part on your way to place some other part, it changes the symmetry n-arity for you. So you go back to change it, then you change it back again. My solution was to use the "x" key. So even when hovering over a part changes the n-lateral symmetry, you can change it, afterwards, once you've moved past it. (Otherwise it's sort of like playing a game of Operation.) I generally avoid learning hotkeys unless I absolutely have to, but I judged this as one situation where I absolutely had to. I think it would be nice if it only insisted on a certain n-lateralism if you actually placed it on an n-lateral part, instead of just changing on hover.

Exciting ideas. Oculus Rift excels at situating you in some sort of virtual reality, so you could imagine it being excellent while actually flying the craft, landing, etc. (And yes, absolutely excellent in E:D!) I can imagine trying to dock, looking around my craft to see just how well I line up, etc. The HoloLens is about placing virtual elements so they appear to be part of the existing real world, so you could imagine it being excellent in applications that benefit from the use of your hands, say, the VAB/SPH. I like the idea of building KSP rockets on my office floor, like I'm a kid again with my big box of Legos. Both sound exciting.

Maybe looking at it backwards would help you? Not adding boosters to a rocket, but starting with the boosters themselves? Let's imagine you could have a rocket that was just a single SRB. It would have a given TWR, and a given delta-V. Let's imagine you have a rocket with two such SRBs, stitched together. Let's assume for simplicity that your method of stitching them together was "magical," that is, massless, generated no drag, and didn't impact the SRB performance somehow. Obviously such a rocket would have precisely the same TWR, and the delta-V, as the one mentioned above, because it would be just like launching two of the original rocket separately. Let's imagine, further, you have a rocket with one million such SRBs, again stitched together using magical massless/dragless/perfectly rigid twine. This rocket, massive though it may be (being one million times the size of the original), would again have exactly the same TWR, and the same delta-V. Now let's imagine instead of just SRBs, you have some payload -- deadweight if you will. If you have a 4 ton payload on top of 2 boosters, this is not dissimilar to having a 2 ton payload on top of 1 booster. If you have a 1 ton payload on top of one million boosters, this is again just like having a 1 gram payload on top of one booster. 1 gram payload will be neglible, but still (very slightly) worse than if you had just launched the single SRB, alone. So: By switching on "moar boosters," you will increase your TWR, and your same delta-V, but only be asymptotically approaching "ideal" TWR of just launching a single booster, but you will never reach it, sort of like Zeno's paradox. So the Hammer SRB by itself has vacuum TWR of 7.71, and 2202 m/s delta-v. If I have a rocket, and all I use are Hammer SRBs in my first stage, that first stage, no matter what I do, can never, ever, ever exceed a 7.71 TWR and 2202 m/s delta-v in vacuum. I can approach that ideal, but I can never reach it. I think this is one thing you could mean by diminishing returns. Possibly more intuitively clear than Tsiolkovsky's rocket equation.