skips

This mod does not work with version 1.3 (MacOS X) without recompilation. In addition the calling sequence of ResearchAndDevelopment.GetExperimentSubject() appears to have changed. An additional argument, which brings the number of arguments to 5, has been added with the name displayBiome. Duplicating the value for the fourth argument appears to restore the functionality of the mod. skips

If you want to use this mod with probes, lookup Starwaster's Science Patches. They are Module Manager patches that install ModuleScienceContainer modules in all probe vessels. The lack of a ModuleScienceContainer prevents this mod from working with probes. skips

A slightly modified version works fine for me. You might want to check for conflicts with the other mods that you are loading. skips

See my posts from 7 Jun 2015 for my solution to this problem. As far as I can tell it does not lose any science and it matches the original game mechanics. skips

Two comments: 1. The collection of data at the LaunchPad is non-functional due to the elimination of the delay in StatesHaveChanged(). Reinstating the stopwatch delay re-enables the collection of science at the LaunchPad. 2. The decision to prevent science from the non-repeatable experiments does not appear to be consistent with the KSP model, which allows the one-time collection to data from non-repeatable experiments. It is my opinion (and only my opinion) that it would be better to have ForScience be more consistent with the KSP model and allow the collection of science one-time from non-repeatable experiments without a scientist. skips

