SkyRender

Beat me to it. Seriously, though, probably the usual way I do for a new install: with KER installed to save me the trouble of hand-calculating dV, but otherwise stock.

That is one bizzarre screenshot. Jebediah is freaking out while Bill is having the time of his life. What alternate reality is that from?

A windfall for the Guide! A new Kerbologist discovered a Kerbal phenomenon and lived to tell the tale. This is his story. Kerbals and Space/Time Warping A rather peculiar Kerbal phenomenon has come to the attention of the Guide recently, due to a Kerbologist actually willingly accompanying a Kerbal on a successful flight into space. The sheer improbability of this event alone is noteworthy, yet it also revealed a facet of the Kerbals' terrifying control over the space/time continuum that was previously unknown: their ability to warp space/time itself to speed up the passage of time. Perhaps the most remarkable thing about this phenomenon is how it is brought about, however. The Kerbal in question, a rather unstable fellow by the name of Bob Kerman, demonstrated the process of time-warping to the Kerbologist by swinging an eeloo around rather violently. After five swings, Bob released his grasp on the ancient time measurement device, and it promptly pinged about the cabin at an impossible speed. The Kerbologist watched in awe as it began to cause spectroscopic distortions before his very eye-stalks, before finally slamming Bob Kerman in the head and knocking him for a loop. Looking out the window of the craft, the Kerbologist was amazed to see that they were suddenly moving 1000 times faster than they had been. Bob Kerman explained, as he re-primed his eeloo, that they were in fact moving exactly as fast as they had been before. This rather unorthodox technique was in fact a means of speeding their perception of time within the confines of whatever cabin it was used in. He then promptly repeated the whole process in reverse, as best our Kerbologist could explain it, and suddenly the craft was nearly on top of the Mun. A quick panicked course readjustment later, the craft was no longer on a collision course. Bob explained that this particular model of eeloo was prone to causing actual distortions in movement through space itself, but that the latest model due out in a few days would fix that problem. After hitching a ride home off the Mun a few days later from the crash site of the rocket, the Kerbologist gave his report and an addenum concerning Kerbal space-time control as well. It turns out that Kerbals can also use their eeloos to speed the passage of time on a smaller scale, but that this was considered taboo due to its tendency to cause the universe around that Kerbal to go pear-shaped. The term "Space Kraken" was apparently brought up during the discussion as well, though derisively. Whatever the case, we now have new reason to recommend that anyone interested in visiting Kerbin reconsider. It turns out that it's a great way to kill a lot of time even on the off chance that you do survive. Possibly quite a lot more time than you intended to, in fact.

I've been with KSP since 2011, I think waiting a bit longer is not really an issue.

Dres, easily. At a glance, it seems like it's just Mun Mk. 2. But when you actually get there and take a good look at it, you realize that it's actually a whole lot more interesting than the Mun.

I'm pretty sure the Mohole exists because rectangular-to-polar conversion causes exaggerated features at the poles, actually...

If my experiences with Kethane and Karbonite are anything to say about it, it's likely that ISRU will be most effective by way of mining the Mun and Minmus. The amount of fuel necessary to capture an asteroid is absurd, and even if you did manage to do it, you'd still have to reach whatever crazy orbit it was in.

Logically 12 across on that list refers to 16 across, as 16 across does not have an entry.

We're hyping together, it's nearly release time. And maybe we'll come back to Kerbin, who can tell? I guess there is no one to blame, We're leaving beta (leaving beta) Will things ever be the same again? It's the Kerbal Countdown! The Kerbal Countdown! We're headed for Eve now, and still we stand tall! 'Cause maybe they've seen us and run from us all! With so many rockets to launch And things to explode (to explode) I'm sure we'll all miss her so! It's the Kerbal Countdown! The Kerbal Countdown! ...What? Someone had to reference Final Countdown.

So glad they fixed the initial contract problem. I recall demonstrating that it was very easy to get contract-locked if you accepted them and failed to achieve the goals behind them. I just hope they do something similar for the planet/moon contracts as well. The way the system currently works, it's entirely possible to get zero credit for reaching Minmus simply because you went there before going to the Mun!

It's a side-effect of the conversion proces of heightmap to sphere. Even the most minute changes in elevation around the poles get exaggerated to the extreme. This is why the poles of practically every body in KSP have almost alien geometries to them.

I'm thinking Kerbal Advanced Ballistic Operations and Observation Machine. Or KABOOM, for short.

The occlusion code is a bit imperfect at the moment, yes. It's very common, for example, for sunlight to reach objects on the surface of Minmus straight through Minmus. It's also true that the eclipse occlusion code is "too good" right now: until you have at least 50% exposure to the sun from an occlusion caused by a planet or moon, you will get zero sunlight.

Not to be pedantic or anything, but it's not that hard to get a chemical rocket in KSP to go much further than out to Jool or Eeloo. Distance traveled scales exponentially with velocity, after all. Launching one's craft out of the sun's sphere of influence is often one of the first things players do, in fact. Coming to a stable orbit that far out would be slightly challenging, of course, but not as much so as you might think thanks to the other half of the Oberth Effect (it's easier to slow down when you're already going slow).

