Claw

Someone else posted a similar finding (with materials and goo at the north pole). I can't recall if it was confirmed then and haven't yet checked it out myself, but certainly sounds like something is going on. Cheers, -Claw

To make a backup, press F5 (or ALT+F5 if you want to name it) to quicksave. ALT+F9 will allow you to restore that point later, or quickload. If you really want to be paranoid about it, you can copy the save files out into another directory. Saves are located in KSP/saves/save name/ directory and are labeled with a .sfs extension. The game that is loaded when you resume yor save is called persistence.sfs. You can copy, paste, rename this out if you want, but I find it easier to use the quicksave method. Cheers, -Claw

With that, perhaps also post that log you said you have. That may also help in figuring out where the game broke the save file when it crashed. Cheers, -Claw

Dude, that's a great job! I also figured this was probably the only real economical way to do Eve. Nice work. Also an awesome entry. Nicely done and pretty cheap! I found your LKO orbital technique very interesting. Not the "most optimal" ascent, but seems very economical. And nice recovery after the first landing. Cheers, ~Claw

Well, this is the same bug. I've actually explained it in my post above, but I didn't explicitly state it. The reason why Chuck is a stalker, is because of the timer (ToS) that is attached to each kerbal. Any kerbal that is in the Applicant pool has a ToS in the future. That ToS in the future is what defines when that kerbal falls off the Applicant roster. If you hire one of these guys, then fire them, the ToS timer remains unchanged. If you've managed to fire them before the ToS timer is expired, then they will happily hang out as an Applicant until that timer expires. Jeb, Bill, and Bob start out with a ToS of 0 (zero). So when you fire them, they go into the applicant pool. When you exit the Astronaut Complex, the roster is scrubbed for Applicants with expired ToS timers, at which time they are deleted. So if your newly fired kerbal has a ToS in the future, he won't be deleted and will still haunt the applicant list. Now, how does that come back to crash your game later?? Well, lets say you hire a kerbal and put them on a couple flights. You later decide you don't want that kerbal and get rid of him. He logged an achievement and you fired him, but the game hasn't crashed even though the "Bug support sticky says firing a kerbal with achievements results in the game locking up." That's because his ToS hasn't expired yet, so he's not actually deleted from the roster (because he's still listed as an applicant). After enough time passes by, his ToS expires. At some point, the game will scrub the roster and delete all the applicants with expired ToS timers. BOOM, save game goes corrupt, well after the fact. You are correct, there is a lot behind this bug. I can go on and on about the permutations, but most people on the forums don't care for pages and pages of why this thing is broken. The bottom line is that fired kerbals eventually fall off the roster, and that causes the game to lock up. There's a separate bug where the ToS timers aren't being reset when you hire a kerbal, and this is causing a delayed response from this bug (a timebomb if you will). This is probably why you can't get the game to reliably crash with the circumstances you are trying to replicate. It also sounds like there is a separate bug where fired kerbals are showing up as assignable crew members with the new crew management interface. I will try to explore that to confirm. Now, if you're talking about my kerbal roster fix, I've taken care of (hopefully) all of these firing permutations. If you hire a kerbal, change your mind, and fire him before you leave the astronat complex, he stays listed as an applicant. However, if you hire a new kerbal and exit the astronaut complex, he's officially on your books. If you go back and fire him, he happily moves over to the applicant list in case you made a mistake and really meant to keep him. But once you leave the astronaut complex after firing him, he's completely dismissed and won't return. That's also true for the original three. They move to the applicant list so you can change your mind, but once you exit the complex they are completely dismissed. I "think" this is what you're looking for...? Cheers, ~Claw By the way, I should add that the bug that causes the lockup actually isn't in the roster itself. The problem is with saving the game. When saving a game, KSP runs through the achievements and contracts and tries to reference kerbals by name. Unfortunately, there isn't any error checking to handle a case where the kerbal no longer appears in the roster. Part of what you are witnessing is that the only way to keep the save bug from happening is by repairing the crew roster so that in the process of saving, KSP has something to reference. That's the piece of the game that we (as users) have access too. Sometimes we have to be creative when fixing a problem when we can't get at it directly. In essence, the lockup bug is being bypassed.

