Rodhern

I haven't decided about the EULA yet. Regardless, a symbolic gesture of skipping or delaying KSP-related purchases seems appropriate for the time being.

The Diazo link is indeed a good one. If I may add one comment though. In general C# is the best/safe bet, especially if you already know C#, but you don't have to choose C#; most dotnet languages will do.

I agree, some graphics would be nice :-)

Anyone that do understand the fuel flow priority system well probably deserves some kind of medal. Do we even know someone like that? (I guess with a forum like this, there is bound to be a few though).

I would just put my new file in the GameData/KeepFit/ConfigData folder with all the other ones. (It is not a requirement, but makes sense to me). I think both node formats are fine, so probably just pick the simple one? (But I don't actually know the purpose of the fancier structure).

Nah. Usually neither the addon nor KSP will copy dlls about the place. I haven't uploaded to Spacedock for some time. I did edit the Spacedock listing front page to make a notice about this issue though. Maybe CKAN figured that is an update. Or, maybe MiniAVC is triggered. In any case, it is quite strange, but good to know, in case others experience something similar.

Hmm, I guess that is useful to know. How do you install your addons? I mean, 'something' must have reinserted the dll.

A long time ago I remember there was a wrapper or something along those lines, and a detailed description of how to read the player's Scansat progress from other mods. That way custom mods could query Scansat to know which scans where done and how much coverage they had reached for each celestial body. I can't seem to find the link now. If you remember a link like that, would you please (re)post it for me.

Excellent. In case anyone else is now wondering why that dll would be in there in the first place. The thing is, if it is not, then the players without Connected Living Spaces installed get the error instead. That is kind of an even worse situation, because that is an error even more 'out of the blue' than the current situation.

@Fergrim, could I get you to try and delete the 'CLSInterfaces.dll' from the KeepFit folder (but keep the one in ConnectedLivingSpace as is). Some while ago that file acted up when it was found twice, but we never really figured what a proper solution would be. And if possible add a fresh log when running the game again.

I don't have a Dropbox account (I don't think). I cannot read the uploaded log file. Is there an easy-ish fix you can do?

A button is supposed to be there, to bring up the status window(s).

If you havn't already, maybe you could check or upload the log file. If we are lucky there could be some hints in there. Edit: You are on KSP 1.3.1 right?

The crew seem a tad .. uhhm .. apprehensive though.

It is a cool question. Snark made a good comment regarding vertical rocket ascent over here. It made me think what the analogue vertical ascent argument would imply for a winged craft climbing steadily at a fixed angle above the horizon. Recapitulation that TWR = 2 is the optimal climb thrust. Consider lift-to-drag (L/D) ratio and vary the climb angle. If we have wings, we may fly less vertical and at a lower TWR. As far as the relative simple model is concerned, the climb fuel cost is worse than the straight up TWR 2 climb. However, if we want to save on TWR, wings are a good alternative to just naively reducing TWR. I think this answer is interesting information, but I also realize that possibly the real questions are still unanswered. The above arguments are mostly concerned with 'slow' flying planes, and a lot of players are far more interested in fast space planes.

Thank you for the report. I have had issues with KRASH spam too, without UPFM installed. In my case KRASH keeps pausing the game even if it is already paused. Some of the KRASH loops aren't entirely mature yet. I am not sure if that is relevant to this situation. I just wanted to give a general heads up about the KRASH log spam tendency.

This is a quite usual scenario actually. The way the percentage settings of Strategies and the percentage settings in the difficulty settings interact, it is very easy to get in to a situation where every successful mission costs you some net-prestige.

I have changed the 'aqua' string to its Unity equivalent '#00ffffff'. I didn't check to see if there is a problem for (lime coloured) 'Exercising' too. Let me know if there is, then I will make another mini-update. The update is just uploaded to Spacedock.

In one of the earlier versions I used "Kerbokatz small utilities FPSLimiter", which allowed my fans to not spin as fast (less heat). I don't need it in the newer KSP versions, but it might be worth a try (?).

I may not be the best to answer this question, as Xamarin Studio won't really work for me. As for the dotnet35 thing, occasionally I misconfigure my Visual Studio, and I noticed that I can open the project files in a text-editor and correct stuff like the references and Visual Studio will keep my changes even if they don't exactly match up. I don't know if Xamarin will let you do the same. It may be worth a try. Try to look in the .csproj and find/read/change: <TargetFrameworkVersion>v3.5</TargetFrameworkVersion>

I guess I can't argue with the "better safe than sorry" attitude you display. Also, it is nice of you to make recommendations to better avoid mistakes. In this case though, I (and it may well be just me) do not feel that an extra set of parentheses makes the formula any clearer. Again, this isn't meant to say that @DC's suggestion is poor; it is more for readers stumbling on this post later and wondering if stuff like " [M]/100*[E]*3600*[O] " needs parentheses to work; it doesn't, but you can add parentheses if you feel it is an improvement. Edit: Ahh, maybe I remember a reason for your recommendation after all. Some people in some contexts use "/" to mean an implicit set of parentheses to the right of the "/"-symbol. You can avoid that by an explicit set of parentheses. I hadn't that in mind when I answered, simply because I don't use that convention myself. So maybe, yes, your recommendation might make the formula clearer after all. And it got me to ponder which version is clearer - probably a healthy exercise.

I am an idiot that answered an old post.

Recompiled for KSP 1.3.1. Uploaded to Github as Kapoin ver. 0.1.1.1.

I think you misunderstand what I am trying to say. I completely agree with your statement. I wasn't trying to say that doing it by hand should be the main way. I noticed a pattern/behaviour that would allow several easy ways of implementing part module load/save, and noticed that a particular node got in the way. Now JPLRepo have explained that the upgrades system makes it so that it is not easy to do it the way I suggested. I am sure that sort of conclusion is obvious to those of you that are very familiar with the code. If I don't ask if a feature can be improved you probably wouldn't even have guessed how potentially confusing it can be for someone that only knows of the KSP code by a number of API signatures and some forum posts.

I am not entirely sure, but I think this is how you do. Go to KCT Settings, fold out the formulas by clicking "Show/Hide Formulas". In the NodeFormula window you see something like "2^([N]+1) / 86400". Change that to, say, "2^([N]+1) / 86400 * 3". [Edit: Remember to click apply]. Now your nodes will be researched 3 times as fast.