I think it prudent to point out that Devnote Tuesdays usually get posted somewhere between 2 and 7 hours from when this post was made. So definitely don't read too much into it not being up yet.

Having a fun little version name was cool for past releases, but this one doesn't really need one. Not that they can't slip in a stealth one: We have lift-off! Introducing Kerbal Space Program 1.0!

I would honestly be amazed if they released 1.0 before May. This is not exactly your typical release, after all. This is the release that KSP is going to be judged by most harshly. It's only just barely the longest development period the game has seen for a given release so far.

If Karbonite (which the resource system in KSP is being based off of) is any indicator, "instantly refuel" is way too strong a term. There will be some serious logistics involved in planning any sort of refueling system, and it will take quite some time to extract and refine that matter into fuel. Even if they do implement a mining-in-background system (something that basically no ISRU mod does at the moment due to the limitations of KSP), it would still take a long time to get an extraction system going. Also, the mining equipment will assuredly be top-tier on the tech tree. ISRU actually adds a lot to gameplay and does not really make the game "easier" at all; just different in focus once you start using it.

Quite right. Debugging is always an ugly process either way. Especially for bugs that are impossible to consistently reproduce. It's lucky when they're as relatively minor and easily traced as this one is!

Pretty sure this has everything anyone could ever hope to build beat in terms of absurdly huge: Those engines on the bottom are called BFE-5000s. For scale, here's what the BFE-5000 looks like on a normal-sized craft: Apologies for the really old version. Those tanks are 1.25m ones. Yes.

Here's where I have to get slightly pedantic: fixing the thrust issue would in fact fall under medium- to high-priority. Fixing the actual model itself would remain low-priority. In other words, unless fixing the model also fixed the thrust issue (or fixing the thrust issue without fixing the model would be exactly as or more challenging than doing both), the model would likely remain untouched.

I think it might be prudent to mention the various tiers of bugs. From highest to lowest, we have: Showstopper - A bug which absolutely destroys the viability of the product (ie. the program won't even run, or the most fundamental functionality of the program is compromised). These are non-negotiable in terms of being fixed; any product shipping with a showstopper bug still in there will generate massive negative feedback. Generally speaking, these are where you find things like fatal crashes, severely compromised performance, and bugs that prevent further use. KSP Examples: The NaN bug, the Kraken (fixed) Critical - A bug that, while it does not prevent the program from functioning, does cause massive disruption and sometimes even compromise significant subsystems. These bugs stand out, will garner negative press, but don't kill the experience per se. They just make it look very unpolished. KSP Examples: Current rover wheel logic High-Priority - Bugs that stand out and raise eyebrows, but that don't actually compromise much of anything. These sorts of bugs get noticed by users, but don't really kill the experience the way a showstopper does or muss up the experience to the point of disrupting an entire aspect of the program. They are very visible, just the same, and thus do need fixing. KSP Examples: Current auto-staging assembly logic in VAB/SPH Medium-Priority - Bugs that you could probably get away with leaving in there, but are still going to get complaints just the same. Usually bugs like this are easily worked around by the user once they know the quirks of said bug. Many exploits in games are actually medium-priority bugs that didn't get ironed out during the final push. KSP Examples: Current VAB/SPH overlay priorities that cause parts on your rocket to be selected instead of items in the inventory palette if they're below said inventory palette Low-Priority - Now we get into bugs that are purely aesthetic. These are the bugs that you need a fairly keen eye to even spot, and they don't really have much of an impact. These are often referred to as "glitches", though really bugs from any tier get called that from time to time. Overall, harmless issues that rarely get fixed unless there's a lot of free time. KSP Examples: Slightly misaligned part models Invisible - A special category of bug that you don't usually hear about. These are the "under-the-hood" bugs that you don't even know are bugs because the developers never admit that they didn't intend for the program to behave that way in the first place. Some of the most interesting features in video games actually have their origins in programming errors of this sort: the end result was deemed "cool" or "useful" enough that they were actually made into features. KSP Examples: You'd have to ask the developers, and there's no promises they'd admit to any!

If it were merely a visual problem, I would put fixing that particular art asset at the bottom of the list, to be honest. You have to go out of your way to even spot that there is a problem (demonstrated by how long it took for anyone to even find it); most players will never even notice. That said, apparently it does have an effect on gameplay (some are reporting asymmetric thrust as well), so it probably will get a pass sooner than later as a result. Squeaky wheel and all that.

This does seem to fall into the same category as the sorts who complain that the textures between the parts in the 3M fuel tanks aren't perfectly aligned and thus they never use them. Of all the petty things to take issue with, this sort of thing strikes me as the most petty of all.

HarvesteR once commented on it some time ago. I don't remember the specifics, but I believed he said it was a combination of the limitation of the patched conics formula he'd chosen combined with an error or two in his code.