IncongruousGoat

Wow. That is one creepy album cover. Good song, though.

Tackle one of the Heritage Challenges. There's a reason they've all stuck around for as long as they have. I'm personally fond of the Jool 5 Challenge, Eve Rocks, and the Caveman Challenge, but they're all good, really.

I don't. I think this is just the rose-tinted nostalgia goggles talking. Hasn't been my experience of older titles at all. Not exclusive to older games. Look at games like Papers, Please, Factorio, and Return of the Obra Dinn. Especially Return of the Obra Dinn. All very high quality, and all with rather low graphical quality compared to modern tripe-A games. Or KSP, even. Sure, it's better than any game you'd find 30 years ago, but by modern standards it doesn't look particularly good. This is especially true if you go back a few versions, before the recent part/texture overhauling. Or heck, if you go way back to the pre-.18 look. Didn't stop people from picking up the game. Plenty of indie games have gone for the retro aesthetic have made it big... and plenty that have tried for that aesthetic have flopped. Graphical quality is not negatively correlated with quality of mechanics. See above. Already been done. Your gripe with Elite: Dangerous seems to be that it didn't do the one thing it sets out to do well, and your solution is to have it try and do more stuff? It's not sufficient to say that such games are fun, since they're typically hard to develop. It's hard enough to make a good game that only tries to do one thing. It's an entirely different level of difficult to have a game that does several radically different things without any of said things feeling out of place or notably worse-designed than the others. The problem, I think, is not that games have been getting worse over the years. Rather, it's that there are simply a lot more games on the market, which makes it harder to separate the wheat from the chaff, as well as giving the impression of a flood of terrible titles. EDIT: Also, why do you use the word "dangerous"? You seem to be arguing that they're worse, but a bad game isn't necessarily dangerous (and a dangerous game isn't necessarily badly made).

A depressingly accurate picture of my current feelings about my life:

"Someone burned their dinner and opened the door to the hallway instead of the window." Explaining to someone why the fire department showed up at our building tonight.

No, I'm seeing it too

Or you can do what @JacobJHC did, and swap out planet packs in the middle of the mission. He ended up landing on Eeloo 3 times - once for stock Eeloo, one for OPM Eeloo, and once for some other planet pack. EDIT: Note that this planet-pack swapping should only be done to handle cases where the planet pack modifies the stock system. You can't just uninstall a planet pack in the middle of the mission if, say, one of the bodies it installs gets in your way.

State bureaucracy can really get on my nerves. So, some backstory: A few months ago, I moved from New York State to Seattle. Shortly after arriving, I sold the car I had driven out west in and bought a new one. I transferred the old car's title to the scrap dealer I sold it to, registered the new car with the Washington DMV, cancelled the insurance on the old car, and got a Washington driver's license within the appropriate time frame as set by the State of Washington for transferring a license from a different state. All fine, right? Apparently not, because now the NY DMV is mailing my old address telling me that my NY driver's license (which I don't have, because I'm not a resident of New York) is suspended because of the insurance lapsing on the old car (which I don't own). And I get to wait until Tuesday to do anything about it, because the DMV isn't open on weekends and Monday is a federal holiday. Whoopee.

@GRS Congratulations on completing the Ultimate Challenge! Your submission has been added to the Hall of Fame, and you may claim the badge at your leisure. Overall, I found myself impressed with your submission. Not for doing any one thing exceptionally well, but for overall competence in all aspects of planning, design, and execution. It's not too hard to find people on the forums who are really good at compact lander design, or at mission architecture, or who are really good pilots. The rare thing is to find someone who is all of those things. I do have one question for you, though: What version(s) of KSP did you fly the mission in?

You don't even need distributed launch. Falcon Heavy + Star 48 solid kick stage gets you there with only a single gravity assist, and with much less chance of distributed launch-related failure. Docking in real life is nowhere near as easy as docking in KSP, and distributed launch is complicated from an engineering perspective.

On a different note, I was looking at the remaining steps in the mission, specifically at step 22, and I decided to test the Laythe landing. Mostly because I was worried that VICTOR wouldn't be aerodynamically stable. The good news is that it is stable. The bad news is that Jeb's perch on the ladder isn't. When I was testing, the Kerbal I had along for the ride started sliding up the ladder, and I needed to keep moving them down the ladder to prevent them from flying off. Which meant I didn't have time to control VICTOR at all for the landing. Which means that the Laythe landing is going to have to be conducted using Jeb's EVA chute. This is fine (the chute can be repacked), but we should probably update the mission plan to reflect this. And maybe also flesh out the Kerbin landing a little, since the plan currently stops before re-entry.

