cpast

Er, the phrase "X does not a Y make" is idiomatic English. It's equivalent to "X does not make a Y," but adds a bit of a flourish. It predates George Lucas by at least hundreds of years. You do realize that in general, what makes a game a game is the restrictions, right? It's the fact that you're given some set of things and told to have fun within those rules; if you have lots of self-control, you can self-impose restrictions (e.g. I'm in no danger of launching ridiculous rockets, because I have a rule that my rockets must *look* like rockets), but let's not pretend that "no restrictions" has anything to do with a game.

This is one of the reasons I routinely shut down my engines when not actively thrusting.

I really don't see how any of that is Lego-like. Lego-like, as I understand it, means that components are taken as given. You have no ability to make tweaks to parts; you have what's in the box and that's it. Your task is to use fixed parts in creative ways. You combine parts very simply; you don't have to do anything complicated to attach things, you just stick them together (provided that they're designed to be attached in the manner you're attaching them). The amazing thing is how much can be accomplished without any customization of the blocks in any way; standard 2x4 blocks can produce amazing things, and you don't have to let people design their parts to have them do whatever sorts of stuff they want.

Because Lego is about snapping together multiple fixed-size parts; you have a fixed group of blocks, at fixed dimensions and fixed shapes, and do not get to do things like make a tall 2x4 of just the right height because you don't want to stack short 2x4s. If you consider making custom parts to be legolike, you and I played with very different Lego sets growing up.

You can get fuel information in map view: just click the resource pane button, and click "Stage Only" to just get the fuel in the current stage. The three things you can't do are look at the rocket/terrain (which I find to be nice for basic spatial orientation; it's much harder for me to fly just by navball, and obviously landing by navball without a radar altimeter is a bad idea); easily check altitude (you have to hover over the craft, you don't have the nice display); and actually stage or otherwise activate/deactivate stuff.

Ah. No, you don't show up *unannounced*. For many missions, it still might not be a problem fitting in the fairing (AFAIK, many missions aren't built out to the width of the fairing), but there would be plenty of planning and integration work to do, and any fairing issues would also be addressed at that time. However, there's a big, big difference between KSP and real national programs: In real life, different programs have free reign to do whatever they like. In KSP, we all have parts of the same width. A Russian capsule might be a different width than an American one, but every KSP program has the same stock capsule widths, and mod capsules generally stick to those widths. (as a side note: while looking up real fairing widths, it turns out that real fairings absolutely *aren't* custom-made; they have standard prefab fairings whose specifications are something you design to when building a payload) Edit: To address "player sets the standards:" Not quite. Standard widths are largely a consequence of part size; the player does *not* set how wide their parts are.

Rockets are almost *never* custom-designed for one payload, because designing a rocket is really, really, really expensive and building a one-off rocket is also really, really, really expensive. Rockets are fairly standardized. They have actual catalogs which show you basic launch options and platforms; while there's more to it than just that (e.g. what orbit you want, insurance, if other peoples' stuff is on the same rocket, that sort of thing), you don't custom-design the rocket for the payload. Yes. It happens all the time; NASA has launched *commercial* satellites, let alone other space agencies' stuff. Russia launches other countries' astronauts. NASA has launched ESA stuff, often for payment in kind (i.e. ESA didn't even pay for the launch, they instead did something for NASA in exchange for NASA launching their stuff). That said, while I like the idea of restricted space, I do think people pointing out that we don't have the necessary space-saving parts (e.g. hinges) have a good point. Mushroom fairings definitely shouldn't just be linearly scaled in cost and mass; the wider the fairing, the harder it is to build, so some sort of nonlinear cost/mass scaling with width would make sense. But a proper aero system should make mushroom fairings give limited benefit in terms of reducing drag; they'd keep stuff from falling apart, but it'd be hard to launch them.

KW does it in 18, AFAIK (sizes 1.25, 2.5, 3.75, both wide and normal; can't remember if they have 0.625, but don't think so and it's not needed in stock since you don't really launch 0.625-wide stacks). Note that 6 of these are literally just sectors of a cylinder, and 6 are tops to a cylinder. Those 12 could really be done as 2, just with the part scaled. The remaining 6 have 2 formats (wider than stack and same width as stack), and could probably also be done as 2 with model scaling (just would be a bit iffier, because that has more than zero detail required).

No one holds the rights to the story. It entered the public domain well over a hundred years ago.

