ShotgunNinja

@Box of Stardust The crew get the radiation after shielding for the internal space he occupy, same with the quality of life factors.

@Nansuchao You can edit the profile and increase the radiation thresholds, to save them. 119x24h was too low anyway, maybe I have to increase it a bit.

@Box of Stardust, @dboi88 Radiation shielding and quality of life factors are calculated per internal space if you have CLS installed, else they are calculated for the whole vessel. With CLS, you can have an internal space with weak shielding and strong quality of life, for the long travel time. Then you can have a separed internal space with strong shielding and weak quality of life, for the times you cross the radiation belt or when a solar storm hit. I guess the best way to see how it works is to launch a vessel with multiple internal spaces and have a look at the vessel info window.

@Nansuchao Try loading the same vessel in the editor and see what the planner estimate for radiation is. If it doesn't fit with what you are seeing there may be something wrong with radiation calculations. @rkman There was a problem with performance from version 0.9.9.5 to version 0.9.9.7. Other than that, I see no perceptible slowdown at all with 20 vessels of various complexity. That being said an optimization pass is planned in the future.

@Nansuchao, @leomike The default profile is balanced against 6h day. It would make sense to create a version of it for 24h day, that is also always used by players using RSS (longer distances, etc). CLS can be useful to deal with radiation long-term, not much for cosmic radiation as you also need the living-space/entertainment to be high overall during the long trip, but more to make an 'uncomfortable but hardened' internal space to use during solar storms or when crossing a belt. As leomike pointed out, those are going to weight heavily on the lifetime radiation dose: 1h crossing the Kerbin/Earth belt equal 166 kerbin days / 41 earth days worth of cosmic space radiation. RSS Mars has no radiation belt and a small magnetic field. In reality, Mars has a very tenue and extremely irregular magnetic field. @SkyblueX Honestly, I don't know what may cause the duplication bug. I see it's a long standing bug in various mods and, more puzzling, none of them was able to fix it. It probably arise from some inter-mod interaction, maybe when 2 or more mods add a module to EVA kerbals. It could also be related to the way the stock game (or is ModuleManager?) preserve some module data even after you remove a mod. For example, I don't think IR Robotics or Deadly Reentry could possibly cause it, even if they figure out in some of the bug reports. Also KIS seem to be in all these reports, but I bet is just a statistical anomaly as it is one of the most used mods. I'll try to replicate it when I got some spare time and see if I can associate it to multiple EVA modules (my main suspect at this point).

@John Nowak Correct, it is a framework that run a set of zero or more rules. Rules can be defined inside any .cfg file in GameData. The convention I've used is to store set of rules in single .cfg files that I called 'profiles'. The ones shipped are meant to be mutually exclusive , so you should enable only one at the same time. Note that this is just a convention and you can for example create a rule of your own design, that is meant to be added to the set of rules the player is using. In that case there is no need for mutual exclusion. For your second question, biomeMask is interpreted by the game engine as a bitfield were each bit set the experiment to be biome-dependent (or not) on a specific situation. These are the bits meanings: Situation bit_index 2^bit_index SrfLanded 0 1 SrfSplashed 1 2 FlyingLow 2 4 FlyingHigh 3 8 InSpaceLow 4 16 InSpaceHigh 5 32 To combine them, just sum the 2^bit_index values together. Here are some examples: // biome-dependent when splashed (2), or high in space (32) biomeMask = 34 // biome-dependent when landed (1), splashed (2), flying low (4) or in space low (16) biomeMask = 23 @RattiRatto PBS include MM patches to work with Kerbalism, and Kerbalism simulate the PBS converters in background.

@The-Doctor Lets see... should I keep using CRP and having a lot of other mods work flawless with this one out of the box, or should I remove it so that my friend The-Doctor will avoid installing a mod that consist of just a .cfg file with the resources? I think I'll go with the former. Also, you are vastly underestimating how much work is required behind the hood to make a mod, so that you can have some fun for free. You should stop asking features after features and starting enjoying what you have.

@The-Doctor The signal system is similar to AntennaRange, with these differences: relaying must be explicitly enabled per-antenna the act of relaying consume EC, even in background the way transmission costs scale with distance is different More informations are here. If you want something more complex I suggest you disable the signal mechanic and use RemoteTech instead.

@Liondrome I know what's going on. You are right I assume a body orbit the star, or another body that orbit the star. So for the two bodies in question the system is using the wrong distances, as these were very near the sun. Will fix in next version. @Khargee In general, switching profile for an existing savegame is not recommended as resources, consumption rates and mechanics change. For example, if you start a game with the Snacks profile and then switch to Default all your existing vessels will be referencing a resource (snacks) that doesn't exist anymore. If you do the opposite switch, instead, all your Kerbals will die of oxygen deprivation. What is happening here, I'm guessing from the log, is that your existing vessels had CO2 and Crap resources that are now unknown to the game. This lead to the exceptions being thrown during mass calculation by the game engine. @The-Doctor Anything else? Persistent rotations is beyond the scope of this mod. Your idea is cool, just too complex to implement right now.