re Instability/Constant Crashing [No fix, possible workarounds] The crash appears to be caused by an error in using the GPU. The text from a crash report is Process: KSP [8734] Path: /Users/USER/*/KSP.app/Contents/MacOS/KSP Identifier: unity.Squad.Kerbal Space Program Version: Unity Player version 5.2.4f1 (5.2.4f1) Code Type: X86-64 (Native) Parent Process: ??? [1] Responsible: KSP [8734] User ID: 502 Date/Time: 2016-04-20 19:00:15.833 -0400 OS Version: Mac OS X 10.11.4 (15E65) Report Version: 11 Anonymous UUID: 6778CDA8-47CE-84BD-4FDE-351A8F0A65D4 Time Awake Since Boot: 2500000 seconds System Integrity Protection: enabled Crashed Thread: 6 UnityGfxDeviceWorker Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x0000000000000000, 0x0000000000000000 Exception Note: EXC_CORPSE_NOTIFY Application Specific Information: abort() called Application Specific Signatures: Graphics hardware encountered an error and was reset: 0x0000001f Reducing the size of the window appears to reduce the frequency of crashes. skips

KSP 1.0.5 broke this mod. There was a change made to the constructor for the ScienceData class that invalidated some of the code. The function newScienceData() assumes that the ScienceData constructor takes 5 arguments. In KSP 1.0.5, the constructor takes 7 arguments. If you are maintaining this mod, you can restore the functioning of it by changing newScienceData() to be private ScienceData newScienceData(ModuleScienceExperiment currentExperiment) { return new ScienceData( currentExperiment.experiment.baseValue * currentScienceSubject(currentExperiment.experiment).dataScale, currentExperiment.xmitDataScalar, 0f, currentScienceSubject(currentExperiment.experiment).id, currentScienceSubject(currentExperiment.experiment).title, false, currentExperiment.part.flightID ); } skips

Release 1.0.5 changed the ScienceData class such that the previous constructor is no longer recognized. This change is preventing the collection of science from Dmagic's Orbital science experiments. skips

@Mikemc According to the log, the issue is the protections on the C:\Program Files directory. It is unfortunate that KSP is incompatible with the default security configuration of most new systems. The recommendation to move KSP out of the C:\Program Files directory should resolve your problem. skips

Your statement might well be true, however, it is not documented in the second message of the first page. The syntax that I suggested is documented in that message. I believe that it is in the best interest of all of the users to point people to the documentation and suggest that they help themselves. Note that this statement is merely my opinion and you are free to disagree. skips

From first page, second message @PART[FUELTANKNAME] { @TechRequired = heavyRocketry @title = FT-450 @description = We've got the gas! !RESOURCE[Oxidizer] {} }

1. Add the Goo Experiment to a spacecraft without a scientist aboard. 2. On launchpad activate the Goo Experiment manually. 3. Launch the rocket. 4. After retrieval, examine the Science Archive in the R&D center. It will show zero science accomplished entries for "Flying over Kerbin" and the biome on which the craft landed. See my previous post with the git differences. The issue with the Science Archive has to do with the order in which you do the tests. If you reorder them as I have done, the zero science entries will not appear in the Science Archive. I also included a IsOnetimeNotRunnable() function that can be used to allow run once experiments to execute once per flight. This implementation has the interesting side-effect that if you have two experiments on board, they each get executed in different biomes. Feel free to use or throw away the changes that I posted. skips PS: You can get the current code to work with probes by just adding a Container to the probe. A simple Module Manager configuration file is all that is needed. - ss

Here is a git difference that allows ForScience to execute non-rerunnable experiments once per flight. In addition, the reordering of the tests prevents zero science return entries in the Science Archive list. skips diff --git a/Source/ForScience.cs b/Source/ForScience.cs index aa2c83b..9bd5e83 100644 --- a/Source/ForScience.cs +++ b/Source/ForScience.cs @@ -110,28 +110,28 @@ namespace ForScience Debug.Log("[For Science] Checking experiment: " + currentScienceSubject(currentExperiment.experiment).id); #endif - if (ActiveContainer().HasData(newScienceData(currentExperiment))) // we have the same experiment data onboard, so we skip it + if (!currentExperiment.experiment.IsAvailableWhile(currentSituation(), currentBody())) // this experiement isn't available here so we skip it { #if DEBUG - Debug.Log("[For Science] Skipping: We already have that data onboard."); + Debug.Log("[For Science] Skipping: Experiment is not available for this situation/atmosphere."); #endif } - else if (!currentExperiment.rerunnable & !IsScientistOnBoard()) // no cheating goo and materials here + else if (IsOnetimeNotRunnable(currentExperiment)) // no cheating goo and materials here { #if DEBUG Debug.Log("[For Science] Skipping: Experiment is not repeatable."); #endif } - else if (!currentExperiment.experiment.IsAvailableWhile(currentSituation(), currentBody())) // this experiement isn't available here so we skip it + else if (currentScienceValue(currentExperiment) < 0.1) // this experiment has no more value so we skip it { #if DEBUG - Debug.Log("[For Science] Skipping: Experiment is not available for this situation/atmosphere."); + Debug.Log("[For Science] Skipping: No more science is available: "); #endif } - else if (currentScienceValue(currentExperiment) < 0.1) // this experiment has no more value so we skip it + else if (ActiveContainer().HasData(newScienceData(currentExperiment))) // we have the same experiment data onboard, so we skip it { #if DEBUG - Debug.Log("[For Science] Skipping: No more science is available: "); + Debug.Log("[For Science] Skipping: We already have that data onboard."); #endif } else @@ -140,6 +140,7 @@ namespace ForScience Debug.Log("[For Science] Running experiment: " + currentScienceSubject(currentExperiment.experiment).id); #endif ActiveContainer().AddData(newScienceData(currentExperiment)); //manually add data to avoid deployexperiment state issues + completedExperiments.Add( currentExperiment ); } } @@ -315,6 +316,22 @@ namespace ForScience } return returnvalue; } + + private bool IsOnetimeNotRunnable( ModuleScienceExperiment currentExperiment ) + { + var returnvalue = false; + if (!currentExperiment.rerunnable & !IsScientistOnBoard()) + { + foreach (ModuleScienceExperiment doneExperiment in completedExperiments) + { + if (doneExperiment == currentExperiment) + { + returnvalue = true; + } + } + } + return returnvalue; + } } }

An alternative explanation is that the configuration changes that the configuration files are requesting MM to make are exposing the race condition in stock. I would suggest that you take a long and careful look at the changes that the configuration files are making. skips

My best guess is that you have AOA enabled and when it cuts off your thrust because the aerodynamics are overpowering your attitude control, the center of lift changes significantly and your attitude control cannot cope. Try turning off the AOA limiter and adjusting the shape of your ascent profile to better match the changing direction of your velocity. Ideally you should be able to adjust your ascent profile to match the natural gravity turn of your craft and never trip the AOA limit, but that takes a significant amount of fiddling with the profile and your thrust limiter. BTW: none of these issues are directly MechJeb problems. skips