Jovus

New thread titles for February: Are wings cheating? Are probe cores cheating? Are SRBs cheating? Are rocket engines cheating?

You mean without actually running out? I finished a Minimus return (putting my craft for capture reentry at Kerbin) with exactly 0.5 m/s left in the tank.

I'm confused. In my install, the 48-7S has a lower vacuum ISP than the LV-909. Is this a change in 0.90 that others haven't noticed, or is one of my mods messing with my engines? (I don't have any that should be.)

When all the requirements are ripe for testing, they'll get the green checkmarks next to them. When you've actually completed the mission, the whole mission text goes green, and you'll get a new notification in your notification thingummy (The button in the app bar that has a number with parentheses around it.)

Wanderfound, I just wanted to say thanks. Because of all your enthusiasm, you got me interested not only in spaceplanes but also planes. And you helped make it make sense. As proof, here's a spaceplane I put together (just unlocked the turbojet, which is my highest unlock in this save). It's remarkably stable across the entire reasonable envelope all the way up to 30km. And like I said, first try. (There was some fiddling with landing gear, but none with the wings.) A bit of a pig when it's full of cargo, but that's because I don't have the tech to make a truly powerful beast. And there's enough delta-V in the tank to do a Munar flyby. And all that's basically exclusively inspired by what you've done here. So thanks.

Because there was a booster on the other side.

Easiest solution for next time: build your probe before putting it into the cargo bay, then save it as a subassembly. If you're not sure it'll fit, just put a cargo bay around it in the planning stage.

So what's the purpose to putting canaards at -100 AoA like you do? Does it improve stability? How does it change your lift characteristics? Why do you do it, and in what cases should I?

Regarding the parachute warning, I had a thought while I was playing today. (I'm still using the older version rather than the beta.) Rather than (or maybe as well as) a toggle to simply turn it on and off, maybe it could by not show if the only parachutes on the craft are in the abort group, but otherwise show? My thinking goes like this: my big problem with the parachute warning is when flying spaceplanes. When I'm flying a spaceplane, I don't give a flip that parachute deployment is unsafe - I'm not going to deploy parachutes unless something goes horribly wrong. (Probably not even then.) In this case, the warning is just getting in the way and messing up visuals. However, when I actually do plan to use parachutes, it can be useful. Sure, on Kerbin where I have lots of practice, I don't need it, but I haven't ever tried a parachute anywhere else, and I could definitely see the attraction in having a handy dandy warning to tell me when it's safe to open my chutes on e.g. Duna (whose atmospheric composition is quite different), since I have no real idea based on my Kerbin experiences.

Not quite, but close. But anyhow, this is still a cool picture of it, and one that's hard to get - it's in the daytime, planetside, rather than just in orbit.

Jebediah body pillows. Don't judge me!

I'm going to introduce my son to KSP when he's old enough. I think that should be around 7. Hopefully it'll be multiplayer, so I can play with him. (Addendum for clarity: why are we worried about whether or not it's a children's game? Would you be ashamed to play it if it were?)

A small disagreement here, which I bring forward because this was put forward to be a discussion. But first, let's clear the air and lay down the ground rules of where I'm standing. You should know that I joined this lovely community and got this awesome game shortly after the release of 0.23.5, so I'm relatively new around here. If that makes me less authoritative, well, I'm at a disadvantage. I also largely agree with the broad sentiment of the first post, which I take to be (so you can see what I'm agreeing with), "Squad has created a masterpiece of a game that has oodles more content than we have any real reason to expect, especially when compared to other games. The game as it is right now, along with the promises made for the 1.0 release, will be a fully featured game when it's released." I freely recognize (and applaud) that Squad has gone above and beyond in making KSP one of the best games there is and single-handedly setting the bar for the genre. (Possibly even creating the genre.) My concern over the 1.0 release has very little to do with wanting more features. Oh, sure, I'd love a few more things - like reentry heat, life support, an extra planet, etc. - but I recognize that, as it is now, I have no real right to expect those things, and a company must necessarily cut a product at some point. They have to say, "All right, this is it - from here on out all new releases are for support; this is the 'final' product," or they'll never get it out the door. That's one of two ways for software to die. My concern is over the other way for software to die: being released to a bad reception. I want to hold the 1.0 release off just a wee bit longer - not to shoehorn in more content, but precisely because they are going to shoehorn in more content. 1.0 is a monster of a release. It's going to have a lot of bugs, and there's no telling how many bugs there will be without fairly extensive testing; testing that, I can tell you as a former QAer for medical software, just plain won't be extensive enough due to the nature of the development cycle. (Not Squad's development cycle, which I know nothing specific about. But truly new features like this - especially this large - do best if they get a round or two of 'beta testing' - that is, give the software to real users and ask them for detailed and specific feedback. And Squad has a whole community here, many of whom I'm sure would be willing to give that feedback.) If Squad releases a game that has enough of any: bugs, strange workflows, poorly written tutorials, features that feel 'incomplete' especially to the uninitiated, arcane or difficult controls, poorly explained controls, glitches, visual 'holes' (like missing IVAs), poor user feedback, lack of user feedback, misleading user feedback, or gross instability (whether ultimately their fault or not), then chances are good the game will get a bad reception. This is difficult to evaluate by current reviews, for two reasons: one, because reviewers are probably more favorable to KSP while it's in early access due to the understanding that it's not complete, and two, because reviewers aren't KSP's target audience. They're a lossy metric. And if KSP pans, Squad quite likely will drop the project. (They are, after all, in this to make money. I couldn't blame them in the least for this reaction.) And I love KSP. Furthermore, I want other people, who aren't yet in this community, to love KSP, rather than be turned off by any of the problems I mentioned above. Sure, if Squad fumbles and drops KSP, it's no skin off my nose personally - I'll still have the final release version of their software, and whatever mods I need to make it what I want it to be. But I want Squad to succeed, because I want them to be rewarded for this awesome thing they have done.

If you know what you're posting is going to cause a lock, don't post it. I'm not saying you can't think what you think, or express what you think, but doing it like this is just bad form.

My worry isn't that the new features won't be publicly tested. Indeed, you are correct to point out that most software isn't publicly tested until the release, and that model works just fine. (Though, since Squad does have a willing stable of beta testers - which is what we are, regardless of the version-grouping scheme - they should use them.) My worry, as a former QAer for a software company, is that these new features won't be adequately tested. That simply cannot be done in a release concurrent with the features themselves. The very nature of the beast is to limit QA time, and limited QA time will focus on questions like "Does it do what it says on the tin?" and "Does the feature actually fully exist and make sense, or not?" Those are very good questions for QA to ask, but there's another that won't be, and it's the one that finds you the bugs your public will unwittingly stumble over in their everyday experiences (both because there are a lot more of them than you, and because customers do weird things): "How can I break it?" Squad needs a "How can I break it?" release before they shove my favorite baby into the cold, hard world to fight off the wolves all by itself. And it doesn't matter if they say, "Yeah, we'll do that after 1.0," because, even if they keep their promise, the wolves will have already picked it apart (going, as usual, straight for the wallet).

Additionally, I worry that, even if they get everything right in this next release and don't release more bugs (hah, right), they've already done a bit of screwing the pooch by making this announcement. They've gotten a fair bit of favorable publicity so far, but it's all been in the vein of "Here's this really cool indie game that's still in early access that is really good for early access! (But don't forget, it's early access, not complete.)" Effectively what they're doing by moving from 'first beta' to 'version complete' is sending a really big signal to the gaming community that KSP is even if that's not true. (Which, if we're honest, we don't have any real indication of, other than Squad's promise to do more development after 1.0)And that could come back and bite them in the wallet really hard.

The flip answer here is that DeBroglie pilot waves are weird. The less flip answer is that this is just experimentally confirming theory that we've known for a long time.

Basically the only way that radioactive dating on geological timescales could be off is if we're incorrect in our baseline assumptions of how much of particular isotopes of uranium we started with. I can't speak as to what goes into the assumptions of those starting conditions, but I'm willing to be they're fairly plausibly argued in the literature.

This move is redolent of the marketing side (i.e., the native 'this-is-what-the-company-actually-does' side) pushing the game development side to wrap things up quickly because they don't feel they'll get their money's worth if they have to pay for too much more development. I hope I'm wrong, but nobody anywhere ever releases anything other than maybe a couple of bugfixes after 1.0, unless they're using a service model rather than a product model. I don't expect Squad will be any different. I suppose this is goodbye to outer planets and reentry heating. Alas.

Actually, there are seventeen and a half. Kerbal sexuality is confusing, which is why there are so many volunteers to be launched on really long, lonely voyages to completely desolate places where you might not ever come back. 'cause it's better than family reunions.

I'm confused. If you already have a large supply of drinking water, why not just electrolyze it before ingestion?

Why do you want your parachutes to deploy sooner? It just means more waiting. 5km is still really high up.

At around 6 arcseconds, I wouldn't really trust WISE to notice individual planets at 1000 AU. Not that it can't, but that nondetection isn't definitive, I wouldn't think.

Or instead of monoprop engines, sepratrons. Because who doesn't love RATOL?

You assume their goal was to save money while finishing the project in an expedient fashion. No. Their goal was to save their own necks by kissing ass, looking politically favorable, shifting the blame elsewhere, and hoping the Man with the Moustache didn't notice.