cantab

Now we have the asteroids, there's unlimited science. And to collect all the science from just one asteroid requires you to take it to all the possible situations. THAT would be quite the feat, considering it necessarily involves an ascent from either Eve or Jool.

IMHO one of the more promising approaches is air launch. That's how Scaled Composites did things for their suborbital craft, and Orbital Sciences have been launching their Pegasus rockets from carrier aircraft for a couple of decades and are now designing the much more capable Pegasus II. Air launch to orbit could really benefit from a suitable supersonic carrier aircraft. There'd be new aerodynamic challenges of course, but it would shave yet more delta-V off the requirement for the rocket itself. Unfortunately aircraft development has shown no signs of going in this direction since Concorde. Some strategic bombers could be suitable, such as the B-1 or the Tu-160, but that would depend on considerably military co-operation.

I believe - but am not sure - that it's generally best for each stage in a serially-staged rocket to contribute about the same amount of delta-V. So for a two stage to orbit launcher it'd be about 4500 m/s a stage.

I don't know exactly how different rockets do things, but one option would be a bladder tank, with the propellant inside a flexible container and the pressurising gas outside it.

Took a penalty. It was not exactly convincing...but after a few attempts I did manage to get the ball over the line.

Well, the footballs make a nice little toy. They must be about the only thing in KSP that isn't made of explodium! Bounce pretty well, but I haven't been able to curl the ball. Seem a bit rough around the edges though. The attachment point isn't matching the surface of the model, and the angle they're fired off at seems to behave oddly, in that I can rotate the parts and get no change sometimes. And I was greatly disappointed not to get a "Kick" option when I EVAed a Kerbal over to the ball.

I'm not a lawyer, but I believe there's two main approaches a software developer might use to restrict the distribution of mods of their software. The first is to claim the mod is a derivative work, and thus as the copyright holder of the original work they have considerable power to restrict the distribution of the derivative. I don't know if there's any case law on whether a mod is considered a derivative work though. The second would be to claim the restrictions are part of the contract, ie the EULA. That might be less likely to hold up since contractual terms can be deemed unfair or otherwise void by a court, but then again I suspect that an outright ban on modmaking and mod distribution would be upheld, and that's more restrictive than an only-through-official-channels rules. Again, no idea if there's been any similar cases in the past./armchairlawyering

I don't expect to be picked for the forum squad. In any case, I reckon Reddit will take the cup, their history with their challenges is strong.

Naturally Curse are going to want any "official mods" to be hosted only on Curse, whether or not this is a contractual requirement. Equally naturally, Squad won't feel hosting their stuff on Dropbox or Mega would be very professional. Though it may be legally possible for Squad to in future mandate that third-party mods be hosted exclusively on Curse, I think - or at least hope - they recognise the backlash that would cause. Not to mention suing your mod-makers, which they'd have to do to enforce any such policy, would be business stupidity. Personally I object to them being called "soccer balls". America might call them that but the rest of the world knows them as footballs

E class asteroids certainly do run up to three thousand tons, with rumours of even heavier ones. Here's the one I encountered: Big E Class by cantab314, on Flickr The only thing clawed is the little "lander" you can see, so almost all the mass given is that of the asteroid. I didn't even try to move it, the mission was a simple visit.

When you know how it works it's easy enough. (Just put your higher drag coefficient parts, for example stowed parachutes, at the rear.) The stock aerodynamics may be unrealistic, but they're at least fairly simple and easy to understand, and they haven't stopped players building some pretty neat aircraft. And the air's better than the water, at least.

For Minmus, I would recommend sticking your apoapsis out near Minmus's orbit to get a close intersect, then making a mid-course correction for the inclination to hit its SOI.

It's perfect for mission planning, but by itself it doesn't help you visually appreciate things. Personally I do find that while I can easily make interplanetary transfers by doing what Alexmoon's calculator tells me, I don't feel I really understand them.

Even without extra ladders, you can still fly so the command pod is close enough that you can switch to Jeb and grab it. It's difficult - it will probably be one of the most challenging things you do in KSP - but it's possible.

Claw gave the dV estimates for your first ship. For your second one, I make it ~870 tons wet and 110 dry. Pushing a 3000 ton asteroid, you'll have ~800 m/s of delta-V. Of course once you're there you won't have so much fuel left. Plenty enough for an aerocapture, but not enough for a purely powered one. As for matching inclination with the asteroid's predicted path, well the best thing to do is: Sit the rocket on the pad. In map mode, target the asteroid. Wait until KSC is under the asteroid's predicted path. Launch, and make your pitchover in roughly the right direction. In map mode, try and keep your trajectory in line with the asteroid's path. But if you've already launched into an orbit with the inclination way off, your next best option is: Burn at or opposite the ascending/descending node to raise your apoapsis nice and high, but be mindful of how long your orbit will take. And you want your apoapsis towards the "open" side of the asteroid's path. Burn to match inclinations at apoapsis, this will take much less delta-V than doing it in a low orbit. Burn for ejection near periapsis. It applies for when you're going to intercept the asteroid in solar orbit. You leave along the path it's predicted to arrive, which means that when you're still in Kerbin's SOI you want an inclination 180 degrees from the asteroid's predicted path.

