Eric S

It's a web app that creates parts for arbitrary fairings. I've even managed to create... not sure if interstage is the right word, but fairings that aren't necessarily a nosecone. Haven't tried using it with 0.20 yet, so I don't know if it still works. http://nathannifong.com/FairingFactory/

Minor issue: Your redirector seems broken. Other than that, my only comment was "What, no insignia for 'Lander if we're lucky, Impactor otherwise'?" Followed by "Nope, no need for an Impactor insignia, if the kerbals live but the ship is nonfunctional, it's a Base, if they don't live, there's noone to plant the flag."

Which was shown to be impossible in reddit Jetsetter! challenge thread, where the hard mode challenge was to impact the Mun. Basically, KSP jet engines, including turbojets, have a max speed, and that speed is less than the speed you'd need to reach the Mun's SoI. Not nitpicking, just adding a little info. If you had jet engines that could get you going fast enough before they flamed out, it would certainly be possible, but as you point out, it would involve leaving Kerbin's SoI, even if just by entering the Mun's SoI.

It does sound interesting, but the time limit bothers me, though I can see why it's there.

Of the choices given, I had to go with landing on planets. However, design, both of a mission and a ship to do that mission, is what I enjoy most, especially when I'm going beyond the requirements of the game itself. My mothership to Jool mission, for example, could have been done by a much smaller craft, but I included hydroponics and a centrifuge to support the crew, which was also much larger than it needed to be, since I can only control one kerbal at a time and never had kerbals in more than three places at a time.

Technically yes, it's even a spaceplane. I just need to work on it so that I can do something other than get into orbit, then deorbit and land. No cargo capacity, no RCS, not even sure how far beyond a 100km orbit I can get it, so it's pretty much just a checkmark on what I technically can do at this point.

As for the airbags, I haven't tested it to make sure it still works in 0.19 or 0.20, but I used the mod CP Airbag System back in 0.18 and it worked fine then.

That may be true in some specific case, but it's not generally true. If you have four tanks that are in separate radially mounted stacks and connect a fuel line from each of them to one central fuel tank, the game's fuel flow logic will take fuel equally from all four tanks. If, on the other hand, you have four tanks arranged in two stacks (two tanks per stack), then even with all four tanks having fuel lines, it will drain two of the tanks first, then the other two. In fact, if you have tanks stacked on top of each other, there's no reason that I'm aware of to run individual fuel lines for each tank.

The one time a retrograde orbit makes sense is if you're doing your planetary transfer burn with an ion drive and you're transferring to a planet farther out. A retrograde orbit in this case means that you can use solar panels to power the ion drive for the burn, rather than being in Kerbin's shadow when you want to burn.

rescaleFactor should always apply to nodes, but I've heard of bugs in that respect. scale doesn't apply to nodes.

Read "World War Z"? Part of what bothers me about the movie adaptation is that the movie follows your attitude (slow zombies not a threat, must use fast super-zombies), but the book spent time explaining WHY slow zombies would be an actual threat even to the military. While the book has some combat with zombies, it's much more about why society as a whole falls to the zombie horde, and how it (and its military) adapts to overcome the challenge.

Just to make it obvious when that turns up, the default rescaleFactor is 1.25 so if you don't specify one, that's what you get. That happened when they added EVA to the game, and they needed to scale everything up so that it would look like a kerbal could actually fit inside the 1-man capsule. Specify a rescaleFactor of 1, and you get what you expect if you didn't know what the default was.

