the [Bug] fix for Lockup in 0.90

[PB666]

I have been directed to the bug fix from one of the threads in the Unmodded section.

I have a modded installation but was directed to a bug fix for unmodded install, for this reason I am posting here.

In some of the games Jeb was killed after he fell through the KSC terrain (another bunch of bugs). However in a few other crashed games Jeb was not killed, fired or resurrected. I moved him from active status to inactive status, so he would not be automatically pulled for further ground missions (i suppose this is a form of firing, but his experience stats stick with him if he goes on a launch mission), I have been rotating nauts in and out of active status. In most cases for Jeb, this was done at the very beginning of the game, before any missions were undertaken, whereas the game crashes occurs much later in the game after almost a dozen missions have been completed. In all cases except one all pilots were returned home before the next mission preceded. Most games were in hard carreer, however one was normal career (It actually locked up the fastest).

For 0.90 I think the sticky needs to be rewritten to deal with the specifics of possibilities in 0.90. This lockup is more complicated in 0.90 than the sticky presents. I have been playing this game for more than a year and I have never experienced this lockup until 0.90, there are specific things happening with this version (either game-controlled, user-input or combinations of both) that would only rarely be encountered in previous versions.

[vexx32]

If you're referring to the save game glitch related to firing Kerbals, AFAIK that one's pretty recent, and there is a sticky thread dedicated to detailing how to fix it. Unless I'm misunderstanding your meaning, I'm not really sure what you're asking for...

[PB666]

If you're referring to the save game glitch related to firing Kerbals, AFAIK that one's pretty recent, and there is a sticky thread dedicated to detailing how to fix it. Unless I'm misunderstanding your meaning, I'm not really sure what you're asking for...

The sticky fix repaired the game, but Jeb has vanished, lol. Its not a problem, more than an inconvinience, Even if Jeb has never engaged in a mission, he can never be a candidate, so I guess when I need him I will have to manually 'recruit' him to crews.

I don't consider moving him back to candidate status firing him, since he owns the firm. Its like the boss deciding to remove himself from a duty roster. If I want fire him I would make him unavailable. So the exact meaning of these feilds is not exactly clear.

BTW, This was done to keep KSC from killing Jeb while gathering KSC science, at least if I was going to kill off a green minion with buggy texture through-falls, it should actually be a minion. (A kerbal with low courage and high stupidity).

So let me be explicit, if you move players from active status to inactive status, and they have accomplished some goal (say launched a craft) then while they initially appear to be a candidate again, what they really are is disappearred, since they can never be a candidate, again. This is my emperical observation.

That's kind of what is missing.

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

The sticky fix repaired the game, but Jeb has vanished, lol. Its not a problem, more than an inconvinience, Even if Jeb has never engaged in a mission, he can never be a candidate, so I guess when I need him I will have to manually 'recruit' him to crews.

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.

I don't consider moving him back to candidate status firing him, since he owns the firm.

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.

Its like the boss deciding to remove himself from a duty roster.

You are the boss.

If I want fire him I would make him unavailable. So the exact meaning of these feilds is not exactly clear.

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.

So let me be explicit, if you move players from active status to inactive status, and they have accomplished some goal (say launched a craft) then while they initially appear to be a candidate again, what they really are is disappearred, since they can never be a candidate, again. This is my emperical observation.

That's kind of what is missing.

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.

Edited January 10, 2015 by Claw

[PB666]

I will address these in a moment

First off, I created a new game 'default'.

Before doing anything I 'fired' Jeb, he was placed as candidate. On return he was gone. So this checked out. He was replaced by a new named pilot.

Next I fired Bob and Bill, on reloaded the 'default' game they were deleted, and two new pilots appears. This checks out.

Next I put chuck on a mission, he completed and gained exp, I then, 'fired' him. He went to the applicant section.

Without closing the game I then accepted two new missions

Erroneously the program autoselected Chuck as the pilot for next two builds, defaulting over the two pilots on the list.

On game reload (live KSP) he was still on the applicants list. (which is what I originally expected)

I then closed KSP and reloaded. Chuck was still in the applicants list (not deleted) with his experience stats.

Chuck, of course, is Shroedinger's cat.

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.

Oddly I named my company after him, :^)

No but I can rehire chuck, he has not been deleted.

And So following this statement I rehired chuck and sent him on a mission.

I again fired him, and I again tried to add missions.

I managed to remove him from the roster by doing the following,

-placing him on the candidates list

-in the VAB creating a capsule, then going to crew, removing his name from the MK1 capsule and placing another active pilot in his place.

After repeated attempts at trying to crash the game I have been unable at top of tier 3. The rescue mission has showed up . . . . . . . . . . . .

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

at least as far as the game is concerned can be used as a placeholder name for what it actually is, because the observations suggest that it goes undefined. Jeb, Bill, Bob...Bye-bye; Chuck is like a stalking ex-girlfriend.....

It should be as such:

If firing is true then Kerbals identity should be removed from applicant roster on the next reload no matter what.

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

Shroedinger even confused Einstien god does not play dice with the universe

Either the bug is more complex or Heisenberg uncertainty is at play. Does the game employ a random number generator?

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.