The Science and Funds displays are nice and convenient numeric quantities. In contrast, Reputation shows as a bar going from "bad" to "good." This bar has a couple numbers on it; as far as I can tell, the numbers have nothing whatsoever to do with your actual numeric reputation. This is fine if all you care about is if you have a little reputation or a lot of reputation. However, there *is* a number associated with reputation, and this number isn't hidden from the player -- all contracts and the Admin Building talk in terms of that number. This means that if cancelling a contract or adopting a strategy, we pay a reputation cost that is presented to us numerically, with absolutely no idea how much or how little reputation we're spending or how much we have to spend. These are both permanent actions, as far as I know; the only way to see the actual effect on reputation is to quicksave, cancel the contract or adopt the strategy, see the new reputation, and reload from save if we don't like it. This really doesn't make much sense. If you want numeric reputation to be behind the scenes, so players don't have to worry about "is that a lot or a little" and to implement some sort of diminishing returns, then don't treat reputation like a currency when adding or subtracting it -- say how it changes our reputation in a way that makes sense to someone looking at the bar. If you want to treat it like a currency, then either drop the bar, or add a numeric display for the actual value of our rep.

If that's supposed to be the creature, it really doesn't resemble Shelley's description. The creature is *hideous* - it has watery dead-looking eyes, yellowish translucent skin, black lips, a shriveled face - basically, it looks like a reanimated oversized corpse. Unlike Kerbals, it's slightly oversized (it was too hard for Frankenstein to assemble the smaller bits at human scale), though in proportion with a human. Keep in mind that the creature in the novel is quite intelligent; its initial problem when interacting with humans is that its body, particularly the face, is so hideous that people who see it are instantly repulsed (it gets his *creator* to run screaming from the room). Kerbals, on the other hand, are kinda cute.

OK, thanks all!

If I transmit scientific data from a part at less than 100% value, can I later send another mission to do the experiment again, recover that mission, and get the science I missed out on when transmitting the first time? Or do transmission losses permanently reduce the science I can get from a situation?

So you think the game will not be complete until every single request from everybody has been filled? Even the ones which directly contradict each other? You can't please everyone with a game; no matter what you're making, just about everyone will have something they wished was there but isn't (this applies *especially* to the developers, who know what had to be cut because of time and complexity). So do you actually maintain that so long as there are unaddressed suggestions the game can't be considered complete and worthy of 1.0 release? Or is there something more specific than "everything anyone wanted added"?

http://arstechnica.com/gaming/2014/04/steam-gauge-addressing-your-questions-and-concerns/?comments=1&post=26666493 They're not official; only Squad knows the total official sales numbers, but they're a reasonably reputable estimator. KS isn't the only repo, but people a) also redownload mods they already had, the estimates are almost a year old, and c) Steam isn't the only sales channel

Without the sales numbers for KSP, you cannot conclude *anything* from FAR download numbers. Honestly, the number you get from those is all under 100,000 people for each mod. Factor in that there's a *lot* of overlap in those numbers, and you're claiming that there are under 200,000 people or so who have bought KSP. I suspect the actual sales numbers are much, much higher than 200,000. Those mod numbers are small even compared to the number of forumgoers, let alone the number of players. EDIT: Apparently an Ars Technica person in May 2014 who was compiling Steam sales estimates had an estimated 645,000 KSP copies on Steam. That was almost a year ago. So if that's anywhere near the actual numbers, the mod numbers you're quoting really aren't that high.

No, 1.0. The difference between 0.26/0.27 and 0.90 is a marketing thing. But 1.0 vs 0.xxx is an actual distinction - 1.0 is the first full release, at which point it's no longer in initial development and is intended to be suitable for general use. It means it's no longer basically an in-development thing, it's a complete and finished product. One that might see updates, but they're building on a complete product, instead of taking it closer to a complete product. That's not something Squad invented or something marketers invented; it's been around since structured version numbers became a thing (the pre-1.0 releases didn't necessarily go public, so 1.0 was the first public version, but now we do have public development releases).

I'd bet money that the proportion of people who play with mods is *much* smaller than most forum members seem to believe. I often see people talking about forum members as if they're a representative subset of KSP players, and acting like because modding is common among frequent forumites, it's common among players. If KSP is like any other product I've ever seen, they're not and it's not; I'd guess a sizeable majority (really, probably at least 75%) of players play all-stock, cap out at <=20 hours of playtime (that's a perfectly respectable amount for a $60 game, let alone a $30 one), and don't know or care about the forums. Any consideration of the typical player that starts with a frequent forumgoer is likely to be far removed from an actual typical player.

