Crazy Diamond

I have found two situations that prevent data collected by a deployed science instrument (Ionographer PD-22, Go-ob ED Monitor, etc.) from being transmitted back to Kerbin even when a good communication link from the Probodobodyne Experiment Control Station to Kerbin, optionally through a relay, is available. If either one or both of these conditions exist, then the science completed by the instrument(s) will not be transmitted. While the problems are likely due to programming logic errors, workarounds are available as detailed below. I have observed that the science collected by a deployed science instrument is transmitted at about 28-day intervals provided the equipment is powered and enabled, additional science has been collected, and a communications link is available. If there is no communications link at the time a transmission is attempted at the end of the next interval, a message communicating the failure is posted for each instrument, the key noCommNetMsgPosted in the corresponding SCIENCECLUSTER.MANNEDSCIENCEPARTS.MANNEDSCIENCEPART.EXPERIMENT section of the Persistent.sfs or other save file is updated with the value "True", and no further transmission attempts are ever made even if the comm link is restored before the next interval. To fix this problem, reset noCommNetMsgPosted = False for all affected instruments in the save file. Even with transmissions suspended after losing a comm link, deployed instruments will continue to collect science until they reach 100% of the science limit. When that happens, editing the noCommNetMsgPosted key value is still necessary but is not sufficient to fix the problem because there is no new science to be collected which is needed to trigger a transmission attempt. So, in addition to setting noCommNetMsgPosted = False in the save file, you must also reduce TotalScienceGenerated to a value below ScienceLimit found in the same EXPERIMENT sub-section so that new science may be completed to trigger a transmission attempt. You should also reduce StoredScienceData by the same percentage. (StoredScienceData was 12 times smaller than TotalScienceGenerated in my save file.) Next, you must also reset Enabled = True in the MANNEDSCIENCEPART section for each affected instrument. You may also want to verify that isEnabled = True in the instrument's VESSEL.PART.MODULE section found later in the save file. Searching for the MANNEDSCIENCE PartID will help you locate the vessel part having the matching persistentId. After editing and saving the save file, reload the file in Kerbal Space Program. Expect up to 28 game days to elapse before receiving a message stating successful science data transmission provided a good communication link is available at the moment the transmission is attempted.

I have found two situations that prevent data collected by a deployed science instrument (Ionographer PD-22, Go-ob ED Monitor, etc.) from being transmitted back to Kerbin even when a good communication link from the Probodobodyne Experiment Control Station to Kerbin, optionally through a relay, is available. If either one or both of these conditions exist, then the science completed by the instrument(s) will not be transmitted. While the problems are likely due to programming logic errors, workarounds are available as detailed below. I have observed that the science collected by a deployed science instrument is transmitted at about 28-day intervals provided the equipment is powered and enabled, additional science has been collected, and a communications link is available. If there is no communications link at the time a transmission is attempted at the end of the next interval, a message communicating the failure is posted for each instrument, the key noCommNetMsgPosted in the corresponding SCIENCECLUSTER.MANNEDSCIENCEPARTS.MANNEDSCIENCEPART.EXPERIMENT section of the Persistent.sfs or other save file is updated with the value "True", and no further transmission attempts are ever made even if the comm link is restored before the next interval. To fix this problem, reset noCommNetMsgPosted = False for all affected instruments in the save file. Even with transmissions suspended after losing a comm link, deployed instruments will continue to collect science until they reach 100% of the science limit. When that happens, editing the noCommNetMsgPosted key value is still necessary but is not sufficient to fix the problem because there is no new science to be collected which is needed to trigger a transmission attempt. So, in addition to setting noCommNetMsgPosted = False in the save file, you must also reduce TotalScienceGenerated to a value below ScienceLimit found in the same EXPERIMENT sub-section so that new science may be completed to trigger a transmission attempt. You should also reduce StoredScienceData by the same percentage. (StoredScienceData was 12 times smaller than TotalScienceGenerated in my save file.) Next, you must also reset Enabled = True in the MANNEDSCIENCEPART section for each affected instrument. You may also want to verify that isEnabled = True in the instrument's VESSEL.PART.MODULE section found later in the save file. Searching for the MANNEDSCIENCE PartID will help you locate the vessel part having the matching persistentId. After editing and saving the save file, reload the file in Kerbal Space Program. Expect up to 28 game days to elapse before receiving a message stating successful science data transmission provided a good communication link is available at the moment the transmission is attempted.

I have experienced this in my mostly stock game also. The asteroid mass after harvesting 100% of the resources is reported as 140t in the pop-up property box but the delta-v information suggests a mass of 1979t (after I subtract the 387t ship and fuel mass) which I suspect was the original total asteroid mass including resources. This absolutely kills my available delta v and makes it ridiculously difficult to move the asteroid into a Moho orbit from the environs of Kerbin even after sending a refueling ship. My whole strategy depended on depleting the mass of the asteroid by converting its resource mass into fuel but I've been thwarted by this programming oversight.

I've been using your lights as navigation lights and to light payload bay interiors. Thank you so much. However, I noticed that since the latest update with the stock color changer and KSP v 1.11.0.3045, my color settings made in the VAB are NOT saved using the following procedure: 1. Turn on light 2. Select color 3. Turn off light 4. Save vehicle When I reload the vehicle, I find that the color has reverted to the default white color. I would prefer following the above steps because I can confirm the color and appearance as I change the light settings and still have the lights off by default when I load and launch the vehicle later. The settings are only saved by following one of these alternate procedures: 1. With light turned off, select color 2. Save vehicle OR 1. Turn on light 2. Select color 3. Save vehicle But even then, I sometimes find the colors revert to the default white upon launching the vehicle. I believe the same problem may be evident with the new stock lights.

I observe loose shrouds on my spacecraft all the time upon returning my attention to them. I attribute it to shoddy craftsmanship. Duct tape needs to be added as a stock component. https://imgur.com/a/VPmeG