Mihara

What about the Sonic Rainboom one?

I have been getting the same kind of log spam as listed above, which coincides with CommNet giving out entirely. It typically remains dormant for some time until I switch a vessel, whereupon CommNet abruptly is not working anymore -- all probes report they are disconnected and cannot be controlled -- and nothing will fix it short of quitting KSP entirely. This happened in the career mode, and it started happening after installing Community Tech Tree, but I'm not sure if these events are connected or not. Removing UPGRADE blocks in antenna configurations fixed this problem. It sounds like a stock bug that this upgrade configuration triggers in certain circumstances, though the exact reproduction steps remain elusive.

I have also encountered the problem of CommNet breaking entirely upon getting a part upgrade for the antennas, every time I have loaded a vessel with an upgraded antenna. Removing the upgrade blocks in part configs solved it for me.

I wouldn't want to turn this into a "please revive xxxx" either, you're doing enough maintenance work already. But 6S Service Compartment Tubes are still useful, have a compatible license, and need no extra work to revive -- the last post in the thread contains the requisite config changes which I am using in 1.3.

Mysteriously, this particular plugin is responsible for dropping the FPS in tracking station all the way down to 4 for me. Ship's map view is not affected, and there's nothing in the logs. Any ideas?

Sure, ok. Will I have to ask for balancing guidelines a third time or will you agree that you will never explain what sort of balance you wanted to achieve and why?

For point one, I'm not criticising, I'm asking a question: Why is this possible, what is the internal logic, what exactly habitation is meant to model? Because, yes, I can solve this issue in numerous ways, but it won't make the event that happened make sense -- the crew could turn the craft, but didn't, because they were too homesick, and then they stopped being homesick seconds before it was too late to turn the craft. I would love to see some life support balancing guidelines. The existing documentation is both out of date -- it lists the default habitation as a "month" rather than the 7 days it actually is -- and not clear on what means what. Life support values offered by various mods are all over the place too. For point two -- so why are the default grace periods are different for habitation and supplies, then, with habitation being lower than supplies?

That's what it does, or at least should. I.e. if we're below this altitude over our homeworld, we're "on Kerbin" in which case most of the checks get ignored, if I'm reading the source right. I would love to see some balancing guidelines, to be honest. I want to know the reasoning why exactly is it intended to work this way, so I can correctly patch the life support into all the parts floating around which don't come with it.

Why is it designed so that kerbals can refuse to control their capsule during reentry, due to being homesick? Because that's what killed them, before the loss of power they had 30+ days of habitation remaining. What's the point of the 15 day grace period on supplies, then?