I don't have exact figures to hand, but I do recall that I find 860 m/s not quite enough for a Mun transfer, I often end up using more like 900.

I believe the drives are the element most holding back everyday use in my current PC. Either that or the encrypting file system. But with 1.3 out of 1.5 TB used - and I've hit higher in the past and had to delete stuff to make space - an SSD-only system won't be economical, and putting the OS and software on an SSD won't help my files load more quickly. Back to the original topic, yes 34% fragmentation is a lot. What's your total disk space usage? If you have very little free space, I believe that will slow down any defragmentation and make it hard to get good results. So it may be best to free up some space before the defrag, even if it's only temporary and you copy the files back aftewards.

I'm trying to understand how KSP's water physics work, so I can build nice floaty things without simply spamming radial intakes. So far, all I'm finding is that it's screwy. Here are some tests I've done using some simple craft. All fuel tanks are empty. The craft with 2 400 tanks is exactly twice the mass and twice the length of the one with a single 400 tank, therefore I would expect it to float with the same fraction of its length below the waterline, as long as the visible water lines up with the physical water. The craft with the 800 tank is the same as the one with 2 400 tanks except for changing the tanks, therefore I would expect it to float identically, even if the visible water and physical water are consistently misaligned. Instead, I get these results. [table] [tr] [td] Low Detail, 400 tank by cantab314, on Flickr[/td] [td] Low Detail, 2x 400 tanks by cantab314, on Flickr[/td] [td] Low Detail, 800 tank by cantab314, on Flickr[/td] [/tr] [tr] [td] Medium Detail, 400 tank by cantab314, on Flickr[/td] [td] Medium Detail, 2x 400 tanks by cantab314, on Flickr[/td] [td] Medium Detail, 800 tank by cantab314, on Flickr[/td] [/tr] [tr] [td] High Detail, 400 tank by cantab314, on Flickr[/td] [td] High Detail, 2x 400 tanks by cantab314, on Flickr[/td] [td] High Detail, 800 tank by cantab314, on Flickr[/td] [/tr] [/table] I don't know what to make of these really. Low terrain detail seems to throw the visible water level, which I somewhat expected. More baffling is that an 800 tank has different buoyancy properties to a pair of 400 tanks. I've looked in the part.cfg's for anything that might hint at buoyancy, hypothesising that maybe part scaling throws things off, but the 400 and 800 tanks differ only in name, node positions, tech tree position and cost, description, mass, and fuel and oxizider capacity - in short, nothing that I can see that would make the pair of 400 tanks float higher than the single 800 one. So what's going on? How exactly does KSP work out part buoyancy?

This is wilfully dishonest. You are trying to make it look like the bad stock aerodynamics will result in your probe breaking, when that only occurs because YOU installed a mod that makes it break. And when you haven't even shown that your probe would survive if it faced the way you want.

I don't know exactly how much kethane to expect on Minmus, but I know it's nowhere near enough. Even if you stripped the whole system of its kethane you'd still be many orders of magnitude short.And if you tried to make the kethane from Kerbals, recording the names and stats of each one would probably make your persistent.sfs fill up your hard drive.

You'll see plenty of Kerbals getting scared during launches, but not many who aren't happy once they get into space. They don't need much motivation, just promise them that this launch is the one that will reach space this time and definitely won't nosedive into the VAB again and they'll be racing for the command pod.

The most efficient engine in stock is the PB-ION, with an Isp of 4200 s. To get 29 m/s of delta-V out of it requires a mass fraction of 1.0007. That may seem hilariously small, but Minmus weighs 2.6 x 1019 kg. 0.0007 times that is still around 18 trillion tonnes of fuel. If you had a xenon version of the giant Kerbodyne tank, with the same wet and dry masses, you'd need 250 billion of them.

The key thing to know is that the celestials in KSP are "on rails" on simple Keplerian orbits. There's no secular variation, and certainly no actual physics simulation on their orbits. This makes calculating their positions at any given time pretty easy. Tools that simulate planetary motion based on gravitational forces are overkill and will actually give results that diverge from the game. All you need are the orbital elements, which you can get from the KSP Wiki or I believe from some mods, and the equations which you can probably find on Wikipedia. With that simplicity in mind, doing it in Excel is IMHO perfectly reasonable to get static pictures at a chosen time, though I wouldn't attempt an animation in it.

Very likely. By default Kerbal Alarm Clock backs up your save any time you let it switch you to a different ship. These backups are stored in your save's folder with fairly self-explanatory names. With KSP closed, first make a copy of your current persistent.sfs, then make a copy of the appropriate backup (probably the one with the newest date) and rename it persistent.sfs.

This is a great approach, very tempted to copy it.