You are very welcome. And that's my goal, to make these mods as non-intrusive as possible and get rid of some of the needless stress. Thanks! I hope you find the fixes useful! Haha, matchbox car! I don't know if I can do anything to solve that or not. Trapping memory requests might be a bit beyond the ability of a KSP addon. Also, memory freezes and lockups may occur for many reasons. So it's hard to start working on any bug in particular without specific places to look and ways to trigger it. I will keep this in the back of my mind. I've always wanted to try some way to reduce the run-time memory footprint of KSP, but that might also be a bit beyond the scope of my add-ons. That's very strange. The only thing I can think of is if you copied the zip file itself over and didn't uncompress the .dll files. Thanks everyone! Cheers, ~Claw

Yes, actually. You told it to decouple there, which I'm sure wasn't your intent. The problem is actually further down in your picture. You put the wrong part ID in the attN line. From your pictures, I can't tell you what that number needs to be, but it definitely isn't "1". Part 1 (the SAS part) is already attached to the bottom node. Do search for the dockUId that you have highlighted and you should find the other docking port somewhere. You actually need to then set the partner port to "attN = top, X" where X is the parent in that partner port (which will actually reference the port shown). Actually, I'm considering building a fix for this. If you still have a save file available, it would be awesome if you could upload it. Cheers, ~Claw

Sounds like you have a corrupt save game. Try moving all of your savegames out and starting a new game. If that all functions correctly, exit out and try to resume the game. If that works, then you can start moving save files back one or a few at a time. When clicking on "Resume" stops bring up the game selection screen, then you have narrowed down the broken save. If that doesn't work, then post a log file so we can have a look. Usually if you can start a new game, then it messes up next time, you might have it installed to some place like Program Files or the Desktop. Windows can mess up KSP in those locations. Directions on where to find and how to upload log files can be found here: http://forum.kerbalspaceprogram.com/threads/92230-%21%21%21-PLEASE-READ-BEFORE-POSTING-%21%21%21-Stock-Support-Bug-Reporting-Guide Cheers, ~Claw

Oh noes, more work for my pile! I haven't looked yet, but my initial guess is that it's set up this way intentionally to help the editor when placing symmetric parts on the nodes. Except that you can't place symmetric parts on the nodes around... So it might be a leftover byproduct of logic to deal with something that wasn't actually implemented. Even if that isn't it, my guess is that it's a self imposed (KSP) limitation rather than an inherent limitation of the tree structure. I'll have a look, but if there is special logic put in, I think it will be difficult/impossible to fix at my level. It may take a few days before I can even check, so maybe bug me about this again. Cheers, ~Claw

There is a similar bug that affects the game with contracts. Where if a part that you previously tested is no longer available to the game, it can lock up. Or maybe you've found a new permutation entirely. Or it could be completely different. As TriggerAu suggests, it would be a good idea to start a new thread and provide the information from the support sticky here: http://forum.kerbalspaceprogram.com/threads/92230-%21%21%21-PLEASE-READ-BEFORE-POSTING-%21%21%21-Stock-Support-Bug-Reporting-Guide Cheers, ~Claw