Stock converters were one of those things I never dived into before -- actually, when I last abandoned KSP they didn't exist yet -- and I don't really want to start now, because I have a feeling this will turn into another session of running after everyone's code with a flyswatter trying to change something right after they did it. Anyway, since I'm here... I think the concept of habitation needs work. What exactly is it supposed to be, and how exactly does it cause homesickness? What exactly is homesickness, conceptually, and how exactly does it impair or kill a kerbal? Because here's a story... So I have a large station around Minmus, and I'm trying to devise a crew transfer vehicle with the following properties: Must hold six kerbals, and be an automatic, pushbutton launch with no intermediate docking procedures. This is a chore, it's taking my time from other things to do around Minmus. Must be able to get there, and, which is important, return after a flyby if something happened, and for whatever reason they can't dock and resupply. Must be able to land safely without complicated manual procedures like landing an aircraft, because I suck at those. The limiting factor on this turns out to be hab, not supplies, because it's easy enough to stock enough supplies and/or recyclers to make them last 15 days, and there's the 15-day grace period anyway, a 20-day endurance on supplies is trivial. But habitation in a pod runs out after 7 days with the default settings -- and not a month as the documentation seems to say (and for the record, NASA's Orion is apparently supposed to have 21 days endurance, which obviously includes habitation requirements) -- often leaving them hours of hab left before they dock, and leaving no margin of error for the return trip. I've found multiple solutions for keeping six kerbals in one pod, but none of them have habitation bonuses, and upon reflection most of them probably shouldn't, being, well, descent capsules. So I have to pack a hab module, and the most mass and cost effective solution is usually one or another variation on the hitchhiker can. Which don't exactly make for an easy automatic landing, so they need to be decoupled. They also complicate launch escape systems, not to mention that they tend to look rather ugly. They also tend to result in far more hab than this vehicle could possibly need, and stacking up observation cupolas to get just the right amount produces really ugly, not to mention part-heavy vehicles. I've spent a few days tuning such a vehicle with varying results, but here's an anecdote about one of the versions: The trip to Minmus proceeds normally, they burn for aerobraking, and it so happens that the descent module enters Kerbin's atmosphere right at the edge of dawn. I decouple everything below the heatshield, and that's exactly the moment the crew refuses to work. Due to homesickness. Literally when they can't possibly go anywhere but home, anymore. I'm not sure if that's the hab sucking out the remaining batteries in seconds, or the number of parts changing triggering a recomputation, but the pod with the hitchhiker can (because I tried to be optimal and packed six kerbals in six seats, four of them being the hitchhiker) has no one at the controls and is flying through the air sideways. The vehicle has remote control as a matter of policy, but because there's still no batteries, and because I just decoupled the solar panels, I can't turn them heatshield first. They return to duty at 25km altitude, moments before the vehicle burns up in the atmosphere. I obviously can just turn up the base habitation multiplier, but -- why did you balance it this way, and not some other way? P.S. Possibly, homesickness should also have a grace period the way supplies do, so that given an unprepared pod, by default, a kerbal would be disabled by lack of supplies and homesickness simultaneously...

Just stepped into this one yesterday, figuring it out was complicated. SimpleConstruction omits the file GameData/ExtraplanetaryLaunchpads/Textures/plaque.png from the original Extraplanetary Launchpads. This file is required for the survey stakes to work and its name is hardcoded in the plugin itself, so you can't even move it, it has to be named exactly that. Not So Simple Construction forgot to include it either, probably, because version 5.7.0 of Extraplanetary Launchpads did not require this file. Get the file from the full Extraplanetary Launchpads and the stakes will work.

I am using it in 1.3 as-is, no issues whatsoever.

I've been wondering why the survey stakes aren't working -- as in, calling the menu produces NREs in the log and a mangled window when using stakes, but everything appears to work normally when using a launchpad. Found it. The current, 5.8.0 version of Launchpad.dll hardcodes the location of three textures - icon_button, icon_filter and plaque, in ExtraplanetaryLaunchpads/Textures. The third one is required for the stakes. SimpleConstruction bundles the first two, but not the third one. Now I'm wondering why nobody seems to have noticed.

I dearly wanted to avoid diving into KSP code again. Well, upon reflection, no, it looks like the exception is thrown somewhere in KSP's base resource converter class, which means that the exception can probably be suppressed, but can't really be prevented, since the assumption in question is not made by accessible user code. That's why we can't have nice things.

Shouldn't just returning if active scene is editor without touching the last update time nix the problem, though?

Did. As far as I can tell the problem no longer recurs. This should be relatively easy to prevent, though, shouldn't it?

...Wasn't that exactly what I said?

I'm seeing some strange log spam: [EXC 20:26:20.903] NullReferenceException: Object reference not set to an instance of an object USITools.ModuleResourceConverter_USI.PostProcess (ConverterResults result, Double deltaTime) LifeSupport.ModuleLifeSupportRecycler.PostProcess (ConverterResults result, Double deltaTime) BaseConverter.FixedUpdate () [EXC 20:26:20.904] NullReferenceException: Object reference not set to an instance of an object USITools.ModuleResourceConverter_USI.PostProcess (ConverterResults result, Double deltaTime) LifeSupport.ModuleHabitation.PostProcess (ConverterResults result, Double deltaTime) BaseConverter.FixedUpdate () This comes in spurts, and not unexpectedly, coincides with a significant drop in framerate while it lasts. I'm not sure if I can produce a reproducible save and there could be hundreds of mod interactions, so there could be lots of reasons, but maybe this section of the code needs some more robust debug messaging... One particular interaction I'm suspecting might be involved is EditorTime: the slowdown is particularly prominent when I'm in the VAB, and its whole shtick is spinning time while you're there. The spurts do appear to start after I spend some time in the VAB while my vessels with life support are in the world. It never happens in the design sandbox save, which is free of running vessels.

A question about stackability: Is there a particular reason why the KAS connector port is not stackable? I can't seem to think of one, but I decided to ask before writing a patch making it so, just in case it will bring the kraken on me or something.

There's a bug in the contracts for this. Well, probably several, but at least one. I think I'm going to tell this as a story, because it is amusing... So I get a contract to put up a telescope. I duly construct a small station to service it and launch it, yay! Now that I got the science results from around Kerbin, I go back to the contracts to see... No, not a "Put one around the Mun now." Put another one up around Kerbin. But I don't want another station around Kerbin! So I make a token vehicle, telescope, solar panel, lab, and launch it, and then immediately deorbit it. That's how I find that not only the telescope does not get burned up, it also serves as an excellent airbrake, not unlike the 2.5m ballute. Most of the "station" makes it to the ground despite me not expecting it to. I come back to contracts to find... another contract for a Kerbin telescope. So I decide to get crafty. I exploit the fact that it airbrakes so well and set it up to land. A few attempts later, I succeed -- even just deleting it is profitable, after all, getting almost all of it back is a nice bonus. I take out the contract again, but decide to take a break, and go back to resupply my station. Poof, the contract gets fullfilled: It counts as a "new" telescope in orbit. This is infinitely repeatable. This kind of puts a cramp into my attempts to play career seriously. EDIT: Oh, and I keep getting contracts that tell me to do radioastronomy on the surface. I don't think this kind of telescope should work for this sort of thing, but maybe that's just me.

You left a debug log in: https://github.com/ChrisAdderley/NearFutureSolar/blob/master/Source/ModuleCurvedSolarPanel.cs#L251 Identifying the source of the log spam was rather nontrivial.

Answering my own question: Found it! https://github.com/ChrisAdderley/NearFutureSolar/blob/master/Source/ModuleCurvedSolarPanel.cs#L251

Nope, not it. And you'd think Trajectories would spam the log with every vessel, not just one station.

Like that's going to help. ⏚ [mihara:~/.steam/steam/steamapps/common/Kerbal Space Program/GameData] 8d8h7m24s $ find . -type f | grep dll | sort -u ./000_AT_Utils/Plugins/000_AT_Utils.dll ./000_AT_Utils/Plugins/001_AnisotropicPartResizer.dll ./000_AT_Utils/Plugins/002_MultiAnimators.dll ./000_AT_Utils/Plugins/ConfigurableContainers.dll ./000_AT_Utils/Plugins/SubmodelResizer.dll ./000_FilterExtensions/FilterExtensions.dll ./000_USITools/USITools.dll ./000_USITools/USITools.dll.mdb ./ActionGroupManager/ActionGroupManager.dll ./AllYAll/Plugins/AllYAll.dll ./AntennaSleep/AntennaSleep.dll ./Astrogator/Astrogator.dll ./Astrogator/Astrogator.dll.mdb ./AviationLights/Plugins/AviationLights.dll ./B9_Aerospace_ProceduralWings/Plugins/B9_Aerospace_WingStuff.dll ./B9PartSwitch/Plugins/B9PartSwitch.dll ./BahaSP/Plugins/BDAnimationModules.dll ./BetterBurnTime/BetterBurnTime.dll ./BetterTimeWarp/Plugins/BetterTimeWarp.dll ./BonVoyage/BonVoyage.dll ./CIT/BAM/Plugins/BAM.dll ./CIT/CITUtil.dll ./CollisionFX/Plugins/CollisionFX.dll ./CommunityCategoryKit/CCK.dll ./ConnectedLivingSpace/Plugins/CLSInterfaces.dll ./ConnectedLivingSpace/Plugins/ConnectedLivingSpace.dll ./ContractConfigurator/CC_RemoteTech.dll ./ContractConfigurator/ContractConfigurator.dll ./ContractConfigurator/KerKonConConExt.dll ./CorrectCOL/Plugins/CorrectCoL.dll ./CrewLight/CrewLight.dll ./CrowdSourcedScience/Plugin/ScienceFixer.dll ./CustomBarnKit/CustomBarnKit.dll ./DatedQuickSaves/DatedQuickSaves.dll ./DeployableEngines/Plugins/DeployableEngines.dll ./DistantObject/DistantObject.dll ./DMagicOrbitalScience/Plugins/DMagic.dll ./DMagicScienceAnimate/DMModuleScienceAnimateGeneric.dll ./DMagicUtilities/CapCom/CapCom.dll ./DMagicUtilities/ContractParser/ContractParser.dll ./DMagicUtilities/ProgressParser/ProgressParser.dll ./DraggableAltimeter/DraggableAltimeter.dll ./DraggableNavball/DraggableNavball.dll ./EarnYourStripes/EarnYourStripes.dll ./EasyBoard/EasyBoard.dll ./EasyVesselSwitch/Plugins/EasyVesselSwitch.dll ./EasyVesselSwitch/Plugins/KSPDev_Utils.0.23.0.dll ./EditorExtensionsRedux/Plugins/EditorExtensionsRedux.dll ./EditorTime/EditorTime.dll ./EnvironmentalVisualEnhancements/Plugins/Atmosphere.dll ./EnvironmentalVisualEnhancements/Plugins/_BuildManager.dll ./EnvironmentalVisualEnhancements/Plugins/CelestialShadows.dll ./EnvironmentalVisualEnhancements/Plugins/CityLights.dll ./EnvironmentalVisualEnhancements/Plugins/EVEManager.dll ./EnvironmentalVisualEnhancements/Plugins/PartFX.dll ./EnvironmentalVisualEnhancements/Plugins/PQSManager.dll ./EnvironmentalVisualEnhancements/Plugins/ShaderLoader.dll ./EnvironmentalVisualEnhancements/Plugins/Terrain.dll ./EnvironmentalVisualEnhancements/Plugins/TextureConfig.dll ./EnvironmentalVisualEnhancements/Plugins/Utils.dll ./EVAEnhancementsContinued/Plugins/EVAEnhancementsContinued.dll ./Firespitter/Plugins/Firespitter.dll ./Firespitter/Plugins/Firespitter.dll.mdb ./FlexoDocking/FlexoTubes.dll ./FlightPlan/FlightPlan.dll ./FMRS/Plugins/FMRS.dll ./FP_DPSoundFX/Plugins/FP_DockingSndFX.dll ./Hangar/Plugins/Hangar.dll ./HLAirships/Plugins/HLAirships.dll ./HullCameraVDS/Plugins/HullCamera.dll ./HullCameraVDS/Plugins/HullCamera.dll.orig ./IndicatorLights/IndicatorLights.dll ./InterstellarFuelSwitch/Plugins/InterstellarFuelSwitch.dll ./InterstellarFuelSwitch/Plugins/Scale_Redist.dll ./JanitorsCloset/Plugins/JanitorsCloset.dll ./KAS/Plugins/KAS.dll ./KEI/KEI.dll ./KerbalEngineer/KerbalEngineer.dll ./KerbalEngineer/KerbalEngineer.Unity.dll ./KerbalJointReinforcement/Plugin/KerbalJointReinforcement.dll ./KerbalReusabilityExpansion/DeployableAeroSurfaces.dll ./Kerbaltek/HyperEdit.dll ./KerbetrotterLtd/000_KerbetrotterTools/Plugins/KerbetrotterTools.dll ./KerbNetController/BetterKerbNet.dll ./KerboKatz/KerboKatz.UI.dll ./KerboKatz/KerboKatzUtilities.dll ./KerboKatz/SmallUtilities/FPSLimiter/FPSLimiter.dll ./KIS/Plugins/KIS.dll ./KIS/Plugins/KSPDev_Utils.0.23.0.dll ./kOS/Plugins/ICSharpCode.SharpZipLib.dll ./kOS/Plugins/kOS.dll ./kOS/Plugins/kOS.Safe.dll ./KspCraftOrganizer/Plugins/KspCraftOrganizerPlugin.dll ./KSPRescuePodFix/KSPRescuePodFix.dll ./KSPWheel/Plugin/KSPWheel.dll ./Landertron/Landertron.dll ./LaunchNumbering/LaunchNumbering.dll ./LightsOut/LightsOut.dll ./MagiCore/MagiCore.dll ./MechJeb2/Plugins/MechJeb2.dll ./ModuleManager.2.8.0.dll ./NavBallDockingAlignmentIndicatorCE/Plugins/NavBallDockingAlignmentIndicatorCE.dll ./NavyFish/Plugins/Docking Port Alignment Indicator/DockingPortAlignmentIndicator.dll ./NavyFish/Plugins/Docking Port Alignment Indicator/DPAI_RPM.dll ./NavyFish/Plugins/Docking Port Alignment Indicator/ModuleDockingNodeNamed.dll ./NearFutureElectrical/Plugins/NearFutureElectrical.dll ./NearFutureProps/Versioning/MiniAVC.dll.pruned ./NearFuturePropulsion/Plugins/NearFuturePropulsion.dll ./NearFutureSolar/Plugins/NearFutureSolar.dll ./NearFutureSpacecraft/Versioning/MiniAVC.dll.pruned ./Nereid/FinalFrontier/Plugins/FinalFrontier.dll ./NRAP/Plugins/NRAP.dll ./PartCommanderContinued/Plugins/PartCommanderContinued.dll ./PlanetaryBaseInc/BaseSystem/Plugins/PlanetarySurfaceStructures.dll ./PlanetShine/Plugins/PlanetShine.dll ./ProceduralDynamics/Plugins/pWings.dll ./ProceduralParts/Plugins/ProceduralParts.dll ./RCSBuildAid/Plugins/RCSBuildAid.dll ./RCSBuildAid/Plugins/RCSBuildAidToolbar.dll ./RealChute/Plugins/RealChute.dll ./RealTimeClock2/RealTimeClock2.dll ./ReCoupler/ReCoupler.dll ./RecoveryController/Plugins/RecoveryController.dll ./ReentryParticleEffect/Plugins/ReentryParticleEffect.dll ./ReentryParticleEffect/Plugins/ReentryParticleEffect.dll.mdb ./REPOSoftTech/DeepFreeze/Plugins/DeepFreeze.dll ./RetractableLiftingSurface/Plugins/RetractableLiftingSurface.dll ./SafeChute/SafeChute.dll ./SCANsat/Plugins/SCANmechjeb.dll ./SCANsat/Plugins/SCANsat.dll ./SCANsat/Plugins/SCANsat.Unity.dll ./ScienceRelay/ScienceRelay.dll ./SelectableDataTransmitter/Plugins/SelectableDataTransmitter.dll ./SensiblePumpsCont/Plugins/SensiblePumps.dll ./SensibleScreenshot/SensibleScreenshot.dll ./ShipManifest/Plugins/CLSInterfaces.dll ./ShipManifest/Plugins/ShipManifest.dll ./SimpleConstruction/Plugins/Launchpad.dll ./SmartActuation/SmartActuation.dll ./SmokeScreen/SmokeScreen.dll ./Solar Science/Plugins/SolarExperimentKmi.dll ./Solar Science/Plugins/SolarExperimentStereo.dll ./Squad/Plugins/KSPSteamCtrlr.dll ./Squad/Plugins/Steamworks.NET.dll ./Squidsoft Collective/ControlHereAG/ControlHereAG.dll ./Squidsoft Collective/FuelCellTweaks/FuelCellTweaks.dll ./StationPartsExpansion/Versioning/MiniAVC.dll.pruned ./Strategia/Strategia.dll ./SurfaceLights/Plugins/SurfaceLights.dll ./SXT/PlugIns/ModuleBounce.dll ./TacFuelBalancer/TacFuelBalancer.dll ./TakeCommand/Plugins/TakeCommand.dll ./TankLock/Plugins/TankLock.dll ./TextureReplacer/Plugins/TextureReplacer.dll ./TooManyOrbits/TooManyOrbits.dll ./Trajectories/Plugin/Trajectories.dll ./TriggerTech/KerbalAlarmClock/KerbalAlarmClock.dll ./TweakScale/plugins/Scale.dll ./TweakScale/plugins/Scale_Redist.dll ./UmbraSpaceIndustries/ART/DynamicTanks.dll ./UmbraSpaceIndustries/Konstruction/Konstruction.dll ./UmbraSpaceIndustries/Konstruction/Konstruction.dll.mdb ./UmbraSpaceIndustries/LifeSupport/USILifeSupport.dll ./UmbraSpaceIndustries/LifeSupport/USILifeSupport.dll.mdb ./UmbraSpaceIndustries/WarpDrive/WarpEngine.dll ./UmbraSpaceIndustries/WarpDrive/WarpEngine.dll.mdb ./VanguardTechnologies/Plugins/VanguardTechnologies.dll ./WasdEditorCamera/Plugins/WasdEditorCamera.dll ./WaypointManager/WaypointManager.dll ./WildBlueIndustries/000WildBlueTools/Plugins/WildBlueTools.dll ./WildBlueIndustries/001KerbalActuators/Plugins/KerbalActuators.dll ./WildBlueIndustries/Heisenberg/Plugin/AirshipUtils.dll ./Wwwwwwwww/Wwwwwwwww.dll ./[x] Science!/[x] Science!.dll ./XyphosAerospace/Plugins/ControlFromHere/ControlFromHere.dll ./ZeroMiniAVC/Plugins/ZeroMiniAVC.dll

To be precise, a particular vessel -- a rather huge station, at that, so it's challenging to find out if a given specific part is responsible -- keeps spamming debug output in the logs: [LOG 20:24:20.564] 4.657114 [LOG 20:24:20.564] 17.34298 [LOG 20:24:20.564] 26.65707 [LOG 20:24:20.564] 94.65758 [LOG 20:24:20.564] 72.65759 [LOG 20:24:20.564] 116.6576 [LOG 20:24:20.564] 175.3427 [LOG 20:24:20.564] 162.6571 [LOG 20:24:20.564] 153.3428 Now, it's probable the culprit is a plugin I don't actually need, or maybe something that's relatively easy to fix, only, the bloody thing doesn't say who that is, and further investigations don't provide any clues. Failing the obvious "Dear modders, please please please make sure the log output of your plugins is easy to identify!" which nobody will care about, can anyone provide any pointers?