To summarize, players can't fire kerbs, they can 'demote' them to candidate, and what the game does is delete them. Since the players are not firing them and the game is doing something other than firing them, in essence they cannot be fired. This lack of a definition is the cause of the bug. If demoting is a lead up to firing, then expired kerbs should be relisted, not deleted.

This is consistent with the observations, but. . . . . ..

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

I will buy all of this except the fact that firing a candidate does not remove him from potentially active status, he may still default as pilot of the next mission [bug N+1](verified twice). As such he will show up on the candidates list and active list at the same time [bug N + 2](verified twice).

This is why there is confusion about activity and firing. Traditionally if one fires someone he is removed from his status he would not be a candidate; instead identified but banished as not to be rehired; this would fix the games problem, creating a term called Banished. In actuality chuck appears to be demoted but still active. If a pilot is fired he should not default to the next mission, even if the game is not closed. I hope you see what I mean by this is a complex and confusing bug the outcome of 'firing' depends on when you closed the game and how long since it was closed or the kerbal was 'fired'. A current build or future build in the VAB should not have recently fired pilot default appear.

Since I cannot purposefully crash the game I will restate under what circumstances the game was crashed. Kerbs could be moved from active to inactive status up until some point in the game, in which this or something else caused a crash. Since reinstating Jebediah's profile recovered one game we have to assume that this is at least part of the problem. In the last few games I was playing I was rotating pilots in and out of hired status all was going well until I get to the top of the (45 sci) level of the tech tree. Here is what is observed combined with these, again I did not close the game after every hire or fire because I had no reason to expect this was a problem.

1. Remove the kerbals from active status, put a kerbal with bad stat in. May or may not complete one faux launch for a mission and Jeb Exp.

2. Roam and MK1 roll around KSC gathering science, rolling back to pad to get full salvage. Lots of small sci. This may also include the use of Mat science and goo.

3. level up, using KSC science I usually get two middle of tier 4 (45 pts per)

4. At tier 4 begin going after altitude missions followed by orbital mission.

5. Around this point in the game the lock-up occurs.

I cannot say when exactly I opened and closed the game, generally I don't play more than 2 hours at a sitting so I think that the game was closed and opened at least once. Roaming KSC takes alot of time with or without exploits.

IMHO, there is something more to this problem than what you have identified and what I have identified, maybe I have to wait a really long time for those timers to expire and crash the game, seems reasonable but not certain.

Hope that helps...

About 2/3rds there, couple more issues that need some work.

[Claw]

No but I can rehire chuck, he has not been deleted.

And So following this statement I rehired chuck and sent him on a mission.

...

at least as far as the game is concerned can be used as a placeholder name for what it actually is, because the observations suggest that it goes undefined. Jeb, Bill, Bob...Bye-bye; Chuck is like a stalking ex-girlfriend.....

It should be as such:

If firing is true then Kerbals identity should be removed from applicant roster on the next reload no matter what.

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.

Edited January 11, 2015 by Claw

[PB666]

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.

OK, OK.....Not exactly what you are saying.... Chuck the quantum kitty gets placed on the applicant list. Then I go get a mission (or not) and go to an assembly building, launched........ but there's ole Chucky [psycho movie background music playing], an applicant to be deleted, an active pilot at the same time. What we really need here to make this right is an automated pilot makeover in which the kerbal turns orange and has blood vessels popping out of his skin, mid flight the rocket veers off course and lands in the center of large impact crater on the other side of the Kerbin, followed by a wicked laugh and chucky proclaiming to rule the world......Yes, this would be the perfect bug fix and a new hidden career mode---Insane - world of missilecraft.

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.

.....and they are accepting missions for which they had been previously fired ......and showing up on two rosters at one time.

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.

Summary: Assuming that these nested bugs are all part of the same phenomena they may begin presenting themselves in various ways. 'Fired' players may be the default crew on future missions, show up on two rosters (active and applicant) at once and other oddities. However eventually they will be deleted and once deleted, because they have previously achieved some past recognition (like landing on an uninhabited volcano, ), lock-up the game on a later facility entry and exit.

[Claw]

OK, OK.....Not exactly what you are saying.... Chuck the quantum kitty gets placed on the applicant list. Then I go get a mission (or not) and go to an assembly building, launched........ but there's ole Chucky [psycho movie background music playing], an applicant to be deleted, an active pilot at the same time.

I hear you. What I'm trying to say is that you have found a new bug (where he's showing up as a crew member in the next flight, despite being an applicant) and it is a different bug than the one that causes the game to lock up.

I would also presume restarting KSP prevents this second bug from happening, because the crew manifest handler is wiped out. That's good news, because that means it's probably easily fixable. That's not the case for the roster bug, it will persist across KSP restarts, and took a lot more integrated fixing and roster management. (Also, it is my own fault that the roster bug is misleadingly named, since it's not actually a bug in the roster.)

Let me restate again. The bug that causes the lock up is not actually a bug with the roster. It is a bug in the scenario module save routines.

I can't check into at the moment, but this second bug sounds fixable within my existing crew roster fix. I would say that you did find another bug, and could definitely cause bad problems, including triggering the roster bug discussed in the sticky.

Thank you for the find, and the detailed description. I will try to check it out in the next few days.

Cheers,

-Claw