cpast

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".

I have a Thinkpad T430, which works just fine for KSP.

For vacation time: How about if deploying a crewmember before their R&R is done affects unhappiness? Say, make it so that unhappiness doesn't immediately go to zero when they return, but rather decreases over their vacation? You could also add some unhappiness when they return based on how long their vacation will be (because no one likes being pulled back to work early), and not take it smoothly to zero (have a jump between "day before vacation ends" and "day after vacation ends" to encourage actually waiting for the vacation to end). I'd sort of like it if missions under 1 hour long (or some other short time) didn't count as requiring vacation. And for unhappiness, a quick Mun or Minmus mission with one Kerbal in a Mk 1 would be nice if it didn't make me need to worry about happiness; those missions often appear in early game, and that's also the time larger crews are hardest. Lastly: maybe difficulty could also affect the offsets? So on lower difficulty, I could make it so that five Kerbals with enough facilities could be sustained indefinitely, while at higher difficulty I'd need both facilities and a bunch of Kerbals to socialize with.

Procedural parts lend themselves to designing by the numbers. Many people have lots of fun designing by the numbers; even though I don't use procedural parts, I'm generally one of them. But procedural parts confront someone with *mandatory* dealing with numbers, whereas fixed-size parts encourage playing around in a Lego-like manner. It's relatively simple to grasp tossing on another fuel tank, while procedural parts instead much more strongly encourage calculating the right value; it seems like Squad prefers having people snap together parts instead of having them calculate the correct value. Squad *normally* seems to prefer Lego-style; tweakables are numeric and would get you to modify an existing part instead of swapping it out or adding a new part, but other than that they seem to prefer swapping what parts you use over changing properties of the part. What would be nice from a strictly memory usage point of view would be to reuse textures more, or even implement parts as procedural under the hood while having fixed sizes that snap together. For instance, it'd be neat to have normally fixed fuel tank sizes, which all reference the procedural tank but have fixed size. That way, they'd only have the one model and texture, but would still have the Lego effect. They could also then put a modifiable procedural tank at the very end of the tech tree; that way, they'd have the Lego style they seem to like, while not needing a ton of different parts.

I wouldn't describe the old look as "easy on the eyes" or "clean looking". I would describe the new design as both those things.

Incidentally, it was intended for teens because the adult pilots were dead; it was not actually designed in a way that teens could use it properly, and really required an experienced pilot -- its just that the experienced pilots had been killed or captured, so the Nazis threw children at the war (although it doesn't look like the Hitler Youth actually ended up flying it -- the only operational unit was a preexisting Luftwaffe fighter squadron). From what I can tell, the He 162 actually was fairly well-designed; it was just late in the war, so production was rushed and they still couldn't get many out, and the experienced pilots who should have flown it were dead.

No, really, just no. Scientists don't understand Latin; they understand specific terms, but there's nothing about "vibrassa" making it any easier to understand than "whisker". When you consider that virtually all science nowadays is conducted in English, scientists understand English anyways. Latin isn't culturally neutral (since it originates from western Europe), it isn't used outside of specific terms, and there's nothing that makes assorted Latin terms easier to learn than assorted English terms (for people who aren't reading your paper, since if someone is trying to read a paper and doesn't understand the language the paper is written in, they won't be able to understand it regardless). Latin used to be the language of science. It no longer is, and further uses of Latin are more tradition and consistency (e.g. biological nomenclature in real or dog Latin fits in with preexisting nomenclature, English nomenclature would not) than anything else. Incidentally, in Zambia any doctor should know what "whisker" means, because schools there are taught in English, not a different language. Doctoral programs are normally designed such that anyone taking them has to learn English to complete them, precisely because it's nigh-impossible to do science nowadays without a working knowledge of English. Some science disciplines do use Latin terms, but it's a historical thing, not because Latin is an inherently better language (doctors have a bit of an exception, because Latin lets them refer to things without the patient knowing and panicking).

Is that in discussions, or in papers? I ran a search in abstracts for Astronomy and Astrophysics, and "Sol" came up with just "author has Sol in their name" and "abstract cites a journal whose name includes the word Solar, abbreviated as Sol.", while "Sun" came up with a lot of results. But that search may be highly unrepresentative, for all I know.

But...why? That's no more objective than "Earth", and is less useful for just about every scientific purpose -- I cannot think of a single case where you'd want arbitrary bits of information crammed into a designation. There are conventions for nomenclature of exoplanets, which if extended to the Earth would give either "Sun b" or "Sun d" (the former if you consider Earth to be the first planet discovered, the latter if you consider the first 6 planets to have been discovered simultaneously, as they've been known since antiquity). Note that the scientific designation for the Sun is just "the Sun"; scientists don't seem to have an issue singling it out as not needing to be referenced via catalog number.

Stickied in this subforum: http://forum.kerbalspaceprogram.com/threads/25176-Need-a-Thread-Moving-Removing-Closing-or-Post-Deleted

Right, but I don't see why having them activated via action group when the vessel loads is any better than having them set that way in the first place (unless I'm misunderstanding you?)