For my mothership to Jool mission, I decided on a crew of 12 kerbals. I went fishing with Kerbal Crew Manifest (this was before KCM would let you edit kerbals) trying to get a few recognizable names (the youtubers that have been honored in game). I managed to get two recognizable names, though not youtubers. Kirk and Dilbert. Decided to make Kirk second in command, You'd expect Kirk to be brave, but he was a screamer. And then, I kid you not, Kirk had something happen to him that I will never forget. During the mothership's shakedown cruise, it went out to orbit Minmus. By the time I had burned off enough fuel to depart Minmus (but still in it's SoI), I had used up the fuel in the HOME habitat modules, so Jeb was transfering the worst of the screamers to plant duty. Anyone remember the bug with the DSM spherical pod that when you'd EVA a kerbal from that pod, they'd wind up getting shot away from the ship at high speed? This is when I became aware of it. Managed to bring Kirk to a stop then bring him back into the ship, but the whole time I'm already thinking of how this was going to read in the captain's log. "A side note, if Kirk alleges that I tried to strand him on an ice moon, I'd just like to clarify two things. First, it was an equipment malfunction. Second, we had already burned to escape Minmus, so at least initially it would have been a highly elliptical Kerbin orbit rather than a Minmus impact." Dilbert was very calm about things, and wound up becoming second in command in the wake of Kirk's demotion.

But still rates as hard-core sci-fi compared to typical SyFy channel content (is that how they spell it now? They haven't had much I'd be willing to watch on for years).

Not sure they'd go quite that far :-) Truth of the matter is that asparagus staging wouldn't be as effective in real life as in KSP, and not because of aerodynamics. KSP planets are smaller and closer together than those in this universe so that we don't have to spend as much time achieving orbit or landing. However, in order to have the smaller distances not make everything easy-mode, the TWR of the engines are much lower than real engines, and the dry mass of fuel tanks are higher than similar real fuel tanks. Since asparagus staging is all about emptying and discarding fuel tanks and the engines that lifted those fuel tanks as fast as possible, the win wouldn't be as large with realistic fuel tanks and engines. Really, asparagus staging is the natural reaction to less efficient fuel tanks and engines, combined with the magic fuel lines. Assuming that all the technical issues could be worked out (just what all the technical issues are is an entirely separate topic), asparagus staging might see usage in our reality, but it wouldn't be as world changing as it is in KSP. Also, it's too early to say that asparagus staging will never be used in reality. The cross-feeding that the Falcon Heavy will be using was first envisioned in 1947, and I think the Falcon Heavy is the first common rocket that will actually use it. Likewise, asparagus staging wasn't invented here, but it's going to be just an idea on paper until the issues get worked out for us, unlike our kerbals.

As I understand it, we'll have the current level of info available on the currently released planets without discovery, the discovery is for new planets.

Solid rockets not getting counted is a known bug introduced when 0.20 came out. I think it affects MechJeb as well, but I'm not certain. As for asparagus staging not adding much, it's not like it will double or triple your delta-V, and it's easy to get it wrong until you've got some practice with it. If you want, upload the .craft file somewhere and I'll take a look at it.

I can't think of any reason for that craft to be out of balance. My only suggestion is to swap the LV-T30 out for an LV-T45. The probes have almost no reaction wheel command authority, the LV-T30 doesn't have vectored thrust, and you have no other control on that craft.

As of 0.20 (or was it 0.19?), using a probe first then a manned pod still results in the game populating the manned pod. I either EVA the kerbals before launch, or use Kerbal Crew Manifest to unload them and then fly the rescue craft from a pod, since that way I can't mess up and strand even more kerbals somewhere.

Yeah, last time I saw a poll for age range for a video game (I think it was KSP but I'm not certain) the end range was something like 25 and up, and the person was shocked that he got as many 25+ responses as he did (I think it was the highest category, mostly because he broke down the sub-25 groups into 4-6 year brackets). Not as bad as the time I was asked that if I was over 18, why was I still playing video games. I'm not sure if the person thought that adults lose interest, or that adults have more interesting things to do. I just told him "Because it's fun. Trust me, going out and getting drunk gets old really fast unless you're very easily entertained." I think the last time I went out with the intention of getting drunk was back when I was... 23? Over half a lifetime ago.

As I understand it, the problem comes from when the ship has to reorganize the parts tree. This happens to one of the two craft whenever you dock two craft, they become a single parts tree. Parts of the craft that gets subsumed that are between the real craft root and the docking port wind up having to change their parent part, and some parts, notably the cubic octagonal strut have problems with this, for some reason.

To the best of my knowledge, RCS thrusters work fine when blocked, liquid chemical engines don't. If ion engines fall into the "works fine" category, it may be that it's the liquid engines that have a check that other engines don't rather than RCS skipping that check.

That would tell you the breaking force/torque of that one part, but wouldn't tell you what the default is, so you wouldn't know what the breaking force/torque of a part that didn't explicitly have those values in the config would be.

I think that's a little more accurate. I'd probably use the term depart rather than launch just to try to be more clear about what fuel you're interested in tracking. What it comes down to is that if you're shipping all your fuel up from Kerbin, it will take more fuel total (including the fuel for getting the fuel into HKO) to depart from HKO than LKO, but the ship leaves the Kerbin SoI with more delta-v on board. If, on the other hand, you're mining kethane on Minmus, then LKO has less of an advantage. Several months ago, before the forum rollback, we did a pretty thorough writeup on LKO refueling versus refueling in Minmus orbit. The conclusions were basically: 1) If you're not mining kethane, the only times refueling anywhere but LKO made sense was if your delta-v budget was insanely tight or if the ship that needed to be refueled was somewhere other than LKO and couldn't easily return to LKO, and neither of those cases were common enough to really worry about. 2) Departing from Minmus made sense if you had refueling facilities on Minmus and either were on a tight delta-v budget or you'd need to refuel anyway. 3) Departing directly from Minmus saved some post-refueling delta-v over departing from LKO, but there was an alternate strategy that did much better. Basically, burn away from Minmus like you're returning to Kerbin, keeping your periapsis at about 80km, then burning at periapsis to reach the necessary velocity for the transfer. The timing on this is tricky, but for a Duna transfer, it would mean using less than half as much post-refueling delta-v compared to refueling in LKO. Since that's a mostly linear savings, it's not going to make a radical difference if you're going to Moho, but again, if your delta-v budget is tight, it might be essential. If the delta-v budget isn't tight, it isn't worth doing it unless you're confident you can manage the transfer timing accurately, as course corrections can eat through your savings and then some if the timing is off.

Nope. In fact, hyperthreading is one of the things used to distinguish Haswell i7s from i5s. I don't know if this was true of previous generations.