Gaius

It's not a "taking seriously" thing, it's an "RTFM" thing. I too get annoyed when people email me questions that I already clearly answered in the docs/FAQ/whatever prominently. It's like, did you think I was kidding the first time or something? In the case of licensing, if I already gave you explicit, detailed, written permission to do something, it's just utterly bizarre to be writing me asking for permission again. Starwaster sounds like he's actually a lot nicer about it than me. When people write me asking permission to do things I already gave them permission to do, or asking questions I already answered in the FAQ clearly (it's clear they didn't misunderstand or were unclear, rather it's clear they didn't read it to begin with), I just delete the mail without reply. Why waste the time? If they didn't read what I already sent them, why send them even more text? I know, I'm horrible. It's just, if you ever publish anything remotely popular, you'll see just how freaking annoying it can be to have your email/IM/whatever constantly clogged by crap from people who refuse to read. Seriously, don't write asking permission to do something when the author already gave you permission to do that. At a certain point you're just afraid to fire up your email for fear of the mass of crap you're going to have to wade through... I've since learned to use a different email for stuff like that.

Doesn't make a lot of sense that it would use more power. What does make sense is, it should provide absolutely no torque. If you want to use it with kOS, just add to its config: MODULE { name = kOSProcessor } You could even put that in by default. It's harmless and is just ignored if kOS is not installed.

My understanding was that the default value is 20, but I can't find a source for that now, so consider that hear-say...

It works as well as it ever did. If you want to use it in career mode, you'll need to edit the part configs and add a "TechRequired" line, or use ModuleManager to add the appropriate variables to the parts: @PART[ISA_MapSat]:Final { TechRequired = scienceTech } @PART[ISA_GPS]:Final { TechRequired = scienceTech }

Yeah, generating and storing antimatter is the biggest problem... pretty much everything else Krevsin wrote is nonsense. To be fair, Dr. Smith's estimates on the cost of producing that much antimatter are optimistic. But the hurdles here are economic, not technological. The engineering is pretty straightforward... once you can make and store antimatter in sufficient quantities economically.

This post (on page 14 of 15 for me).

Select the MODULE sections in one of the config files, select "cut", open your part's config file, select "paste", edit the parameters to taste. BTW, as far as taste goes, I recommend: baseConeShape=0, 0, 1, 0.5 noseConeShape=0, 0, 1, 0.5 This gives the "pointy on the top, but rounded on the side" look I like best ("raindrop shape", perhaps?). I think that's what the KW fairings were shaped like, but I might be misremembering, it's been so long since I used them...

Or one could simply refrain from overwriting them when it's not needed. When I install a new Unity-based game, I don't have to worry about it breaking another Unity-based game I have installed, as long as both authors follow best-practices in this area and have their own copies of whatever version of Unity they used in their own directories with the game, just like KSP does. This creates none of the nightmare scenarios people seem to be fearing for some reason, nor any upgrade problems when new versions of Unity are released (the kind of problems that would be created if they were trying to use Unity as a shared resource). Each game has its own copies of needed libraries in whatever versions they were designed to use, and problems are avoided, not caused, by the fact that they may be using different versions at the same time. That's actually how you cause problems, rather than avoid them. Avoiding these kinds of version issues is most easily done by isolating each mod so that it can use whichever version works for it, and not be affected by future updates that might change things in ways that were not known at the time the mod was made. As long as you don't have the plugin in one single location, trying to cope with many config files, each potentially written under a different version of the plugin, you greatly simplify the problem and simply avoid the kind of compatibility problems that crop up any time shared resources are used. Resource sharing can be a great boon in many situations, but is ModuleManager such a large and memory-hungry plugin that it really benefits from it? Trying to share it rather than treat it like a local library for each mod that wants to take advantage of it seems like it creates more headaches for no real benefit...

As it should, assuming it's anything like the "surface" of Jupiter, which is really just an arbitrarily defined point in the atmosphere. Only one end of a no longer attached strut is saved with the craft. You can see the other end during the session in which the strut is broken, but upon reloading the craft after a save, all those "feet" are gone.

This is precisely why it'd be nice to have MechJeb compute these things for us, rather having to memorize or have a chart of the minutes/seconds to meters conversion for each sphere in the solar system, plus a calculator to figure out how many deg/min/sec one needs to add to park 20m north of the target. If I wanted to do all that kind of stuff manually, I wouldn't have MechJeb installed!

That shouldn't be necessary, those mods should have their own copies in their folders already, and you shouldn't replace them, since they may be dependent on the particular version they shipped with -- replacing them with a newer version is begging for problems. It's like replacing a library DLL that ships with a program with a newer version of that library -- it might work, but it's generally a very bad idea. If it was designed to run with version X, don't replace it with version Y. Leave well enough alone...

Haha, awesome! Very prescient of you!

