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

I have been playing with this mod for a couple of days and have three suggestions. 1. Leave the minimum science limit but consider lowering it to 0.01 science. (I am not unhappy with it remaining at 0.1 science return.) 2. Expand the filter to eliminate storing any experiment that would result in zero net science. This change would clean up some of the mess that appears in the Science Archive with experiments that cannot be executed being listed with zero science value. 3. Enable the execution of the non-rerunnable experiments once, if there is no scientist aboard and only if the returned science is greater than the minimum. This change would allow the use of these experiments with unmanned craft albeit only once per flight. This change would meet the spirit of both the squad implementation and this mod. skips

This result should be expected. You asked for a major axis of your orbit to be kerban's radius + 75 km. MechJeb provided that semi-major axis. The issue is why your rocket failed to stop accelerating when the apoapsis reached 75 km. It may have to do with the other mods that you have installed, because my rockets generally hit the desired apoapsis within 1-5 km for requested altitudes between 75 and 300 km. skips

This mod collects science points as they become available for manned Pods. With a scientist aboard, the science from the Goo and Materials Bay experiments will be collected as well. When you recover the spacecraft, all of the collected science gets added to your total. The Module Manager configuration file extends this capability to Probes (i.e., spacecraft with no manned Pod). skips

It allows this mod to collect science from a ship that contains a probe and no pod. Note that you cannot collect science from the Goo Experiment or Materials Bay as they require a Scientist crew member and probe's have 0 crew requirement. skips

Here is a module manager configuration that will enable you to collect science from probes. @PART[*]:HAS[@MODULE[ModuleCommand],#vesselType[Probe]] { MODULE { name = ModuleScienceContainer reviewActionName = Review Stored Data storeActionName = Store Experiments evaOnlyStorage = False storageRange = 1.3 } } skips

Turn off the AOA limiter and adjust your ascent path to match the turn profile you need to keep from losing control. skips

It is likely that the issue is with the "lift" generated by the atmosphere between 15 km and 30 km overpowering your guidance system. With atmospheric effects being much more prominent in KSP 1.0, you have to be very careful to maintain a reasonable acceleration and speed until you are above 35 km. These issues are not related directly to MechJeb but to the design of your spacecraft and the ascent path that you have setup. skips

Here is the configuration file that I use with Module Manager (being posted for about the 4th time). ///////////////////// // change the technology requirements for MechJeb ///////////////////// @PART[*]:HAS[@MODULE[MechJebCore]] { // delete any existing MechJebCore modules // !MODULE[MechJebCore] { } // insert MechJeb module with revised tech tree assignments// MODULE { name = MechJebCore MechJebLocalSettings { MechJebModuleCustomWindowEditor { unlockTechs = basicRocketry } MechJebModuleSmartASS { unlockTechs = flightControl } MechJebModuleManeuverPlanner { unlockTechs = advRocketry } MechJebModuleNodeEditor { unlockTechs = advRocketry } MechJebModuleTranslatron { unlockTechs = fuelSystems } MechJebModuleWarpHelper { unlockTechs = generalRocketry } MechJebModuleAttitudeAdjustment { unlockTechs = advFlightControl } MechJebModuleThrustWindow { unlockTechs = basicRocketry } MechJebModuleRCSBalancerWindow { unlockTechs = fuelSystems } MechJebModuleRoverWindow { unlockTechs = fieldScience } MechJebModuleAscentGuidance { unlockTechs = generalRocketry } MechJebModuleLandingGuidance { unlockTechs = generalRocketry } MechJebModuleSpaceplaneGuidance { unlockTechs = aerodynamicSystems } MechJebModuleDockingGuidance { unlockTechs = specializedConstruction } MechJebModuleRendezvousAutopilotWindow { unlockTechs = specializedConstruction } MechJebModuleRendezvousGuidance { unlockTechs = specializedConstruction } } } } Keep in mind that this change will not unlock MechJeb capabilities that require maneuver nodes. The existence of maneuver nodes requires upgrades to the facilities at KSC. This change is a Squad decision in both Career and Science modes. If you do not like it, either play in Sandbox mode or complain to Squad. One other suggestion that I would make is to make sure that you have upgraded all of your mods to work with the latest release. With the 1.0 release, Squad changed the rules significantly even for mods that are just different parts (i.e., no .dll file). There is no assurance that the old modded parts will work with the new KSP. For the same reason, I would recommend starting with a new game whenever Squad releases a new version. Although they may make sure that the stock parts are upwardly compatible, there is no reason to believe that they will do the same for modded parts. These opinions are mine, but then again I follow them and I do not experience all of the problems that are reported on this forum. skips - - - Updated - - - @sarbian Do you happen to know if there is a reason for setting the "DecEndAlt" to twice the "Drag Length"? I noticed in the setup code that the landing autopilot skips atmospheric braking if the drag length is more than 70 percent of the atmosphere's depth. With the DecEndAlt set to twice the drag length, the coast will end immediately if the drag length is more than half the atmosphere's depth. I have played around with setting the DecEndAlt to 1 times the drag length (plus the altitude of the landing point), which is about 8 KM for Kerban and did not see any adverse effects. For the ships that I fly, the final descent phase starts when the ship is approximately at the terminal velocity (i.e., the drag acceleration is approximately 1 g). In any case thanks for thinking about this issue. skips

I do not see this problem with craft that have two MechJeb parts on the same stage (for symmetry reasons) and a MechJeb module in a probe part. skips

@Apollo13 Be advised that I cannot duplicate your problem with KSP 1.0.2 and MechJeb dev version 2.5.0.0-453 with no other mods installed. skips