drake127

Yes, it just needs to be recompiled against 1.8.0.

This was fixed in KSP 1.7.2.

Yes, it works well without any additional steps (except updating assemblies, defines etc.)

It looks like 1.7.2 fixes science gain issue. :-) Unfortunately, asc (applyScienceScale) is still True in save file. @Jognt Can you check BG experiments how they behaves? I was hoping to calculate science based on asc, but it seems that it's ignored now?

Sure, I didn't think of that. However, should it be percentage of science cap (~90 %), experiment gain percentage (~1-5%), experiment gain (~0.1)? I didn't test all experiments nor Breaking Ground expansion so I am not sure what scale is the most reasonable. For standard science on Kerbin, each of those figures lead to three to five measurements. I am not sure how it scales with high-yield science though. I may look into it later.

You need to build Google dependencies once - you are apparently missing protoc.exe (Google protobuf) that compiles .proto files.

I created a PR that calculates science for onboard experiments correctly. I have also prepared fixes for GUI but I am not sure if we can agree on some specific threshold that marks experiment completion (PR).

I can but I am not sure if it's allowed here or generally a good idea. What errors did you encounter?

That's right! I was wondering why I have some recurring experiments fully completed in my save file. Now if we just fix the equation, we are not able to complete any (recurring) experiment. That makes UI quite unfriendly when filtering completed experiments. So where should we draw a line? I was thinking about 90 % of science, 0.1 science earned per measurement, 1 % science earned per measurement or something similar? There's no point to clutter list when full science is unreachable...

Hi, during my gameplay I noticed that I was unable to complete an atmosphere analysis experiment without many many tries even when [x] Science! reports green full bar. After long investigation I found out that science gain in [x] Science! is calculated incorrectly and in reality it's nearly impossible to reach full bar. E.g. after six collection of atmosphere analysis on KSC runway you are still missing 0.68 science points (from 7.2 total) and gaining just 0.05 per collection and declining. I propose two changes: Fix the formula for calculating collected science onboard. It prevents filling the bar completely when there's plenty of science left. The [x] Science! considers an experiment to be completed (collected) when there is less than 0.1 science to obtain. That's almost impossible to get for most recurring experiments, so I would also consider an experiment completed when you would recover at least 0.1 science points during single run. What do you think? I can create PR if needed.

Hi, I want to share my experience with compiling Principia from sources. I wanted to add KSP 1.7.1 support because waiting one whole month is unbearable and I was encouraged by the fact that there are virtually no changes in KSP support since 1.4.0. There's good tutorial how to build Principia from sources on project wiki (https://github.com/mockingbirdnest/Principia/blob/master/documentation/Setup.md) but I wanted to use VS 2019 and as little dependencies as possible. It turned out quite well because in the end I only needed: VS 2019 with C++ and C# support Windows SDK 10.0.18362 .NET Framework 4.7.2 SDK (and Targeting Pack) I also noticed that recommended PS command "$GitPromptSettings..." is unnecessary (it's just an optimization). It was necessary to patch all project files (including Google dependencies) to target .NET framework v4.7.2 (was v4.5, v4.5.2 and v4.6), SDK 10.0.18362.0 instead of others, and even change platform toolset to v142 (currently v141) - i.e. it was possible to completely switch to the most beautiful VS 2019. Great thing is that it compiles and passes tests! As for the changes for 1.7.1, there aren't that many (depends how thorough you want to be). For gaming it's enough to replace all 1.7.0 to 1.7.1, 1_7_0 to 1_7_1 and fix ksp_plugin_adapter.cs on line 207 to (Versioning.version_minor == 7 && Versioning.Revision <= 1))). It compiles for some time and if it fails, you have to start from the beginning. When I managed to build Google dependencies, I commented them out (build_solutions($dependencies)) in rebuild_all_solutions.ps1 to speed things up a bit. I had to compile Principia about four times before I catched all the errors but it's definitely doable and there's no dark magic. :-)

I had same problem with stock Minmus where timewarp altitude (3000 m) is bellow some of the terrain. Settings timewarpAltitudeLimits to 6000+ also helped.