Gotmachine

Radiation and shielding is averaged over the whole vessel, it doesn't matter where the kerbals are. Currently the only way of changing that is by disabling specific habitats, which isn't really practical because that will depressurize them. Gameplay wise, the basic recommendadtion are : - Max out shielding for anything interplanetary, you will need a lot of extra margin, trust me. - Avoid getting inside radiation belts as much as possible - Follow this guide to design a vessel that minimize solar storm induced radiation : https://github.com/Kerbalism/Kerbalism/wiki/PlayGuide-~-Environment#coronal-mass-ejection-cme

@kubi This is a bug, the geigerCounter experiment definition is missing, not sure if that's recent or not. Thanks for the report.

JPLRepo's Background Resource is the only one alive, BackgroundProcessing by jamespicone is dead since a very long time. Background Resource isn't really released and isn't meant to be hooked into by external mods like BackgroundProcessing was, as far as I know. I gave you the link to the Background Resource repo where you can see a some examples of how it adds supports for the stock modules (even some barebone support for a NFE module). Talk with JPLRepo, maybe he will accept a PR. Is that a direct answer enough ?

Those downloads are here because Background Resource is bundled with TAC-LS and DeepFreeze. As a Kerbalism contributor and someone that followed all those background processing mods since a few years, I was just giving you some insight related to your question. Background Resource is a rewrite of the old background processing mod, you got JPLRepo answer, he didn't really release it and as far as I know there has been very little activity on it, and I don't think it's really mean't to be hooked into at this state. The source is here : https://github.com/JPLRepo/REPOSoftTechKSPUtils/tree/master/BackgroundResources In my opinion it's way too far to be complete for widespread use, it doesn't handle solar panel correctly at high timewarp speeds and it only support stock modules. There are a lot of popular mods using custom converters and generators. That's why I suggest going the stock way of post-facto processing on vessel load instead of continuous background processing, unless you really want to face all the very hard to fullfill mod support requests that will come with that decision.

@Silent1_87 AmpYear and Kerbalism have been incompatible since quite some time, probably won't get ever fixed. As for RPM, proper support support would require code on their side, If you want to get into it. You can come on our discord if you have specific questions.

My point is that there is no widely adopted background processing plugin. The only active ones are JPLRepo's backgroundprocessing and Kerbalism, they are incompatible with each other, the first one isn't really distributed and not maintained much, the latter isn't independent from the whole Kerbalism mod. So in the context of ODFC, you can add some code to support/integrate with those if you want (although in the case of kerbalism, ODFC is mostly irrelevant), but you will still need your own fallback.

The reason is that nobody is using those plugins and they never got any attention beside a few modders. Any kind of background processing mod introduce a lot of issues and mean a lot of mod compatibility problems. The core problem is that the various pieces of stock code related to resource processing (on loaded vessels) have deep issues. The only real way to get around them all would be to bypass the whole thing and write a whole new resource framework/API complete with all the required partmodules, then convince everyone to use them or to use that common API instead of the stock system/modules. There has been some efforts here and there but so far nobody has come with something good enough for widespread adoption.

@pp3d We are aware of the issue with some WBI dependant mods (Airships, Buffalo...) due to us using the same "Atmosphere" resource name with a different density. Unfortunately changing that name would break all existing saves, and since we are planning to remove that resource we won't fix it, sorry for that. @lk00david See https://github.com/Kerbalism/Kerbalism/wiki/FAQ#q-my-probes-use-12-ecs-for-comms-and-die-within-seconds @tinygrox Feel free to contribute another language if you can, but be aware that the Kerbalism UI code is (very) partially localized.

It's a confirmed bug since 1.8, reported by several people. As far as I know there isn't any fix. You can upvote https://bugs.kerbalspaceprogram.com/issues/24061 in hope Squad will do something about it...

Commnet constellation is doing a lot of custom stuff with commnet, I would say it's a likely suspect. If it somehow set a value in commnet to NaN at some point, that will cause kerbalism to have NaN data, causing NaN part masses, causing everything to crash. It's useless to uninstall mods that give exceptions after this is happening, as I said once you are past the point where some NaN is introduced, everything will crash because of that.