Best part of this is that not only is it moar science, but it's real science! (Current, too!)

If they were that common, though, wouldn't there be English names for them? Notice there's a word for "ten", a word for "hundred", a word for "thousand", and a word for "million", but no word for "ten thousand" -- you have to say ten of the smaller quantity, and no word for "hundred thousand", again, have to use two words, a hundred of the smaller word. English-speaking people at least seem to think once you hit a thousand, you should come up with new words for powers of a 1000 from that point, not powers of ten. (The word "myriad" once meant specifically "ten thousand", but that usage is archaic, in modern English it just means "a large number".) As it stands, the SI prefixes exactly correspond to English words in common usage ("deca-" means ten, "hecto-" means hundred, "kilo-" means thousand, "mega-" means million, "giga-" means billion, etc.) -- ten and hundred thousand prefixes would break that symmetry, extending to powers of ten rarely used enough that English-speakers don't even have individual words for them (archaic usage aside) and resort to compound names for the numbers. The SI system simply follows the established convention for what people over the years have determined to be the most comfortable level of cutting up large numbers into words. If you did insert new prefixes in there, you'd end up with odd quantity changes translating back and forth into natural languages, e.g. "23 kilometers" = "23 thousand meters", a natural translation preserving the quantity, but if you had "myriameters", then "24 myriameters" = "240 thousand meters" -- notice here that the quantity has to change when expressing it in natural language. Instead of "X prefixmeters = X word meters", you have "X prefixmeters = (X times ten) word meters". It would be awkward. It's probably not by coincidence that the standard convention for writing these numbers in decimal is to start adding commas (or periods in some countries) between the digits when the numbers hit 10,000 (you can also do it between 1000 and 9999, but it's optional there). That's the point when we start breaking digits into groups of three. And it's precisely at that point that we stop naming the powers of ten that aren't powers of a thousand. The SI prefix standard falls precisely into this same pattern.

Station construction vehicle/tug. When I make them myself, they have nothing but RCS -- the LLL salvage pod actually has a huge delta-V in comparison.

No, it jumps by factors of 1000 from then on. There's no 10,000 or 100,000 prefix, after kilo (1000), the next is mega (1,000,000). http://en.wikipedia.org/wiki/Metric_prefix Coming up with 48 different prefixes to cover the entire range covered would be... a challenge. And counter-productive -- that's far too much for anyone to memorize -- it would be more confusing than helpful. But the original French system did have a 10,000 prefix, "myria-", it was just never adopted into SI.

Awesome! A much more elegant solution than using multiple command pods for their storage...

Also note that the Mun has biomes. Each one should be fully researched, you get just as much science running the same experiment in a new biome as you got the first time you ran it on the Mun.

Right. When you unlocked the node, you hadn't installed this mod yet, so those parts weren't unlocked at that time. Since you've already unlocked the node, you should be able to go back into the tech tree and select those new parts and unlock them as well. When you click on the node, you'll see all the available parts on the right. Select the new parts and unlock them.

No mods needed at all for the tech tree, it's just part of the base game. You do need to be playing in career mode for it, though -- there's no tech tree in sandbox mode.

Thanks for the update! Just one critical observation: putting "cl_small_ionEngine" and "cl_small_xenonTank" under "largeProbes" seems an odd choice. The apparent meaning of "large" in this context is 2.5m (the size of "probeStackLarge", its only stock representative). Note that the 1.25m stock probe core, "probeStackSmall", is under "advUnmanned", and that's the probe core that these parts would go with. (Note the "small" in "probeStackSmall" having the same meaning as the "small" in "cl_small_ionEngine" and "cl_small_xenonTank": 1.25m. CL and Squad both tend to use the terminology "large" = 2.5m, "small" = 1.25m, and "mini" = 0.625m, albeit not entirely consistently.) But even that aside, wouldn't the "ionPropulsion" node make the most sense? It would at least be consistent with placing "cl_large_nuclearEngine" under "nuclearPropulsion", which seems to be the right place for it despite being a different size-class from the stock engine in that same node. If it makes sense for nuclear engines, it would seem to make sense for ion engines too, at least to me. I would also argue that "cl_mini_asas" and "cl_mini_sas" belong under "precisionEngineering", but that's debatable and a rather minor quibble in any case.

The function of the tech tree is to introduce players to gameplay components a bit at a time, rather than overwhelming them. It's an excuse to spoon-feed players parts in small doses, not to simulate realistic technological advancement. It's not anti-realism, it's just that that's not the main concern...

Awesome sauce. By then I might have unlocked enough of my tech tree that I'll need it.

Parts link by the name of the node, not the location, so if you reorder the tree, the parts from mods reorder accordingly. They stay tied to the named node, no matter where it is moved in the tree...

Yay! We are men. We can rationalize anything.