maja

I just posted about this in M.O.L.E. thread

It's configuration for the [x] Science not MM config, so you need to edit it. I think it's better to ask him in his own thread. You can filter whatever you want yourself if you know an experiment id. They are in the config files of science experiment parts.

You don't need to remove [x] Science. Just add this to the CelestialBodyFilters section in science.cfg config in [x] Science folder. This will filter out M.O.L.E. experiments. // WBI WBISurfaceConstructionStudy = AvoidAll WBIKNUTS = AvoidAll WBIBRE = AvoidAll WBISAME = AvoidAll WBIOrbitalRecon = AvoidAll WBICryogenicRadiationStudy = AvoidAll WBICryogenicResourceStudy = AvoidAll WBICryogenicStudy = AvoidAll WBICrystalGrowth = AvoidAll WBIGooStudy = AvoidAll WBIIceCreamResearch = AvoidAll WBILongTermCryogenicMiniStudy = AvoidAll WBILongTermCryogenicStudy = AvoidAll WBIMESS = AvoidAll WBIConstructionTechniques = AvoidAll WBIPowerToolsEvaluation = AvoidAll WBISpaceAdaptionStudy = AvoidAll WBITemperatureStudy = AvoidAll WBIThermalStudy = AvoidAll

It's one of readouts in the Rendezvous section.

@steve_v @westamastaflash I had this error too and pinpointed it to the planned path string in the game save file. It was probably corrupted. I planned shorter trip (around 120 km) and everything worked again.

I did PR #1221 for that few days before. Just head ups for @RoverDude, that there are some other changes too, to resolve conflicts during merge

Click anywhere in the ScanSat window except the map.

No worries. There is at least that workaround with control core or service bay, if someone needs to use that two parts (esp. tail cargo bay). All your mods are great

Sorry for a little delay @Nertea. Here it is. Steps to reproduce, screenshots, craft files and log file. Only mod installed was Mk4 Spaceplane System (version 2.3.6) with all necessary mods from the mod zip file. https://www.dropbox.com/s/jjzgnz5wjq2y3e0/shielding_bug.zip?dl=0 There is also interesting behaviour, when some cargo is unshielded, if you close all bays at the same time. Workaround is to open and immediatelly close a bay with an unshielded cargo (repeat for all bays with an unshielded cargo). This workaround doesn't work, if you have crew cabin or tail bay attached to the bays.

Will do.

I had this bug even with short cargo bays, so I did a few tests on a clean installation. It seems, that it manifests itself if cargo bays are after the Mk4 crew cabin or if there is the Mk4 tail cargo bay at the end. I saw first four hours of the @RoverDude's stream and he had there tail cargo bay. @sh1pman can probably confirm this.

You're right. I probably missed an use case during testing.

I'm not sure, that there were some definite info from @allista. What I know from my tests is, that this manifest itself when GC is part of MKS and RT is installed. What I can tell from the log, the error is raised during RT ModuleRTDataTransmitter::OnLoad function. Who need to fix what, that I don't know.

I know it, because I reported it in this and RT thread

Reported few times already

Hi @tomf, I'm getting constant log spam with the new version: [LOG 22:03:23.712] [StatSci:3/18/2017 10:03:23 PM]: Checking MeetRequirements [LOG 22:03:23.712] [StatSci:3/18/2017 10:03:23 PM]: Checking lab and a docking port Is it possible to switch off these messages with some cfg setting?

I found discusion about this in this thread, that these experiments are meant only for Kerbin. You can use them everywhere, they are only hidden from [X] Science UI. Just comment that 4 lines (two slashes on the begining of every line) or you can delete them. I did this too, because I'm using CTT which needs a lot of science

The Sounding rocket experiments are enabled only for Kerbin in [X] Science config.

The [x] Science has problem with most if not all Orbital Science experiments. I think, it's because you need to deploy them or there is some other animation (like laser beam).

Me too. You can tell, that something is wrong, because the gauge with the remaining dV doesn't move.

Regarding this error, it seems like interaction with Remote Tech. I did some tests on clear installation with MKS (I'm using GC bundled in MKS) and Remote Tech and every time antenna is added to a vessel in VAB/SPH, on scene change and after staging (and after boarding I think) the coroutine spam starts. I posted it to the Remote Tech thread, but didn't have time to test it with GC and RT only to verify that problem is in the GC core. I can provide logs, if you want @allista

I think, that this has something to do with the latest integration of the Ground Construction mod to the MKS. These three parts has the GroundWorkshop module. @RoverDude can shed some light on this issue.

Hi, I'm getting error "Coroutine couldn't be started because the the game object 'Tundra.Workshop250' is inactive!" in version 1.8.4 when antenna is added to a ship. This is definitelly a conflict with RoverDude's MKS, so it's just heads up, that this kind of error can arise: RemoteTech: ModuleRTDataTransmitter::OnLoad (Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 42) RemoteTech: ModuleRTAntenna: Find TRANSMITTER success. (Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 42) RemoteTech: ModuleRTAntenna: Add TRANSMITTER success. (Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 42) Coroutine couldn't be started because the the game object 'Tundra.Workshop250' is inactive! (Filename: Line: 738) Coroutine couldn't be started because the the game object 'Tundra.AssemblyPlant' is inactive! (Filename: Line: 738) Coroutine couldn't be started because the the game object 'Ranger.Workshop' is inactive! (Filename: Line: 738)

It's in persistent.sfs (..\Kerbal Space Program\save\{game name})

I have this problem too. You need to write letter P two times and then delete one, to use it when renaming a vessel.