Frankly, and I'm being a bit selfish here, I think what reviewers say about KSP and how it affects Squad's reputation is Squad's problem, not mine. Squad deals with the consequences of a 1.0 release, just like they're currently dealing with the consequences of being in early access. KSP is what pays their rent, what lets them afford food, etc. - I'm sure they've thought about this before deciding to make a 1.0 release. If it's a bad idea, the consequences for that don't fall on me (I bought it at 0.23 based solely on the current state of the game without even considering future development, and have more than gotten my money's worth); they fall on Squad. It's a risk (it always is), but I think they know that, and since it's their livelihoods that are affected, I'm inclined to assume they made what they thought was the best decision they could using all the information at their disposal (which is much more than we have; it includes things such as development plans, financial state of the company, enthusiasm on the development team, the latest build, and a sense of how time-consuming it is to do certain things in the code). As for the PR side: Isn't PR what KSP's executive producers used to do for a living? Since I can't imagine a scenario where they weren't involved with this decision in some form or another, they probably have some idea how the PR will work.

What I did with this was to do some certification flights. I'd name my subassembly with mass to LKO defined as "100km equatorial" (I had 3 subassemblies, for 3 mass ranges), with rated transfer stages from LKO to elsewhere. Basically, it was a fully modular program.

I think that just indicates that they really *aren't* available, because they're on vacation; however, you can call them and order them to get down to KSC because you truly have to launch them (e.g. "Jeb, Bill fell out of his ship and is on a Munar return trajectory. If you don't launch to pick him up, he'll die.") One other thing to think about will be the effect of pulling someone out of vacation on their new vacation. If someone gets back from 10 years away (and so has earned a year off), I shouldn't be able to fly them for a week (with them not doing anything in their massive frustration, just being spam-in-a-can) and end up with them ready 30 days later. So when a Kerbal flies on vacation, whatever the length of their flight, it should add 10%-of-flight-with-30-day-minimum to vacation days left. Here's an idea for a slightly more detailed algorithm: Each Kerbal has four things stored relevant to vacations: FlightTime, VacationRemaining, FixedUnhappiness. There's a global LastVacationTick timestamp. A kerbal with 0 days remaining on vacation is owed no vacation from previous flights; their FixedUnhappiness is set to zero each tick. A kerbal in flight has FlightTime counting how long their flight is; a kerbal not in flight has FlightTime set to zero each tick. The "set to zero each tick" shouldn't be necessary, but with realities of software it will be. Each tick, you compute how long it's been since the last tick. For all kerbals on the ground, say Unhappiness -= (Unhappiness-FixedUnhappiness)*(DeltaT/VacationRemaining); VacationRemaining -= DeltaT; if (VacationRemaining <= 0) then Unhappiness = FixedUnhappiness = VacationRemaining = 0. For Kerbals launching, set FlightTime=0, and for Kerbals in flight set FlightTime+=DeltaT. When a Kerbal lands, check if VacationRemaining is zero. If it is, and if FlightTime is less than a cutoff, then set Unhappiness to zero (no vacation time, and in a short flight they can't get *that* unhappy, so they're fine after getting to go home and see their families and talk to frien. If it's not, or if FlightTime is more than the cutoff, say Unhappiness+=f(FlightTime); FixedUnhappiness += .1*f(FlightTime); VacationRemaining += min(30d, 0.1*FlightTime). f(x) is an increasing function of x. This has a Kerbal lose 90% of their vacation-based unhappiness linearly over the course of their vacation. They lose the remaining 10% at the end of their vacation. Mission unhappiness is lost smoothly over the vacation (as a Kerbal forgets the problems on the mission). When they land, unhappiness increases if their flight was long enough or if they were pulled off vacation, to simulate "no one likes being yanked off vacation". A minimum unhappiness for being yanked off vacation is a side-effect of the minimum vacation length. Emergency flights are penalized by having starting unhappiness, and by adding another fixed unhappiness segment of at least that associated with a 30 day vacation (fixed unhappiness is only lost when they complete a vacation), and by extending the vacation at least 30 days. If a Kerbal is repeatedly sent on emergency flights, fixed unhappiness keeps climbing, even if they're only losing an hour of vacation each time; they also keep having 30 days added, even for a 10-minute flight. From a user perspective, it gets introduced like this: Kerbals don't like being pulled off vacation early. The more time you cut off their vacation or the longer the mission they're relaxing from, the less they like it, but no matter how little time you're cutting their vacation short by they don't like being called back early. They really don't like it if you keep pulling them off vacations; until you let them finish all their vacation time, their annoyance at being pulled back early will just grow. Normally they understand they're not entitled to a vacation after a short mission, but if you pulled them off vacation they'll *demand* more vacation time because you cut them off suddenly last time. Three things after rereading what I wrote: First, that's probably somewhat rambling, so sorry. Second, don't take this as a "here's exactly how it should work;" it's just a suggestion with a bit more detail, and I'm sure whatever you come up with will be great. Third, if you want me to keep to more general suggestions because it's your mod and you'll do the details the way you want to and don't want other people to tell you how it should work, just ask (this is just a suggestion, and if you want more suggestion-like suggestions instead of detailed proposal-like suggestions, that's fine by me).