The easiest way, by far, is to go download SharpDevelop (that also include the c# compiler/assembler). Then create a new empty project and add the reference assemblies for KSP and Unity: - Assembly-CSharp - Assembly-CSharp-firstpass - KSPUtil - UnityEngine - UnityEngine.UI Then take the default .cs file the project comes with, remove all the content and put this in its place: using System; using System.Collections.Generic; using UnityEngine; namespace YourStuff { [KSPAddon(KSPAddon.Startup.MainMenu, true)] public class MyMod : MonoBehaviour { // keep it alive MyMod() { DontDestroyOnLoad(this); } // called at every simulation step public void FixedUpdate() { print("hello world"); } } public class MyPartModule : PartModule { // this is loaded from .cfg [KSPField] public float my_value; // this is an event [KSPEvent(guiActive = true, guiName = "Click me!", active = true)] public void ClickMe() { Monobehaviour.print("stop clicking me!"); } // shown on the part tooltip in editor public override string GetInfo() { return "hello world!"; } } } // YourStuff To get started with the UI, have a look at this simple, self-contained Notepad.

@LENIN_comrad Try doing this: remove the GameData/Kerbalism directory completely, then download the last version and install it. If you install using CKAN, make sure to also install Kerbalism-Profile-Default. @cheeseit The parts are unlocked with technologies... you only have unlocked the small food container. NVM saw your other post... try to reinstall as above.

@mivanit I'm using SharpDevelop but this should apply to any IDE/compiler: you need to target .NET Framework 3.5 and include the following reference assemblies, that you will find in the installation directory of KSP: Assembly-CSharp Assembly-CSharp-firstpass KSPUtil UnityEngine UnityEngine.UI Then you will also need to include this other reference assembly, that is the CLS interface dll and is included in Kerbalism download as well as the CLS dev package: CLSInterfaces

@Guest83 For the malfunctions, now I think it was a bad idea to store the lifetimes in the module. The rationale for putting them there was to make them customizable for component, but it was never used that way. And now they are hard to change between versions. They will be best in the settings.cfg I think, that may eventually get an UI at some point.

@cheeseit From the rate of malfunctions you report is possible you are running an old version, or at least the vessel in question was launched in an old version. In newer versions the malfunction rates were seriously nerfed. You can tweak the rate of malfunctions with an MM patch, like this: @PART[*]:HAS[@MODULE[Malfunction]]:FINAL { @min_lifetime *= 10.0 @max_lifetime *= 10.0 } And you can disable malfunctions altogheter by editing Profiles/Default.cfg and deleting this line: @Kerbalism:FOR[EnableMalfunction] {} Note that both solutions will not apply to existing vessels, but only to new ones. You can find some info on the wiki. For the life expectancy estimates, you will find them in the Planner (in the editors) and in the Vessel Info Window (in flight).

@Box of Stardust Ok then, I'm adding the setting in next version. I through you wanted loss of control only in the case a vessel goes out of range... middle of the night here man

@Box of Stardust It isn't possible right now. And is not easy to add it, due to the way the signal system architecture was designed. But I could add a flag in settings to disable the loss of control altogheter. Will that be enough?

@Kethevin They should work together to some extent, but my ISRU background simulation is simplified and may lead to different behaviour between loaded and unloaded vessels. If you try, let me know.

@cubinator You can disable messages, and stopwarp, per-vessel for all types of events. Left click on a vessel in the monitor ui. Note this screenshot is a bit obsolete

New release, 0.9.9.9 Changelog - science lab EC consumption is simulated in background - science labs EC cost tweaked - fix: ui offsets respect scaling - fix: removed signal lock exploit for unmanned debris - fix: missing data in part prefabs will no longer break background simulation - fix: problem with vessel info and resource names being used instead of rule names

@Box of Stardust Yes, controlling an unmanned vessel require line-of-sight with the home body, directly or indirectly. However, now you can disable the signal mechanic if you want. Edit the file profiles/default.cfg and delete this line @Kerbalism:FOR[EnableSignal] {}

@brusura Missed those options altogether... will fix for next version.

@brusura I tried scaling the UI, but the applauncher doesn't seem to scale with the rest:

@Nansuchao Well, that was an easy one to fix

@DarkonZ, @crapstar Dang, it was a bug from a couple versions ago that went un-noticed until now, it only happen when some rule names are different than the resource name. I'll release a new version in a few days, for now replace the dll with this one.

@BashGordon33 The magnetosphere parameters are generated using dark magic, so any body added by any mod pack should just work. @DarkonZ Thanks, will check what is going on