Meithan

Back in the days we had this: KSP Parachute Calculator Sadly, it hasn't been updated in ages, last time being way before 1.0 came out (which heavily changed the aerodynamics of the game), so its results are probably not correct now. Calculating terminal velocity isn't hard, though, so it should be possible to mathematically deduce a rough rule of thumb for parachutes.

My first screenshot is a bit more mundane than many others here: it's a screenshot of my first orbit, back in June 2013 (this was 0.20). There was a definite sense of achievement in getting to orbit for the first time. And it heralded many others that would come later (I remember my first Mun landing and my first docking).

I'm not basing my feeling on people who write on the forums, but on Steam's general success as a game-distribution platform, which is due to 1) widely known and good publicity; 2) very convenient and fast distribution (i.e. download); 3) great prices (I've bought many a game during a Steam sale that I would perhaps not have bought otherwise). But again, this perception could be wrong. A poll on the forums, maybe? It would be biased towards the most active players, but I can't think of any other way of clarifying this. KSP was first available on Steam as early-access. I started playing around 0.20 iirc, and I've used Steam since the start. That was in May 2013.

It's hard to say without having an idea of what proportion of KSP users play through Steam. I just don't know. But I somehow suspect that Steam is the dominant platform for KSP.

steamdb has nice info on the number of concurrent Steam players (which is much less than the total number of persons who have bought the game and a better indication of the size of the active community); I'm attaching the graph below. The largest peak, which surpassed 17.5k players, was due to release of the game (i.e. 1.0), while other substantial but temporary player increases correspond to version updates (0.25, 0.90 and 1.1) or the Christmas holiday season. The fast oscillations are week cycles (people play more on weekends). All in all, we're talking about a 4-5k constant player base, at least on Steam. Hard to tell how the numbers look outside of Steam or on the console.

Perhaps I'm a bit late, but here are my tips based on my own Jool 5 Challenge (see the link in my sig for the full report; mind you that this was pre-1.0). From my notes, I see that landing took 2529 m/s, while takeoff required 2364 m/s (plus 26 m/s for rendezvous with my tug in orbit). The Tylo lander had a total delta-v of 6231 m/s, so I had plenty of margin (I overengineered it a bit). As for TWR, the landing and takeoff stages never went below a Tylo TWR around 2, while the last stage (starting halfway through ascent) had a slightly lower TWR of 1.7. The most important part is the landing TWR; I'd suggest you don't go below 2 for that. This is the Tylo lander that I used, a one-man three-stage asparagus design: Two of the four side tanks/engines were jettisoned during descent (after spending about 1200 m/s): This is what it looked like landed on the surface: Takeoff started on three engines, and the two side tanks/engines were jettisoned midway through, with only the central stack reaching orbit:

I just captured this ~1400 kg spacecraft around Moho using a single ion engine, after a standard midcourse-plane-change interplanetary transfer. Acceleration was about 1.5 m/s^2, so the ~3500 m/s capture burn took 40 minutes, or about 10 minutes at 4x physical timewarp. It requires some patience, yes, but it's certainly doable.

Great post, Snark. I was just about to start designing an unmanned trip to Moho in my career save and was beginning to consider using ion engines simply because 1) they're cool (dat Isp), 2) there's a lot of sunlight at Moho. Your post pretty much resolves the worries that were starting to crop up about such a mission. The retrograde orbit suggestion is one I hadn't thought of, too. Good one!

Scott Manley decided to set things right:

Here's how I do it, using a phasing orbit. It's perhaps not fuel-optimal, but it's not too wasteful either and is much easier than other more fuel-efficient strategies. Works every single time. Launch into an orbit as close to your target's orbit as possible but ahead of your target - the closer you are to the target, the less fuel you'll need to rendezvous, but it's important that you're ahead of it, so being ~30° ahead is ok. This is much easier than trying to precisely hit your target on launch. Wait until the ascending or descending node between your orbital planes and zero out your relative inclination. It's important to closely match the orbital planes only; matching Ap and Pe closely is not necessary. Now simply choose a point along your orbit where you'd like the rendezvous to happen (e.g. in sunlight), set up a maneuver node and pull on the prograde thingy. As you raise the apoapsis of your projected orbit, you'll see one of the close approach markers start to move, go around the projected orbit, and eventually meet the other (which remained at periapsis). Further tweak the maneuver to minimize the closest approach distance and you're set. The point of the this phasing orbit is to have a longer orbital period so that the target (which is behind you) catches up. Perform the maneuver and you'll rendezvous at the next periapsis. You can further fine-tune the closest approach at apoapsis of your phasing orbit. Hope this helps. I'd illustrate it with diagrams but I'm in a hurry right now. Might do it later.

Well, the flight computer commanded the abort automatically after determining that the thrust levels were not as expected. It's not like it had to time it just right or the rocket would launch. The rocket only launches if the flight computer OKs everything after the engines are lit.

It's a "full-thrust" Falcon 9 v1.1.

Hi all! After a long, long KSP dry spell, I'm finally back to the game a bit and also to development of the webapp. I'm pleased to announce that I just rolled out version 1.1 on my new webhost: http://meithan.net/KSP/engines So update your bookmarks, folks. Apart from updating to KSP 1.0.5 engine stats and a lot of code refactoring, version 1.1 brings a new feature: the user can now select which variables to plot and which to hold fixed, out of Payload, Minimum TWR and Delta-v. It's common that one has a specific payload mass in mind, and wants to have an idea of what engines are good for a range of jobs. Or maybe one has a particular mission's delta-v in mind and wants to determine what engines would be appropriate for a range of payload masses. I also uploaded the project to Github, for personal convenience and for code sharing (it's all GPLv3, of course): https://github.com/meithan/engine_charts. Feel free to browse the code, fork it if you so like or submit pull requests (@gfrodo will be particularly interested, I gather). The next feature on the roadmap is to add alternative ranking choices for what's considered the "best" engine: I'm thinking propellant mass and tankage+engines total cost as obvious choices. It shouldn't be too hard to implement but let's see how the week's work comes out. Cheers all, and thanks for your interest and support (bug reports welcome of course).

Well no, my point was that the result of dividing a nonzero quantity by zero can technically be considered to be infinity, so your score would then be the worst possible, not just undefined. But I'm just joking as well. Let's not drift too much off-topic.

Well, if you keep the cost of the rocket fixed, as the payload mass approaches zero your funds/tonne approaches infinity. So you'd have the worst possible score. Sorry.