Try disabling vessel transmission in the kerbalism automation, and see what happen. Edit : any mod related to commnet / antennas ? But as soon as you have NaN in anything related to science / data in kerbalism, bad things will happen (due to that causing NaN masses)

Kerbalism data with NaN sizes can definitely cause major issues because that will propagate to NaN part masses, causing a large portion of KSP and other mods to freak out. This said, not sure the original NaN is from Kerbalism, could be a NaN in commnet variables introduced by another mod. This is hard to troubleshoot unless we can reproduce in a debugger-enabled environnement.

@tychochallenge That readme is from ROKerbalism, which is a Kerbalism config pack maintained by @Standecco The Kerbalism people / contributors offer no support in any form for RO, although we cooperate with the people behind RO-RP1 and ROKerbalism. I suggest you bring any issue to the RO-RP1-Kerbalism discord channel : https://discord.gg/xxBvKB

I don't think you should be using Sdk="Microsoft.NET.Sdk" That's for .NET standard projects. How did you create that *.csproj ? I suggest creating a new project using VS for mac, with the "multiplatform > library" template. For reference, this is what I get in VS for windows using the default .net framework (not .net core / .net standard) library template : <?xml version="1.0" encoding="utf-8"?> <Project ToolsVersion="15.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> <Import Project="$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props" Condition="Exists('$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props')" /> <PropertyGroup> <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration> <Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform> <ProjectGuid>fe8f3ab9-cb75-43eb-b1a3-5a5e93a7fc66</ProjectGuid> <OutputType>Library</OutputType> <AppDesignerFolder>Properties</AppDesignerFolder> <RootNamespace>ClassLibrary1</RootNamespace> <AssemblyName>ClassLibrary1</AssemblyName> <TargetFrameworkVersion>v3.5</TargetFrameworkVersion> <FileAlignment>512</FileAlignment> <Deterministic>true</Deterministic> </PropertyGroup> <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' "> <DebugSymbols>true</DebugSymbols> <DebugType>full</DebugType> <Optimize>false</Optimize> <OutputPath>bin\Debug\</OutputPath> <DefineConstants>DEBUG;TRACE</DefineConstants> <ErrorReport>prompt</ErrorReport> <WarningLevel>4</WarningLevel> </PropertyGroup> <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' "> <DebugType>pdbonly</DebugType> <Optimize>true</Optimize> <OutputPath>bin\Release\</OutputPath> <DefineConstants>TRACE</DefineConstants> <ErrorReport>prompt</ErrorReport> <WarningLevel>4</WarningLevel> </PropertyGroup> <ItemGroup> <Reference Include="System"/> <Reference Include="System.Core"/> <Reference Include="System.Xml.Linq"/> <Reference Include="System.Data.DataSetExtensions"/> <Reference Include="System.Data"/> <Reference Include="System.Xml"/> </ItemGroup> <ItemGroup> <Compile Include="Class1.cs" /> <Compile Include="Properties\AssemblyInfo.cs" /> </ItemGroup> <Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" /> </Project> And this is the *.csproj for my mod (targeting KSP 1.8 /.NET 4.x) <?xml version="1.0" encoding="utf-8"?> <Project ToolsVersion="12.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> <Import Project="$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props" Condition="Exists('$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props')" /> <PropertyGroup> <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration> <Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform> <ProjectGuid>{98D72929-051F-4028-9BA6-293E2379A2B2}</ProjectGuid> <OutputType>Library</OutputType> <AppDesignerFolder>Properties</AppDesignerFolder> <RootNamespace>MandatoryRCS</RootNamespace> <AssemblyName>MandatoryRCS</AssemblyName> <TargetFrameworkVersion>v4.6</TargetFrameworkVersion> <FileAlignment>512</FileAlignment> <KSPDllPath>K:\Projets\KSP\Kerbal Space Program 1.8.1 PLAYTEST</KSPDllPath> <TargetFrameworkProfile /> </PropertyGroup> <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' "> <DebugSymbols>true</DebugSymbols> <DebugType>portable</DebugType> <Optimize>false</Optimize> <OutputPath>bin\Debug\</OutputPath> <DefineConstants>DEBUG;TRACE</DefineConstants> <ErrorReport>prompt</ErrorReport> <WarningLevel>4</WarningLevel> <Prefer32Bit>false</Prefer32Bit> </PropertyGroup> <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' "> <DebugType>pdbonly</DebugType> <Optimize>true</Optimize> <OutputPath>bin\Release\</OutputPath> <DefineConstants>TRACE</DefineConstants> <ErrorReport>prompt</ErrorReport> <WarningLevel>4</WarningLevel> <Prefer32Bit>false</Prefer32Bit> </PropertyGroup> <ItemGroup> <Compile Include="ComponentRWTorqueControl.cs" /> <Compile Include="ComponentSASAttitude.cs" /> <Compile Include="ComponentBase.cs" /> <Compile Include="ComponentSASAutopilot.cs" /> <Compile Include="GameEventsMandatoryRCS.cs" /> <Compile Include="Lib\VesselPhysics.cs" /> <Compile Include="UI\NavBallUI.cs" /> <Compile Include="Settings.cs" /> <Compile Include="Lib\MathExtensions.cs" /> <Compile Include="Lib\Vector6.cs" /> <Compile Include="ModuleTorqueController.cs" /> <Compile Include="Properties\AssemblyInfo.cs" /> <Compile Include="ComponentPersistantRotation.cs" /> <Compile Include="UI\UILib.cs" /> <Compile Include="UI\UIObjects.cs" /> <Compile Include="UI\UISprites.cs" /> <Compile Include="VesselModuleMandatoryRCS.cs" /> </ItemGroup> <ItemGroup> <Reference Include="System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089, processorArchitecture=MSIL" /> <Reference Include="System.Xml"> <Private>False</Private> </Reference> <Reference Include="System.Xml.Linq"> <Private>False</Private> </Reference> <!-- KSP Dlls --> <Reference Include="$(KSPDllPath)\KSP_x64_Data\Managed\Assembly-CSharp.dll"> <Private>False</Private> </Reference> <Reference Include="$(KSPDllPath)\KSP_x64_Data\Managed\Assembly-CSharp-firstpass.dll"> <Private>False</Private> </Reference> <!-- load all UnityEngine Dlls (since 1.8 we only need those) --> <Reference Include="$(KSPDllPath)\KSP_x64_Data\Managed\UnityEngine*.dll"> <Private>False</Private> </Reference> </ItemGroup> <ItemGroup> <Content Include="TODO.txt" /> </ItemGroup> <Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" /> <PropertyGroup> <PostBuildEvent> </PostBuildEvent> </PropertyGroup> <!-- To modify your build process, add your task inside one of the targets below and uncomment it. Other similar extension points exist, see Microsoft.Common.targets. <Target Name="BeforeBuild"> </Target> <Target Name="AfterBuild"> </Target> --> </Project> Note that in the debug configuration, I'm using <DebugType>portable</DebugType>. That will allow using the generated *.pdb debug symbols file with the unity debugger for VS (just put the *.pdb file next to your *.dll file in your mod folder) Also, the KSP console is the unity console. Maybe "print" is redirected there, never tried, I've never seen it used anywhere.

