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.

Norcalplanner, work's looking a bit daunting on this side too, but I think I can manage scoring entries and helping you maintain the leaderboard. I was thinking of 2 or 3 mass tiers myself (maybe an ultra-light 2 tonnes tier?). Let's discuss the details. I'm about to go out right now, so I'll only be able to PM you until tomorrow, if that's ok with you.

Fantastic work, maccollo, that design is not only super efficient but also shines for its simplicity. I wonder, though: is it possible to scale it down? Which brings me to the following. Now that Norcalplanner is thinking about closing the challenge in its current form (since, I agree, it seems you guys have reached the highest efficiency level possible), I think it would be interesting to see what kind of cost efficiency can be obtained for smaller payloads. As Slashy originally pointed out, there's an economy of scale for rocket design in the game, which is reflected by the fact that all current entries in the leaderboard (except one) have payload masses above 100 tonnes. While heavy launchers like these are certainly useful, there's also a "market" for smaller payloads in the game. For instance, most satellite launch contracts for Kerbin's SOI (I must have completed a few dozens) can be fulfilled with a satellite weighing less than 2 tonnes, and many functional (in a Career mode sense) crew shuttles, basic space stations and mining ships (to name a few examples) can be designed and built for in-orbit masses usually not above, say, 30 tonnes. So what do you guys (Norcalplanner, specially) think about this?

The new ruleset sounds great, I really wouldn't change anything. I liked the form of the reaction wheel rule. Hope the others agree with it so we can start (and I'll try to work out an entry this weekend).

Norcalplanner, I understand your reluctance to do fundamental changes to the rules with the challenge ongoing, but I'm afraid I have to side with Temstar and Slashy on this one: I vote for an inert payload. That way the challenge can focus on the lifter exclusively, seeking designs that are practical because they will work for any payload that fits the mass bill. Factoring in the "but the lifter usually separates just before orbit in practical designs" is still achieved by demanding the periapsis to be high but not all the way to 80 km. With an apoapsis of 80 km, circularizing a 1 km periapsis costs about 70 m/s (the current 500 m/s allowance corresponds to a periapsis of -300 km, by the way). Thus, demanding an inert payload but only a suborbital periapsis is effectively equivalent to having the payload finalize the circularization (as done in practice), but eliminates the lifter dependence on payload design. While we're at it I'd also say that "inert" should include clear wording regarding reaction wheels on payload. I'd be OK with allowing one (but no more) reaction wheel in the payload to mimic practical conditions, but I don't know what you and the others feel about it. Having electric charge and guidance on the payload is fine IMO, since in practice this is almost always the case. The point should be to encourage cheap and practical (cheerful, really) general-purpose lifters.

Alright, I'm sold. And looks like your link is broken, I get a "This video does not exist" error.

Yeah, I didn't mean a full LFO-only asparagus design; it's clear that SRBs are needed in the lower stages due to their high TWR and low cost. I was thinking more along the lines of drop tanks. The central LFO core in maccolo's last entry is pretty big: at some point it's carrying two empty orange tanks. Would the increased drag and extra cost of decouplers/fuel lines outdo the mass saved by being able to drop those tanks as soon as they're empty?

Impressive, @maccollo. So the "drop tanks", as Slashy calls them, empty before the SRBs burn out, right? How soon before (can't see video at the moment)? Because you're carrying empty tanks from that point until the SRB clusters separate. Why not use proper drop tanks? In fact, why haven't we seen more asparagus designs? For rockets in that payload class, a radial decoupler and a fuel line are almost insignificant in terms of cost and mass. I guess it adds up?

Wow, that webapp is actually pretty cool. Ha, I got a Moon encounter on my first try (no idea about proper phase angle for Earth-Moon transfer)! Lucky.

You could figure out the volumetric density of ore from the size of the stock holding tanks. Go to the VAB, and locate one of the holding tanks in the parts menu. Next to the rotating icon you'll see a little size scale, in meters. You can estimate the tank's height H and diameter D from that, and then it's simply a matter of dividing the tank's ore capacity (in "units") by the volume of the tank (it's approx. a cylinder, so its volume is V = pi*(D/2)^2*H).

@EdFred: I don't think those maps were computed optimizing for cost either. As KerikBalm pointed out, the atmospheric Δv's are not unique values since they depend (even more strongly now) on a variety of factors (rocket streamlining, per-stage atmospheric TWR and Isp curve of engines, ascent profile, piloting skill, etc.). Because of this, I wouldn't think the stated values are optimal values: I'd think they're intended to be representative "typical" values with an "average" rocket design / flight profile / etc. It's better to err on the safe side in this case, since there can be a large variability in actual performance. And 3500 m/s for ascent to LKO is an approximate value that reflects my experience in general. I measure this with MechJeb, by the way, which shows you how much was lost to gravity, drag and steering, with Δv_spent = final_orbital_velocity + (gravity_losses + drag_losses + steering_losses). @technion: It's probably more my optimization OCD than anything else. One has to optimize for [i]something[/i], right? :P. But I don't feel I have got to the point where money is irrelevant yet (I've about 12 millions in the bank ... is that enough?).