Dunbaratu

You're forgetting one important thing: You cannot turn off evolution. As long as we're DNA based and still procreate, we will continue to mutate. So no, it will be impossible for humans to last a billion years. What will be possible, on the other hand, is for the *descendants of* humans to be around in a billion years. Whatever they end up being, they won't be humans though. To put that in perspective, the common ancestor of *Lemurs* and Humans is only about 50 million years ago. That's still only 5% as long as the duration you're talking about here. The first mammals of *any* kind, date back to only about 20% to 30% as long as the duration you're talking about.

Only if you assume that multiple solar systems means multiple ones in the SAME campaign. Not if it means being able to restart a new game in a new solar system, which would be nice as it would make each play through a bit different.

Yes. This. We on the kOS dev team *HATED* this change when it first came out. The design of kOS was not to hardcode the value of the throttle to zero when you exit the program, but rather to return you to the state it was in when you first started the program - that way you can turn an autopilot on and off while flying a plane and not have the plane's engines cut out when you kill the autopilot. But this stupid change really broke people's scripts (you have a perfect launching script - get it to a nice circular orbit, and then the script ends and your engines fire up to 50% again and distort your orbit right away because that's the silly default the game chose for them on the launchpad before you ran the auto-loaded booted launch script. We had to give them the ability to query and set the initial throttle, or the "exit" throttle that it will return to when you quit.) And you can't actually change it. If you put a vessel on the launchpad, hit 'x' to kill throttle, then leave the launchpad and come back (or save the game and come back later), the act of coming back to the launchpad again resets the throttle to 50%. The game sets the throttle to 50% every time you enter the "launchpad" scene again, clobbering whatever value it had been saved as before for that vessel. There is no reason at all for defaulting it to 50%. None. I have no idea why Squad did it. Hey Squad, I strongly suspect there are zero, (count them, zero) players who find the the 50% throttle feature superior. Can't you please just fix that? Nobody wanted it. Everyone hates it.

Not at the moment, but you can edit your programs externally to the game, in whatever text editor you like.

(picture not shown in quote) Yes - that's exactly it. And your example shows it mildly. It gets worse the more antennae there are. When I tried launching my first satellite that was meant to be part of a kerbin network - with an omni, two DTS's for talking to the other near-kerbin network satellites just like this one that I planned to launch later, and one dish for far away, the thing had such a blotch of overlapping text there that it actually wasn't readable. It seems that the more antennae there are, the more extra times it prints the text out. And that thing had an FPS of about 3 or 4 ... I gave up on using RT until this is fixed. This breaks RT completely. Same here. I'm a little bit concerned with people claiming it's not a big deal. That makes me fear it's not getting the top priority it deserves. A bug that drops the framerate to 3-4 FPS renders the mod impossible to use. EDIT: I just had a look and it seems the issue got addressed in github a few hours ago so when the release comes it should be there. I'm happy about that.

For me the overlapping text bug isn't minor. It's blocking my progress in my career game because I don't want to do probe work without RT, and whenever this bug manifests, my framerate becomes intolerable - in the single digits.

The above problem is essentially why I gave up on bothering with the RT flight computer. There's just no point in trying to use it to queue up a list of actions to occur at a specified future time because the timer is relative to when you manage to finish typing in the parameters and click the commit button. So the time it took to type the actions in affects when they go off. In order to get two commands to fire back-to-back, you have to put a long delay on the first one, commit it, then get the second one set up, and give it a shorter delay than the first one had. then wait ... wait.... wait.... and hit the button......NOW. That just seems utterly ridiculous when presumably the probe HAS a clock on board and can be told to trigger something based on that clock time. The only limitation should be that the command can't go off any earlier than the time it takes to get the signal to the probe. If you set a fixed time that isn't far enough in the future, then it won't go off when you said, and instead goes off once the signal arrives. This was half of why I gave up on the RT flight computer. The other half was the UI inconistency where SOME fields you MUST press enter after typing for the change to take effect and other fields you must NOT press enter because enter commits the command rather than just the one field you're on. That was such a pain. I have no idea if that's been fixed - this was quite some time ago and I just haven't bothered using it since. kOS is just easier. - - - Updated - - - For me it is, not because of the text, but because the text bug is accompanied by a massive drop in framerate, down to less than 10 FPS. And the boldface text isn't *really* bold, but rather it's the same text being printed again and again on top of itself, which in some cases has made it an unreadable blotch. That probably accounts for the poor FPS - something is printing that text again and again waaaay too many times per update.

My complaint is over this here: Drawing this analogy is a bit insulting to NASA, because, well, let me give two sentences: (1) "This is my autopilot, I get the credit and the blame for how it behaves." (2) "This is someone else's autopilot. *They* get the credit and the blame for how it behaves". Most of the time that "cheating" feeling that makes the people who don't want to use Mechjeb choose not to use it is (2) above, but the position NASA is in is much closer to (1). When you say that people's use of the word "cheating" is identical to claiming NASA has been cheating, you're downplaying the fact that NASA is much closer to (1) than (2). The AGC was a joint effort between NASA and MIT. If it didn't work, the blame would have been very much on NASA's head, because even though MIT did the all the underlying low level work, they did so to NASA's specs for what they wanted it to do, what math formulas it had to use, and so on. NASA's position these last 40 years is much closer to being a member of the mechjeb dev team, than being a player downloading the ZIP and installing it without ever looking at the C# code.

Sigh, not this *again*. Another biased wording on another one of these polls. Most people who don't like to use MechJeb aren't doing so out of ignorance of the fact that real space programs use autopilots. It's out of the knowledge that software isn't sentient. It's a proxy for the thinking of the programmer who wrote it. If that human flies your ship well by the proxy of the program they wrote, that's *their* bragging rights, not yours. If that human flies the ship badly and crashes it by the proxy of the program they wrote, that's *their* blame, not yours. That's the feeling that makes some people not want to use MechJeb, not an ignorance of the existence of autopilots, but rather the feeling that in this case the fully working autopilot is somebody else's accomplishment, not their own. I really don't care one way or another if you use MechJeb. There's no such thing as "cheating" in a single-player game. But stop belittling people who don't, under the false implication that they're just ignorant of real life autopilots. For a lot of people the thing the Mechjeb authors are doing for them via the autopilot, is the very thing they want their own player agency over.

I can't figure out why I get this error with version 1.7.4 of KSPAPIextensions installed. I didn't get it with 1.7.3: It causes the main KSP game to fail to load ANY part data on startup, and therefore it deleted all my vessels in the saved game (all of them had "invalid parts" since none of the parts in the game "exist"). The VAB tabs show no parts at all. This all happened after I installed KSPAPIExtensions.dll version 1.7.4 and clobbered KSPAPIExtensions.dll 1.7.3. with it. FileNotFoundException: Could not load file or assembly 'KSPAPIExtensions, Version=1.7.3.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. at (wrapper managed-to-native) System.MonoCustomAttrs:GetCustomAttributesInternal (System.Reflection.ICustomAttributeProvider,System.Type,bool) at System.MonoCustomAttrs.GetCustomAttributesBase (ICustomAttributeProvider obj, System.Type attributeType) [0x00000] in <filename unknown>:0 at System.MonoCustomAttrs.GetCustomAttributes (ICustomAttributeProvider obj, System.Type attributeType, Boolean inherit) [0x00000] in <filename unknown>:0 at System.Reflection.MonoField.GetCustomAttributes (System.Type attributeType, Boolean inherit) [0x00000] in <filename unknown>:0 at BaseFieldList.CreateList (System.Type type, System.Object instance) [0x00000] in <filename unknown>:0 at BaseFieldList..ctor (UnityEngine.Component host) [0x00000] in <filename unknown>:0 at PartModule.ModularSetup () [0x00000] in <filename unknown>:0 at PartModule.Awake () [0x00000] in <filename unknown>:0 UnityEngine.GameObject:Internal_AddComponentWithType(Type) UnityEngine.GameObject:AddComponent(Type) Part:AddModule(String) Part:AddModule(ConfigNode) PartLoader:ParsePart(UrlConfig, ConfigNode) :MoveNext() UnityEngine.MonoBehaviour:StartCoroutine_Auto(IEnumerator) UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator) :MoveNext() UnityEngine.MonoBehaviour:StartCoroutine_Auto(IEnumerator) UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator) PartLoader:StartLoad() :MoveNext() (Filename: Line: -1) NullReferenceException: Object reference not set to an instance of an object at PartModule.Load (.ConfigNode node) [0x00000] in <filename unknown>:0 at Part.AddModule (.ConfigNode node) [0x00000] in <filename unknown>:0 at PartLoader.ParsePart (.UrlConfig urlConfig, .ConfigNode node) [0x00000] in <filename unknown>:0 at PartLoader+.MoveNext () [0x00000] in <filename unknown>:0 UnityEngine.MonoBehaviour:StartCoroutine_Auto(IEnumerator) UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator) :MoveNext() UnityEngine.MonoBehaviour:StartCoroutine_Auto(IEnumerator) UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator) PartLoader:StartLoad() :MoveNext() (Filename: Line: -1) NullReferenceException: Object reference not set to an instance of an object at PartLoader.GetDatabaseConfig (.Part p) [0x00000] in <filename unknown>:0 at PartLoader.GetDatabaseConfig (.Part p, System.String nodeName) [0x00000] in <filename unknown>:0 at DragCubeSystem.LoadDragCubes (.Part p) [0x00000] in <filename unknown>:0 at Part+.MoveNext () [0x00000] in <filename unknown>:0 (Filename: Line: -1) It appears to be looking for a version 1.7.3 of KSPAPIExtensions, and barfing when it can't find one (because it's now 1.7.4?). Here is the list of things I've already spent time trying: - Remove all redundant copies of KSPAPIExtensions.dll that other mods may have installed. Leave just the one in the main GameData folder only. - Check any ModuleManager configs to see if they explicitly tried to add version 1.7.3 to anything. - Check my persistent.sfs for the saved game to see if it explicitly mentions 1.7.3 anywhere (it doesn't). I can't tell why it demands only 1.7.3 and barfs when it's more recent than that. Mods installed are: kOS 1.7.2 Infernal Robotics 0.12.RC1 RemoteTech 1.6.3 - - - Updated - - - Okay I just removed all those mods and re-installed them from scratch and the parts are back, but that saved game now thinks I haven't bought any of them and they're all marked as "experimental" and i have to re-purchase the R&D for the part. No way I'm doing that, the loss of my vessels already borked my bank account in the career - just killing the saved game and starting a new career over. I think the problem was this: - Remove all redundant copies of KSPAPIExtensions.dll that other mods may have installed. Leave just the one in the main GameData folder only. I don't think I should have done that. but part of the reason I did was that I was getting multiple "not compatible with 1.0.2" warnings popping up for the extra copies of them that were compiled for 1.0, and another part of the reason was that leaving the multiple copies in place was causing doubling and tripling of the rightclick menu items- making them look sort of "bold face" as it re-drew them several times on top of each other. That was also tanking the FPS of the game somehow, knocking it down ot about 3 or 4 FPS, even though there were no exceptions in the log. (So that's why I deleted the extra copies of the dll in the first place, but that seems to have brought on bigger problems.)

People keep messing this up. I feel like we need to make the following line in the documentation page stand out better: When the program ends, these automatically unlock as well, which means that to control a craft you must make sure the program doesn’t end. The moment it ends it lets go of the controls.

Then why did I see mods offered marked for 0.9 when I'm on KSP 1.0 ? - - - Updated - - - What does that do with mods that save settings in a config.xml? Does it blow away the settings?

I wish there was a way to have a column for which KSP version it's made for, in the main list. Then when browsing for mods I could sort the list by "KSP version" to see what is and is not updated to KSP 1.0. It's very slow going having to click on each mod one at a time to bring up that field to look.

For all the people trying to measure how long a burn in vacuum should take (for example to decide how soon to start the burn for a maneuver node), this is of interest: https://github.com/KSP-KOS/KOS/issues/940 We'll work on a fix for the next patch release. The API changed in 1.0 because the modelling of engines is now different. They no longer have a single max thrust value - it depends on air present.

The tutorial is pretty old. I'll have to give it another go tomorrow and see how it behaves under 1.0.

Fixing one bug by exploiting another doesn't appeal to me. And yes, he fact that parachutes live through heat just fine that tends to explode the main craft is certainly buggy. And if that's the way they wanted it then it's buggy by design rather than buggy by code, but still buggy. Broken as intended. - - - Updated - - - The science jr doesn't have the bug. It's mass is being added properly and moving the CoM properly. For it, it's actually *correct* that it tends to throw off the balance by being a less dense part on the bottom. What's incorrect is how the heat shield does so even MORE than the science Jr does, because it's even less dense, with its mass of zero, and is thus acting more like an airbrake or a sail.

Yes I thought of that fix, but I'm playing career mode. You get access to the (broken) heat shielding way before you get airbrakes. It's unreasonable to expect that a user would think that heatshields are unusable when first unlocked because you need to wait until you unlock airbrakes first. - - - Updated - - - Incorrect. What you did was claim the correct response was to consider the behavior correct and learn to play the game that way. You are now pretending that that means the same thing as calmly waiting a bit to expect a fix later, which it emphatically does not. One of the reasons for the complaining was precisely BECAUSE the issue was getting marked as "not a bug" on the forum, which doesn't sound like anyone should expect it to get fixed any time soon. Thankfully saner heads prevailed, and that fact that it is a bug and not proper behavior is accepted by squad. THAT means it's okay to chill and wait a bit. Prior to that, it was not. I don't mind if the bug takes a while to get fixed, as long as it is *recognized* as a bug to be fixed, as now finally seems to be the case (precisely because users pointed out to squad what the problem was - in other words, they complained) When there's not even any plans to fix it ever, because the buggy behavior is being redefined as "correct", then that's a problem, and its exactly the reason the complaints were being raised here.

Now that the official word is that Squad has accepted that it is in fact wrong and a bug that massless heat shields act like "wind anchors" and try to rotate you around nose first, and that they plan to make heat shields actually have proper mass, I feel better about applying the modulemanager fix for now.

Which is completely unfair, and buggy. A part should be set up so that it either DOES, or DOES NOT get used in physics calculations. To have it get used in half of them but not others, especially in cases where there is a delicate balance between those calculations, is precisely what is causing the problem here. To make the heatshield so it DOES drag but does NOT move the center of mass, is exactly what is causing the flipover. When an object has one section that is dense and another that is very sparse, but both have equal drag, then when under a wind it will flip so the dense part faces into the wind and the sparse mass part flips to the lee side. You can't get much more sparse in mass than having zero mass but still having drag. That makes it behave like a sail, or a parachute, or like paper - high drag with low mass has a very profound effect - it behaves like an aerodynamics anchor.

Please change the label. "Adding a heat shield causes the capsule to flip point first and burn, thus doing the exact opposite of its intent of helping you survive re-entry" is emphatically a bug. And that's exactly what this misconfiguration causes. Incedentally, turning physics on for the heat shield, via Part.cfg, fixes the bug entirely, so it shouild probably be made that way in the default install.

Also, if the VAB says your vessel has mass 30.1, it won't let you launch to the tier 1 launchpad. So it's still counting that mass against you for that rule too. Is this getting reported as a bug in squad's tracker? Because I think the case "add 1 heat shield and nothing else to a mk1 capsule and it cannot safely re-enter" is pretty clearly wrong, and defeats the point of the heat shield.

The problem isn't heat being broken, it's that the orientation of the vessel flips. The heatshield alters the balance of mass to volume, so the capsule won't go butt-first anymore.

The part is emphatically NOT weightless. Read the engineer panel in my third screenshot. If the 80 shields had no mass, the readout would say the vessel weighs just 0.84 - for the mk1 capsule. It's more than 20. It IS adding the mass to the vessel as a whole, but then not letting that mass affect the center of mass balance, which we think is causing the weird behavior. The part still has mass at least for the calculation of total mass of the vessel. When you extend the length of the capsule without properly calculating in how that moves the center of mass, it causes the center of mass to no longer be below the center of drag, which is the effect that normally makes the capsule go rear-first.

I only did it to prove the bug, as one shield wouldn't move the center of mass very far, but 80 would make it visually obvious whether it was working or not.

I'm about to head out for the evening, but here's some pictorial proof of what's screwed up: Here's a Mk1 command module in the VAB. Notice it has a mass of 0.84 and notice I have the center of mass yellow ball turned on. Now, here's a stack of 80 heat shields attached just under it. Each heat shield allegedly is supposed to have 0.3 mass according to the info panel in the VAB: So why hasn't the center of mass indicator moved at all? The combined mass of 80 of those heat sheilds should be waaay more than the capsule. And yet the yellow ball hasn't budged. But the engineer readout IS aware that they did add to the total mass of the vessel, which is now much more than the mass of one mk1 capsule: So, adding a heat shield DOES add to total mass of the craft, but without moving the center of mass indicator at all. That can't be right.