As far as I know the syntax is To print something in the unity console you need to use the "Debug.Log()" method. Also, I really suggest using the wildcard syntax I posted to load all unity dlls, otherwise you will struggle finding the right ones for the various unity methods you will need.

Not sure if that's the issue here, but on mac you should be using the full .net framework provided by Mono, not .Net standard : https://www.mono-project.com/download/stable/#download-mac For the target framework. It's either "v3.5" for KSP 1.7 and below or "v4.0" (or latter "v4.x" versions) for 1.8 Also, on Mac (or all platforms on KSP 1.8+), there should be a bunch of additional "UnityEngineXXX.dll" that you need to reference. See that post :

I don't see how this can be related, but you should definitely not have a method called Start(), it's one of the "message" hardcoded methods called by unity for all MonoBehaviour-derived classes (PartModule is derived from MonoBehaviour). See https://docs.unity3d.com/ScriptReference/MonoBehaviour.html

Seems alright to me. Temperature in is Kelvin, 300°K = 27°C = 80°F. Also, regarding Nerteas mods compatibility, the known issues are : - Dynamic Battery Storage will likely cause issues with the Kerbalism resource system, and the "planner" part won't work correctly. The plugin can safely be removed. - Near Future Electrical capacitors won't work in the background - Near Future Electrical reactors are dumbed down to basic uranium > EC converters with zero additional constraints, so they are very OP. - As far as I know, the Cryotanks plugin for hydrogen boiloff is working fine (but I haven't checked that in a while) - All other Nertea's mods (NFSolar/NFSpacecraft/NFConstruction/NFLaunchVehicules/SSPX) are fully supported, even tough the a few things could be better balanced. I have some plans for full support for NFE, alongside with heat management and improvements to the kerbalism converters / resource system. No ETA on that.

Dynamic Battery Storage ISN'T a dependency of anything (neither Near Future Electrical nor CryoTanks/CryoEngines), despite the CKAN metadata saying so.

I confirm an issue with NF Construction 1.2, causing a B9PS tank type to be missing and consequently a B9PS fatal error : [ERR 21:26:53.408] pass specifier detected on insert node (not a patch): NearFutureConstruction/Patches/NFConstructionFuelTankTypes/B9_TANK_TYPE:NEEDS[CommunityResourcePack&!CryoTanks]:FOR[NearFutureConstruction] [ERR 21:26:53.408] pass specifier detected on insert node (not a patch): NearFutureConstruction/Patches/NFConstructionFuelTankTypes/B9_TANK_TYPE:NEEDS[CommunityResourcePack&!CryoTanks]:FOR[NearFutureConstruction] [ERR 21:26:53.408] pass specifier detected on insert node (not a patch): NearFutureConstruction/Patches/NFConstructionFuelTankTypes/B9_TANK_TYPE:NEEDS[CommunityResourcePack]:FOR[NearFutureConstruction] [ERR 21:26:53.408] pass specifier detected on insert node (not a patch): NearFutureConstruction/Patches/NFConstructionFuelTankTypes/B9_TANK_TYPE:NEEDS[CommunityResourcePack]:FOR[NearFutureConstruction]

I usually give that example : Each CMR on the ISS is roughly 1.2 meter wide, weight about 280 kg (source) and provide only 0.258 kNm of torque (source). Compare that to the 0.625m KSP small reaction wheel : 50 kg, 5.0 kNm of torque. In short, KSP reaction wheels are about 100x too powerful. They are used for precise and extremely slow attitude keeping. Never for maneuvers like we use them in KSP.

Urgh... guys, pdb2mdb isn't needed anymore. Since 1.8, we have finally emerged from the dark ages of mono. Just change your *.csproj to generate "portable" debug symbols instead of the old and depreciated "full" format. The generated *.pdb file will be usable without any conversion using the Unity debugger for VS (and extra bonus, it should work on the VS for mac / monodevelop unity debugger plugin on OSX/linux) Either edit directly your *.csproj and change : <DebugType>full</DebugType> to : <DebugType>portable</DebugType> or in VS, go to your "project properties" > "Build" tab > "Advanced" button > "Debugging information" > "Portable" :

That's a KSP bug (fixed in 1.8) That menu will be used in the future for other things than science. This can't be done easily, we already had to resort to some hacks to hide the experiments themselves.

@SlashTen There was definitely some issues with solar panels in v3.0.x, although having issues while in sun orbit is quite strange. Anyway, solar power handling has been completely rewritten since, dev builds are available here : https://github.com/Kerbalism/DevBuilds/releases I highly suggest to use them instead of 3.0.2, they contain a lot of bug fixes and many nice improvements. The latest ones are quite stable, we might release an official 3.1 update soon.

Regarding Unity references, the easy solution is to edit your *.csproj file and use a wildcard search instead of specific references : <ItemGroup> <Reference Include="Path\To\The\Dlls\UnityEngine*.dll"> <Private>False</Private> </Reference> </ItemGroup>