One moon down, 4 to go. Album is here: https://imgur.com/a/N0b0kz9 Rendezvousing with Jeb was pretty easy - having the ladder on the end of a long swinging boom arm made it pretty easy to line it up. The landing? Not so much. It took me 4 tries and 1 Jeb-death before I managed to get the lander to the surface in one piece. The ascent went much more smoothly, only taking two tries (I took off in the wrong direction the first time). Jeb has been parked 8.5 meters from BRAVO (which still has the transfer tank docked to it) with a near-zero relative velocity. Having now done the rendezvous, I'm realizing that @Muetdhiver is going to have to do it all over again before taking BRAVO off to Bop and Pol. One thing that might help is having Jeb grab onto BRAVO and then pointing the whole arrangement normal or anti-normal. That should reduce the drift experienced over whole-orbit intervals (i.e. the relative position of Jeb to the lander will be nearly the same one whole orbit after letting go). For the last fraction of an orbit grabbing the ladder and using physics warp shouldn't be too bad.

This isn't really the case. Modern CPUs do a whole lot of complicated stuff under the hood to speed up instruction execution, and the execution time for a given instruction can range anywhere from a fraction of a cycle to dozens of cycles, depending on instruction complexity, instruction operands (independent of complexity), branch predictor accuracy, dependencies, and pipeline contents at time of execution. Some instructions on x86 and x64 will even vary in execution time based on the literal values of the operands at runtime (!). If you want to do some more reading into the nitty-gritty of per-instruction processor performance, I found this pdf, which is fairly comprehensive.

Well, it really depends on why you want to learn to program. If you're just looking to get something done and don't really care about doing it right, Python is the better choice. It was practically designed to make it easy to slap stuff together. However, if you have any intention of actually learning something, don't start with Python. The language is syntactically dissimilar to most others in a way that makes it hard to switch to writing something else, but that's not the problem. The problem is that it's extremely abstracted - the contents of a Python program, as understood by the programmer who wrote it, bear little resemblance to what your computer actually ends up doing when running said program. C++ isn't much better here, unfortunately. The language is less abstracted, but it's also extremely complicated, syntactically and semantically, and if you're not taught it just right you'll come out more confused than you were before you started. If you're looking to really learn something, I would recommend with starting out by learning some C. C is the canonical non-abstracted (or low-level) language, having been described as being a thin veneer over the raw machine instructions it compiles to. Conveniently for us, however, it's human-readable (where machine code is not), and the language spec itself is quite simple. It's got a small standard library and a very small number of language constructs, all of which are easy to describe, and in most cases easy to understand. I don't recommend getting far enough to actually write big programs in C, since it's quite hard to do that and keep your program sane, but it's a good foundation to have for learning C++. But that's the strong opinion of a guy who writes C professionally, so take it with a grain of salt.

If we're talking absolute cheapest route, I had good success with this design a while back when trying to get science back from every biome on the Mun: It doesn't have a crew capsule, but that's because I needed to fit it into the T1 VAB and launchpad (you'll notice it has 30 parts and weighs less than 18 tons). For me at the time, this wasn't a problem since I couldn't do EVAs or take surface samples, but I have no idea how far you've upgraded your space center. If anyone does try and replicate it, note that the design is a bit hard to copy from a screenshot due to high levels of part clipping in the lander.

Thanks! Here's hoping they work just as well for the actual landings.

I think we might have gotten hung up on a nomenclature issue. I didn't mean 8 8-bit ops - I meant a single 8-byte/64-bit integer add (so something like `add rsi, 10`). Oh, and, in gcc, sizeof(float) == 4 and sizeof(double) == 8, regardless of whether or not -m32 is set. It's sizeof(int) that equals sizeof(long) if you're building a 32-bit binary (you need sizeof(long long) for a 64-bit int type). But yes, floating point math's speed advantage comes because of specialized complicated instructions to do aggregate operations, mostly over vector types.

This is technically true in some cases, but highly misleading. Floating-point vector operations are generally faster than the equivalent integer vector operations would be due to the presence of specialized instructions and registers (XMM on x64 and SIMD on ARM64) to handle such operations, and this generally translates to floating point having higher performance than integer math in real world scenarios because most floating point math is vector math that can take advantage of these specialized instructions. However, a plain old double-precision floating-point add is going to be slower than an 8-byte integer add on a modern x64 or ARM64 machine.

I'll volunteer to fly 17 and 18 (the Tylo landing & rendezvous with BRAVO).

Without Principia, that is.

It's not like the capsule size has any effect on how much science you get. Actually, a 2-kerb capsule should work better, since it's lighter.

This alone is a near-insurmountable problem. A 120,000-ton vehicle is technically feasible (there are container ships that are several times as massive), but 12 million tons of deuterium is not happening for any reasonable sum of money. You'd be looking (based on some cursory research) at hundreds of billions to trillions of dollars per flight for fuel costs. If we're talking ways to get something to Proxima B within our lifetime, solar sails are the way to go. That something being a probe, of course. Humans to another star ain't happening with any technology we know how to build. But, as @Spacescifi said, why would you want to make that trip? We've got a perfectly good unsettled, largely unexplored solar system right here.

Have you sent Kerbals to the Mun/Minmus yet?

By having it jettison prematurely at T+45 seconds into flight, destroying the payload, upper stage, and booster from aerodynamic forces.