IncongruousGoat

"Footfall" by Larry Niven & Jerry Pournelle is a great deconstruction and... er... reconstruction? of the alien invasion story. "Nor Crystal Tears" by Alan Dean Foster, for an interesting take on first contact.

Well, (historically, at least) spacecraft guidance didn't bother trying to adjust for the effects of the atmosphere. Guidance programs used a preprogrammed pitch v. time table up until they'd mostly left the atmosphere, only then switching to some closed-loop guidance program and correcting for any deviations that may have occurred during ascent. Trying to actually account for aerodynamics in real time is really, really hard when you've got restricted computing capabilities, and most of the time it just isn't worth it.

You're probably looking for kOS, which not only lets you program actions ahead of time, it lets you write entire scripts for your craft to run. And yes, it's perfectly compatible with RemoteTech.

Atmospheric or vacuum TWR? Some engines (the LV-909, for example) will produce a decent amount of thrust in vacuum, but turn anemic the minute they encounter any semblance of an atmosphere.

To be honest, I'd rather SpaceX produce a practical suit that's a measurable improvement over current pressure suits than one that just looks cool. Obviously, Musk being Musk, it's going to look cool regardless, but hopefully the rule of cool doesn't supersede practical considerations. Better it look bland than be bland.

Despite what @Foxster might say, calculating dV by hand really isn't that hard. All you need is the Tsiolkovsky Rocket Equation: dV=Isp*9.807*ln(mw/md), where Isp is the specific impulse of your engine, mw is the stage wet mass, or the mass of the stage when it's full of fuel, and md is the stage dry mass, or the stage mass when it has no fuel left. Just remember that dV has to be computed for each stage individually, with your total dV equal to the sum of the stage dV values.

Unfortunately, I'm stuck in upstate NY, with neither the time nor the means to go see the eclipse. I guess I'll just have to wait until 2024.

Also, Atlas isn't exactly the easiest thing in the world to fly. You might want to try something more like Titan II, or R7. Those at least have clear staging sequences, instead of a precisely timed engine jettison. If you're flying Atlas (I'm assuming this is the ICBM we're talking about and not, say, Atlas V), and you have TestFlight installed, it's very possible you're not flying Atlas's launch profile correctly. Atlas uses a stage-and-a-half design, where the booster engines (LR-89) are jettisoned 133 seconds into flight, while the sustainer engine (LR-105) carries the payload into orbit. If you're not jettisoning the booster engines, you're exceeding their rated burn time and causing engine failures.

Wow. It's been a while since I posted anything here. Real life has been preventing me from devoting the attention I'd like to this, but I managed to eke out another mission. This time, we head for Dres and Eeloo, in an effort to nail a few more building upgrades before we head for Jool. The album (relink) has been updated with screenshots, for those seeking even more details.

I last searched "xkcd what if metal lakes", which lead me to What If #50. I have lakes of liquid mercury, bromine, gallium, tungsten, nitrogen, and helium. And a rowboat. With all these liquids at my disposal, dealing with a few zombies shouldn't be too hard. Just pushing them into any one of these lakes (well, maybe not the mercury or gallium ones) would be instant zombie death. If that doesn't work, there's always the rowboat. Zombies aren't too good at swimming, and with a little luck and planning I should be able to make it to another continent, preferably one without zombies.

Well, I've got a steam engine, which lets me... start the industrial revolution again? Honestly, this doesn't end well for me.

It would seem the mush is back. Edgas would be proud.

I take it KSP's auto-backup saves won't load either?

Windows 7 x64, because I've been using it for a while, I don't like Windows 10, and switching to Linux is more hassle than I want to go through. Not to mention that I dislike every extant operating system, and so it's easier to just stick with what I have. I'd be dissatisfied either way, so...

Considering the difficulties they've been having with clustering 27 engines on FH, they might not want to try and cram as many engines in as possible, if it means compromising combustion/structural/aerodynamic stability. Furthermore, superficially it makes sense that they would try and have as many engines as possible, so they can have a bigger tank and carry a larger payload. However, they can't just extend the tank ad infinitum-F9, for example, is as long as it can physically be without compromising its ability to withstand aerodynamic forces. Also, all of this begs the question: How are they going to transport a 9m booster from Hawthorne to the Cape? They can't use the Interstate like they do for F9-they'd have to use a boat (slow, comes with risk of saltwater corrosion) or a custom-built airplane (expensive)

There's something else disappointing in all of this: SuperDraco is now no more than a fancy re-usable LES motor, since SpaceX isn't going to be using it for propulsive landings and it's overkill as a maneuvering engine.

More progress! This time, we visit Gilly, in a much less ambitious, much less elegantly designed mission. Because patience and efficiency can go to the birds-I have funds coming out of ears. No spoiler/highlights this time-the mission was as boring as can be. Mission album (re-linked here) has been updated with screenshots.

My browser seems to be having trouble with the 'M's

That appears to have sorted it. Thank you.

@djungelorm Well, the project seems to have built mostly okay. The problems resume at compile time. For some reason, Cygwin's g++ linker can't find -lkrpc. Is there some .dll or .a (or similar) file I should be adding to PATH to placate g++?

This mod sounds fantastic. It's exactly what I didn't know I absolutely needed, and I would love to use it. However. The configure script for the C++ install would appear to be quite, quite broken when trying to install through Cygwin. The script itself fails at checking for asio.hpp usability and presence. Examination of config.log reveals that the problem stems from a plethora of g++ compiler errors, stemming from a missing -D__USE_WIN32_SOCKETS compiler flag somewhere. I would try and add the flag in myself, except that configure doesn't actually appear to contain the compiler call in question. The error occurs at line 16700 in configure. What am I doing wrong/is there any way to fix this?

After one heck of a mission, the Duna system is officially complete. I've decided to put the details of vehicle assembly into a spoiler, since the process was rather involved. The actual trip to Duna and Ike was unremarkable, other than some clever Oberth Effect exploitation off of the Ike escape burn. Screenshots have been added to the full album. It turns out that eyeballing things really isn't that hard once you have patched conics.

You'd build all the avionics yourself. Nobody sells dedicated guidance computers. The program itself would either be written in some assembly, or in C if you can find an appropriate compiler. So, the same way you'd go about programming anything else custom-built around a microcontroller.

Did anybody else notice the engine gimballing at the beginning of the burn?

The ring is there to hold the engine bell's shape. The bell extension doesn't actually have any structural reinforcement-it's just a flimsy sheet of metal. When the engine is firing, the bell is held in shape by the pressure of the expanding exhaust gas, and when the rocket is coasting in orbit there aren't any external forces to warp the bell. On the pad and during launch, however, the bell undergoes a lot of external forces. Hence the ring, to stiffen the bottom edge and hold the nozzle shape together.