Nereid

Feel free. I' still thinking about a cancel dialog if there are still backups ongoing. But is it realy worth the effort?

Under normal circumstances: yes. But in this case a simple volatile boolean and a "spin" to wait should suffice (it's a rare occasion anyway, and checking a boolean every 100ms won't cost much ). Problem with mutexes in C# is, that you can't aquire them mutiple times and release them just once (bad idea, I already tried this). And I'm a bit relecutant to overdesign this, because it uses a blocking queue for the jobs and you can't aquire the mutex or a lock (which is sufficient in this case) over the whole while loop that fetches the jobs. Aquiring the lock just for a single backup job is an incorrect solution either. Problem is: it's a while loop and I have to aquire the lock AFTER getting it from the queue and releasing it only when the queue is empty at the end of the loop. But maybe I have just not found the right class in C# to accomplish this task. I could do it myself writing my own class like in the old days of Java ;), but this is a bit over the top. [Yes, it's an excuse, because I'm to lazy to find a better solution or search for design patterns that solves this. ] So I have to decide: Make it not just 99,999999999999999999...% safe and redesign the job handling or keep it as it is. In theory a new backup could be scheduled while there are still backups ongoing and just waiting to complete and KSP changes the files in between. But this is an academic problem, because new backups are just scheduled in the main menu or at the next save (which waits for the ongoing backups to complete). It just won't happen. Before the latest release there was a temporary solution implemented anyway (so async was not really async). I have just forgotten to fix this, but after I read my comment in the code... And: I've never used the async option myself and I never noticed any differences. II have just done it, because I'm used to avoid the UI thread for operations like this (never ever do any I/O in the event-dispatch-thread! - never ever!), but I'm unfamiliar with Unity. EDIT: And you should never ever use mutexes in the UI-Thread either if they block because if I/O or other unpredictable reasons.

Maybe. I will think about it. But I do not have that much time the next weeks.

Try 1.10.1-3185. It shouldn't crash even with async backups anymore.

@linuxgurugamerI'm already trying to implement a way to log in the main-Thread myself. It doesn't seem to be that hard. As far as I remember I prevent this by halting the game if this occurs.

I have updated it to 1.10.0 but I didn't fix anything regarding the asynchronous backups. If a crash only happens when the ingame debug window is open, I would not call this a major issue, because for debugging you could disable this setting anyway (and its off by default). @linuxgurugamer: is there a way to to force an execution in the UI Thread? In Java Swing there are methods like invokeAndWait or invokeLater. The asynchronous option is not there to improve performance but to keep I/O out of the UI-thread. But maybe there is a better way to achieve this in Unity.

I'm a big fan of this mod, but is it just me or is the KS-29 landing gear broken? If I attach those to an aircraft it starts with the tires below the surface and then it explodes just a few seconds after launch.

There is an example at the first page. It's quite self explanatory.

Bad times for updates. Some may just enjoy their holydays. But just unzip the zip from spacedock into GameData and all is fine.

There is a new version anyway, because a found a minor bug in my own game. Choosing ribbon statistics in the hall of fame didn't work. This is fixed now.

Just checked this: FF tets for active parachutes (even cut parachutes) and if there is any on the vessel, then the crew do not qualify for the ribbon. code: // no EVA if (current.IsEVA) return false; // check vessel if (current.Origin == null) return false; // landed? if (!current.IsLandedOrSplashed) return false; // situation has to change from non-landed to landed (prelaunch wont count) if (previous.IsLandedOrSplashed || previous.IsPrelaunch) return false; // scan Vessel VesselScan scan = current.ScanVessel(); // check fuel double pct = scan.GetResourcePercentage(Constants.RESOURCE_NAME_LIQUID_FUEL); // no tanks or enough fuel left? if (double.IsNaN(pct) || pct*100 > value) return false; // deployed parachutes? if (scan.deployedParachutes > 0 || scan.semiDeployedParachutes > 0) return false; // cut or active parachutes? if (scan.activeParachutes > 0 || scan.cutParachutes > 0) return false; // return true; PS: The method ScanVessel does not scan the vessel every time for every check. It's checked only once and cached for further checks, because it's an expensive operation (it has to iterate over all parts of the vessel).

Well... I really can't remember what the check exactly does. And I'm a bit to lazy to check it now.

Maybe. If anyone can reproduce this, please tell me and please keep a save just before the landing. BTW: There is still quite a few lines old code in FF from old days , where KSP was buggy (e.g. didn't fire some events). And it was my first project in C#, (and in Unity) written in about two weeks (or less) initially. So weird things may happen. But changing them and streamlining the code is to much work and will introduce to many bugs. None of my friends is playing KSP - at least not regulary. And I'm very reluctant to change any basic things at the moment without at least two or three people testing it. And then there are other games at the moment that get my attention.

Then its a bug. Maybe they changed something and FF doesn't detect parachutes anymore.

But you had a fuel tank? And it was empty? Then you qualified for this ribbon, because you met all its conditions. Kerbal logic is simple logic.