That's *exactly* how software release is supposed to work. You have an RC phase before releasing, and your last RC should be exactly the same as your final release. Now, this really works much better when testing is internal (saying "Here's 1.0! It's the exact same build as 0.96, because 0.96 had no issues that needed fixing!" sounds stupid in a PR announcement), but that is in fact the proper way to do release management.

There's one situation where this would be fine (annoying, but basically fine): If this is Squad saying that the whole having-more-and-more-intermediate-versions-released-to-the-public is done, and they'll do a full beta/RC cycle with the testing and QA teams (including alpha versions of the new features). Say, if the "prep for intermediate releases" is too time-consuming, and they think they can get it done quicker pushing frequent builds to testers. That'd be very annoying, and break the early access concept, but would work just fine in the end, and is how most games work. Here's what it seems likely happened: Squad has been working for around 4 years on this game. They've gone through, by my count, 21 basic releases (0.07-0.25 counting 0.23.5 as a basic release, plus 0.90). The game is honestly right now in a state where it's a plausible game by itself. It doesn't feel like a beta; sure, it feels empty without mods, but that's because I'm used to mods, and to modding other games (so I looked for mods quickly). Other games I've played feel just as empty without mods in their final release state after I'm used to having lots of mods. KSP vanilla is a plausible complete game. It might not be the best complete game it could possibly be, but it's still pretty darn good. So, you've spent 4 years of your life working on a game. It's in a decent state. You're losing some of the drive that led you to start working on the game; much of the novelty is going away. Testing, bugfixing, and stabilization is boring. You have things you want to do, but doing them will just push the time when you can say "I made a game" back even further. But you have these things you don't want to compromise on; you won't feel like you made your game until they're added. So, you say "I'll add these, and then I'm done! Game is made! There might be some updates, but I've now completed a video game!" I have no idea whether that scenario has anything whatsoever to do with the actual development process, but that's honestly what ran through my head. Since I'd be tempted to do the exact same thing, I find it hard to criticize Squad if that is in fact the reason.

Parachutes shouldn't be considered required equipment, as not all craft need them (spaceplanes, normal planes, powered landers, all possible on Kerbin). Engines aren't needed in orbit (like on a station); neither is fuel. I think having happiness penalties for missing critical equipment isn't so needed, and it's complicated to tell what's critical and what's not.

I'm pretty certain they just play it for fun (I'm betting that they enjoy space stuff in general, which is both why they play KSP and why they work in the fields they work in). They can also do crazy stuff in KSP that has nothing whatsoever to do with the real world and that you could never, under any circumstances, actually even *think* about pulling off (e.g. Whackjob's stuff). For actual rocket *testing*, KSP features almost none of the things that you care about. Real rockets have to worry about what's going on in the interior of the rocket, stresses that the materials are taking and exactly where those stresses occur, what exactly will happen during staging, forces exerted on the payload, weather conditions, etc. KSP features none of that. You also care about exactly how much what you're building will cost (keeping in mind what you'll compromise on to get off-the-shelf stuff and what you'll have custom-made, and what tolerances you need on parts). You need to work with actual aerodynamics (which is difficult to simulate properly). KSP is not designed to even approximate actual rocket design, testing, and flight; it cannot really be made to do so via modding below the level of "call fork() and launch a real simulator".