Hmm, okay. I see what you are saying in your second post. Although it's not entirely clear to me if you're asking for a fix, or saying that it should work a different way. So I will try to break it apart and give you more information. Maybe somewhere in there will be your answer. I'm still also unclear as to if you are talking about the sticky fix itself, or my add-on fix that addresses this problem. Jeb has vanished because you selected the "fix" option that makes him vanish. There are three options available up there: Fired, Alive, and Dead. I did not include a "return to recruit" status option. The reason for that is because in the stock game without the buggy behavior, you can't do this with veteran kerbals. If you click on the X, you're firing him. That's how the game interprets it, regardless of if it's Jeb or some other kerbonaut. You are the boss. Well, firing and availability are completely different, at least as far as the game is concerned. I'm not sure if you are asking for this, but here is a more detailed explanation... A Kerbal's TYPE determines who "owns" him. There are four options: Applicant, Crew, Tourist, Unowned. As far as I can tell, the game doesn't use "Tourist". An "Applicant" shows up in the applicant pile at the astronaut building. "Crew" is someone on your payroll that you can put out on missions, etc... And "Unowned" is basically kerbals that you haven't rescued yet for rescue contracts. That is all that the TYPE attribute is used for. A kerbal's STATE determines what he's doing at the moment. There are four options: Available, Assigned, Missing, Dead. "Available" means that the kerbal is...well...available for use at KSC (putting on mission, hiring, firing, etc...). "Assigned" basically means the kerbal is out on a mission. "Missing" is for kerbals who have died in a game where spawning is allowed. And I'll let you guess what "Dead" is used for. Yes... Sort of... Kerbals are deleted from the candidate list in an odd way. Each kerbal has a timer associated with them. If they are in the applicant pool when that timer expires, they are removed from the game. This is done so that applicants "expire" after a certain amount of time in order to generate new applicants. The thing with veteran kerbals is that their timers are usually in the past. Specifically Jeb, Bill, and Bob all start out with their timers at 0 (zero). While you are in the astronaut complex... If you delete a kerbal, they are moved to the applicant pool (which is maybe what's leading to your confusion). This is so that if you make a mistake, you can "rehire" them right there. However, once you leave the astronaut complex, they are removed from the applicant list if their timer is expired. You have just "fired" them and they aren't coming back. So to tie that in with the explanation about TYPE and STATE... When you "fire" a kerbal, he is actually returned to an applicant state. As an applicant, if his timer is expired, the kerbal is deleted from the roster entirely. Never to be seen or heard from again... Hope that helps... Cheers, ~Claw Oh, and if you are asking for instructions on how to manually change his state to something else, let me know! Hopefully you can kind of figure it out from the above explanation. You can just set his ToS to Infinity, then do whatever you want with the TYPE and STATE. You could make him stay an applicant forever if you wanted to.

Nope. It'll only stop thrust for the engine that is blocked. If your craft is all stock except for MJ, load up a .craft file somewhere and I'll have a look. There aren't any stock bugs that I know of that would cause this. Cheers, ~Claw

Yep. It looks like your problem is that you fired one of the kerbals that you rescued from orbit. Specifically "Rodfel Kerman" Follow the link below. It will show you how to add Rodfel back to your roster, and will even tell you how to tag him so that he stays fired but won't break your save. http://forum.kerbalspaceprogram.com/threads/105651-FIX-KSC-Buildings-Lock-Up-Can-t-Click-on-Anything-Firing-Kerbal-Crashes-Game Also, if you aren't opposed to using an add-on, I have created a series of stock bug fixes. One of them specifically deals with this problem. Those fixes can be found here: http://forum.kerbalspaceprogram.com/threads/97285-0-25-Stock-Bug-Fix-Modules Welcome to the forums! Cheers, ~Claw

Yes, the persistence is the one that is likely broken. Given what I'm hearing now, I would say the directions in the thread linked below should solve your problem. http://forum.kerbalspaceprogram.com/threads/105651-FIX-KSC-Buildings-Lock-Up-Can-t-Click-on-Anything-Firing-Kerbal-Crashes-Game Cheers, ~Claw

Yeah, there aren't actually a lot of guides about the game itself. There are tons of guides on getting around, building ships, visiting planets, etc... But not a lot of details on the nuts and bolts. That being said, yeah, the debug menu comes with a lot of baggage for some people. My personal philosophy is that it's your game, play it how you'd like. If it feels cheaty to you, then skip it. If you feel like checking it out, do it. Although personally I find that once I start using cheats on a game to circumvent difficulty, the game itself becomes less rewarding. So I suppose that's my own personal level of "feeling cheaty." Although I'm probably opposite of you in that I've mostly been a sandbox player, and have only recently motivated myself to really drill into a career game. Cheers, ~Claw

Well, it really depends a lot on what you are doing. It would be helpful to us if you could visit this thread and provide a few more details: http://forum.kerbalspaceprogram.com/threads/92230-%21%21%21-PLEASE-READ-BEFORE-POSTING-%21%21%21-Stock-Support-Bug-Reporting-Guide Welcome to the forums! Cheers, ~Claw

The debug menu doesn't actually let you edit much. What you can do in there is activate things. Specifically for contracts, you can have the game attempt to generate a new contract type for you in the Add tab. Just realize that you can only "ask" the game to add a contract. If it doesn't find that you've done enough in your save (such as not having actually launched a rocket), it won't add anything. I don't think the debug menu allows you to customize a given contract, but I could be wrong. Cheers, ~Claw

I have found that leaving KSP open for extended periods of time can cause all kinds of problems. I'd say 8 hours of burn falls into that category. Your log file does indicate some of the physics calculations broke down, but there's not a clear cause in there. Also, the claw part seems to be a bit buggy at times. Your save file wasn't coming up on filedropper, so I can't guess much more than that. Cheers, ~Claw

Hello! Well, your picture is entirely consistent with the "can't fire a kerbal" bug shown here: http://forum.kerbalspaceprogram.com/threads/105651-FIX-KSC-Buildings-Lock-Up-Can-t-Click-on-Anything-Firing-Kerbal-Crashes-Game However, I looked through your save file and didn't see any problems so I went ahead and loaded it in my KSP. It loaded up fine and I was able to click on the buildings. Did you grab the correct save file when you uploaded? Or did you do anything immediately after saving? This bug is usually triggered by firing a kerbal that has logged an achievement or that you rescued from orbit. Specifically, you have Jeb who logged first flight. If you were to fire him, your game will lock up. Welcome to the forums! Cheers, ~Claw

I see a similar sticky launch pad report in the support forum. A quick picture would really help me track down the problem. Cheers, ~Claw

I think I know what you are talking about, and sometimes when you switch modes, you need to move the mouse off of the ship and put it back on to sort of "reset" what it's trying to attach. If that doesn't help, can you post a picture of exactly what you are seeing? I'm in the process of trying to kill some of the symmetry bugs, so I'm curious if this is another one that I haven't seen. Cheers, ~Claw

If you can just leave off the fairings, that would be handy. ~Claw

Also, engines will start to roll back when experiencing air starvation. They will enter a roll back state before completely flaming out. Given the way the current IntakeAir system works, one engine (most often the second one placed via symmetry) will roll back first, causing the aircraft to yaw. This can be insidious because you don't get the obvious "POP" and sparks. If your craft doesn't have enough control (or has a high TWR) to deal with this, then it will yaw and go out of control. So based on your pictures, I would guess that the right engine is either placed second (if done manually) or is the mirrored partner (if placed with symmetry). Check out this thread for more info about IntakeAir resourcing: http://forum.kerbalspaceprogram.com/threads/64362-Fuel-Flow-Rules-%280-24-2%29 And here is a thread trying to capitalize on that information, and reorganize intakes in an attempt to prevent asymmetric flameout: http://forum.kerbalspaceprogram.com/threads/100782-0-90-WIP-Intake-Build-Aid-0-4 Cheers, ~Claw

I need pictures, log files, and preferably .craft files (if they are stock). It's extremely difficult for me to replicate and fix a bug (or make my fix more robust) if I don't know what happened. I'm especially interested if your craft was on the Mun and still hitting the pad, because that could possibly be related to the bug that destroys space planes. Cheers, ~Claw

You are both very welcome, and thanks for the great feedback. Unless someone is putting my stuff in CKAN for me (which I suppose is possible), You're probably not getting auto updates. You can check which version you are using by opening the readme.txt file in the StockBugFixModules directory and checking the top line in the Change Log. That being said, if you experienced an ejection problem with the mod installed, I would need to see some log files. That would tell me if the module is conflicting with another mod or if it just failed to work. Cheers, ~Claw