Sir Mortimer

Are you sure you got the latest SSPX release? That sounds like an issue that has been fixed (missing closing curly braces in 2 files)

Sandbag integration in Kerbalism: requires a Kerbal to deploy, and effectively reduces the radiation in the habitat.

This doesn't look healthy. This doesn't look healthy at all. In that log file, I see KerbalismBootstrap v1.0.0.0 KerbalismBootstrap v3.2.7288.28872 / v3.2 Which lets me believe that you might have a mixture of different Kerbalism versions installed at the same time. Note the different paths inside your GameData folder: [LOG 21:09:38.206] AssemblyLoader: Loading assembly at F:\KSP\Kerbal Space Program 1_7_3\GameData\KAS\Kerbalism\Kerbalism17.kbin [LOG 21:09:38.248] AssemblyLoader: Loading assembly at F:\KSP\Kerbal Space Program 1_7_3\GameData\Kerbalism\Kerbalism17.kbin To me it looks like you have Kerbalism inside GameData/Kerbalism and GameData/KAS/Kerbalism. The latter one is a desaster and recipe for catastrophic failures, things go very sideways from there on. Next steps: delete GameData/KAS/Kerbalism*, and just for good measure, also delete GameData/Kerbalism* and then copy a fresh version of the Kerbalism and KerbalismConfig folders from the releases.

I can't make plans or promises for things of which I know nothing but 3 youtube videos. Besides, there isn't even an approximate release date for KSP2 yet, and even if there is, there isn't one for a mac version. Which, for me personally, is a non-negotiable requirement before I even can start looking at the game. Then I don't know if it will even run on my rig. I guess by the time I get there, others will have started a new life support mod. Maybe even a successor for Kerablism, who knows.

The latter, unfortunately. However, there are plans for a mod extension to Kerbalism that will keep track of which radiation belts have been discovered/researched and only show those that are.

Yup, it's a Kerbalism thing. See there → https://forum.kerbalspaceprogram.com/index.php?/topic/190382-150-181-kerbalism-32/

Continuation of this thread:

Welcome to Kerbalism Hundreds of Kerbals were killed in the making of this mod. Kerbalism is a mod for Kerbal Space Program that alters the game to add life support, radiation, failures and an entirely new way of doing science. Go beyond the routine of orbital mechanics and experience the full set of engineering challenges that space has to offer. All mechanics can be configured to some degree, or even disabled if you don't like some of them. A big part of the mod is fully data-driven, so that you can create your own customized game play with only a text editor and a minimal amount of espresso. Or simply use a set of rules shared by other users. Frequently Asked Questions: FAQ Current version: 3.11 What's new: New and Noteworthy Download: Github - SpaceDock - CKAN Docs & support: Github wiki - Discord - Github issues License: Unlicense (unless stated otherwise, parts might be licensed differently) KSP version: 1.5.x - 1.10.x Requires: Module Manager, CommunityResourcePack See also: Mod compatibility - Change Log - Dev Builds Download and installation Download on Github releases or use CKAN Two packages are available: Kerbalism is the core plugin, always required. KerbalismConfig is the default configuration pack. It can be be replaced by other packs distributed elsewhere. Requirements - Module Manager: must be installed in GameData - CommunityResourcePack: must be installed in GameData Third-party configuration packs Make sure to install exactly one configuration pack only. Don't combine packs unless there is explicit instructions to do so. - ROKerbalism for Realism Overhaul / RP-1 by standecco - SIMPLEX Living by theJesuit - KerbalismScienceOnly for Kerbalism with the science feature only Installation checklist for the "GameData" folder required content : - CommunityResourcePack (folder) - Kerbalism (folder) - KerbalismConfig (folder, can be replaced by a third-party config pack) - ModuleManager.X.X.X.dll (file) Mod compatibility and support Checking the mod compatibility page is mandatory before installing Kerbalism on a heavily modded game. Kerbalism does very custom stuff. This can break other mods. For a lot of mods that breaks or need balancing, we provide support code and configuration patches. However some mods are incompatible because there is too much feature overlap or support is too complex to implement. Documentation, help and bug-reporting - Tutorials and documentation are available at the Github wiki - Need help? Ask on Discord or in the KSP forums thread - You found a bug? - Maybe it's related to another mod ? Check the Mod Compatibility page. - Maybe it's a known issue ? Check the GitHub issues and ask on Discord. - You want to report a bug? - Reproduce it consistently, provide us with screenshots and the KSP.log, modulemanager.configcache and persistent.sfs files. - Report it on Github issues (preferred) or in the KSP forums thread. - You want to contribute or add support for your mod? - Check the technical guide on the wiki - Pull requests are welcome, especially for mod support configs. For code contributions, it is recommended to talk to us on Discord before engaging anything. - Read the contributing documentation - To build the plugin from the source code, read the BuildSystem documentation Disclaimer and license This mod is released under the Unlicense, which mean it's in the public domain. Some parts are released under a different license, please refer to their respective LICENSE files. It includes MiniAVC. If you opt-in, it will use the Internet to check whether there is a new version available. Data is only read from the Internet and no personal information is sent. For more control, download the full KSP-AVC Plugin. What does it do? Kerbalism is a mod for Kerbal Space Program that alters the game to add life support, radiation, failures and an entirely new way of doing science. Go beyond the routine of orbital mechanics and experience the full set of engineering challenges that space has to offer. All mechanics can be configured to some degree, or even disabled if you don't like some of them. A big part of the mod is fully data-driven, so that you can create your own customized game play with only a text editor and a minimal amount of espresso. Or simply use a set of rules shared by other users. All vessels, all the time Contrary to popular belief, the observable universe is not a sphere of a 3km radius centered around the active vessel. All mechanics are simulated for loaded and unloaded vessels alike, without exception. Acceptable performance was obtained by a mix of smart approximations and common sense. The performance impact on the game is by and large independent from the number of vessels. Resources This isn't your classic post-facto resource simulation. Consumption and production work is coherent regardless of warp speed or storage capacity. Complex chains of transformations that you build for long-term life support or mining bases just work. Environment The environment of space is modeled in a simple yet effective way. Temperature is calculated using the direct solar flux, the indirect solar flux bouncing off from celestial bodies, and the radiative infrared cooling off their surfaces. The simulation of the latter is especially interesting and able to reproduce good results for worlds with and without atmosphere. Radiation is implemented using an overlapping hierarchy of 3D zones, modeled and rendered using signed distance fields. These are used to simulate inner and outer belts, magnetosphere and even the heliopause. Solar weather is represented by Coronal Mass Ejection events, that happen sporadically, increase radiation and cause communication blackouts. Habitats The habitats of vessels are modeled in terms of internal volume, external surface, and a set of dedicated pseudo resources. These elements are then used to calculate such things as: living space per-capita, the pressure, CO2 and humidity levels of the internal atmosphere, and radiation shielding. Individual habitats can be enabled or disabled, in the editor and in flight, to reconfigure the internal space and everything associated with it during the mission. Inflatable habitats are driven directly by the part pressure. Life support Your crew need a constant intake of Food, Water and Oxygen. Failure to provide for these needs will result in unceremonious death. Configurable supply containers are provided. Kerbals evolved in particular conditions of temperature, and at a very low level of radiation. You should reproduce these conditions wherever your crew go, no matter the external temperature or radiation at that point. Or else death ensues. The vessel habitat can be climatized at the expense of ElectricCharge. Environment radiation can be shielded by applying material layers to the hull, with obvious longevity vs mass trade off. Psychological needs The era of tin can interplanetary travel is over. Your crew need some living space, however minimal. Failure to provide enough living space will result in unforeseen events in the vessel, the kind that happen when operators lose concentration. While not fatal directly, they often lead to fatal consequences later on. Some basic comforts can be provided to delay the inevitable mental breakdown. Nothing fancy, just things like windows to look out, antennas to call back home, or gravity rings to generate artificial gravity. Finally, recent research points out that living in a pressurized environment is vastly superior to living in a suit. So bring some Nitrogen to compensate for leaks and keep the internal atmosphere at an acceptable pressure. ECLSS, ISRU A set of ECLSS components is available for installation in any pod. The scrubber for example, that must be used to keep the level of CO2 in the internal atmosphere below a threshold. Or the pressure control system, that can be used to maintain a comfortable atmospheric pressure inside the vessel. In general, if you ever heard of some kind of apparatus used by space agencies to keep the crew alive, you will find it in this mod. The stock ISRU converters can host a set of reality-inspired chemical processes. The emerging chains provide a flexible and at the same time challenging system to keep your crew alive. The stock ISRU harvesters functionality has been replaced with an equivalent one that is easier to plan against, as it is now vital for long-term manned missions. The means to harvest from atmospheres and oceans is also present, given the importance of atmospheric resources in this regard. No life-support like mod would be complete without a greenhouse of some kind. The one included in this mod has a relatively complete set of input resources and by-products, and some more unique characteristics like a lamp that adapts consumption to natural lighting, emergency harvesting, pressure requirements and radiation tolerance. A planetary resource distribution that mimics the real solar system completes the package. Reliability Components don't last forever in the real world. This is modeled by a simple system that can trigger failures on arbitrary modules. Manufacturing quality can be chosen in the editor, per-component, and improve the MTBF but also requires extra cost and mass. The crew can inspect and repair malfunctioned components. Redundancy now becomes a key aspect of the design phase. Engines have their own failure system: limited ignitions, limited burn duration, and an overall ignition failure probability will even make your 100th moon landing feel like an achievement! Science Experiments don't return their science output instantly, they require some time to run. Some complete in minutes, others will take months. Not to worry, experiments can run on vessels in the background, you don't have to keep that vessel loaded. There are two different kinds of experiments: sensor readings and samples. Sensor readings are just plain data that can be transferred between vessels without extra vehicular activities, they also can be transmitted back directly. Samples however require the delicate handling by kerbals, and cannot be transmitted but have to be recovered instead. They also can be analyzed in a lab, which converts it to data that can be transmitted. Analyzing takes a long time, happens transparently to loaded and unloaded vessels alike, and can't be cheated to create science out of thin air. An interesting method is used to bridge existing stock and third-party experiments to the new science system, that works for most experiments without requiring ad-hoc support. Transmission rates are realistic, and scale with distance to the point that it may take a long time to transmit data from the outer solar system. Data transmission happens transparently in loaded and unloaded vessels. The resulting communication system is simple, yet it also results in more realistic vessel and mission designs. Automation Components can be automated using a minimalist scripting system, with a graphical editor. Scripts are triggered manually or by environmental conditions. You can create a script to turn on all the lights as soon as the Sun is not visible anymore, or retract all solar panels as soon as you enter an atmosphere etc. User Interface Kerbalism has a nice user interface. A planner UI is available in the editor, to help the user design around all the new mechanics introduced. The planner analysis include resource estimates, habitat informations, redundancy analysis, connectivity simulation, multi-environment radiation details and more. To monitor the status of vessels, the monitor UI is also provided. This looks like a simple list of vessels at first, but just click on it to discover an ingenuous little organizer that allow to watch vessel telemetry, control components, create scripts, manage your science data including transmission and analysis, and configure the alerts per-vessel. Modules Emulation Most stock modules and some third-party ones are emulated for what concerns the mechanics introduced by the mod. The level of support depends on the specific module, and may include: simulation of resource consumption and production in unloaded vessels, fixing of timewarp issues in loaded vessels, the ability to disable the module after malfunctions, and also the means to start and stop the module in an automation script. For Modders Kerbalism has a lot of interfaces ready for other mods to use. If you are a mod developer and want Kerbalism to play nice with your mod, please see the wiki or contact us on discord. Legalese

Q: I can't transfer samples from one part to another, why? A: Samples are physical things, you need a Kerbal to transfer them between parts (EVA or crew on board). However, there is a difficulty setting to Always allow sample transfers even on unscrewed vessels. (Kerbalism FAQ, verse 5)

DynamicBatteryStorage is not, and never will be, compatible with Kerbalism (see below). There is a change in the works that will essentially disable DBS if Kerbalism is installed. However, you can use Near Future Electrical without dynamic battery storage being installed. I know CKAN says it is a dependency, but it really is not. That said, there are some parts in NFE that currently are a bit problematic: capacitors won't work as expected for unloaded vessels, and reactors don't produce any heat and thus are very OP. But those issues have nothing to do with DBS. The reason for the incompaitibility is this: 1. DBS dynamically changes the battery storage capacity of a vessel during time warp, this is a workaround for the stock KSP resource system that doesn't do very well in that situation. However, Kerbalism uses its own resource system that, while synced with the stock system, does not expect a vessel to magically shrink or grow storage capacities. Just by doing that, dynamic battery storage could kill Kerbals because it confuses the Kerbalism resource framework. 2. DBS comes with a cool UI that you can use to determine the power status of your vessel in the editor. You can see what uses EC and how much, how much EC is generated by panels and such, you can tweak your distance to the sun and other things. And there is a heat management system too, mainly for the NFE reactors I suppose. But that UI only works for part modules that dynamic battery storage knows how to handle, so it works for the stock game and a few mods only. Kerablisms part modules don't appear in that UI, so the readout would be wrong. But what's more, Kerbalism has its own planner that you can use for that. It will tell you if you're going to run out of power or not, or how long any of the resources will last that you need to operate your vessel. So not only is the DBS UI incomplete with Kerbalism, it also is redundant - which is why it won't be fixed.

Do you have B9PartSwitch installed? Texture switching only works if you're got that

No, it quite explicitly sates "no ground contact", which is checked by Kerbalism using a method that apparently no longer works correctly. Might be related to something that changed in KSP during the recent versions. I'll remove that check until we have something better, and assume that a harvester always has ground contact if the vessel is landed. Expect a new dev build tonight.

OK; looked at the code: there might be a case where KSP behaves oddly, I added a check for that. I'll upload a test build tonight (=in ~12 hours, if life permits), could you test it with that one then?

Does it work when you move around a bit?

The Kottaboos review is so old that you could say it's for a different mod. A *LOT* has changed since then. Unfortunately we don't have much more than what is on the wiki, but there are a few YouTubers who currently have a series on Kerbalism (f.i. sthedgehog or Mike Aben).

Mike Aben currently has a youtube series (search his name in YT, you'll find it) where he uses exactly this kind of setup.

That info might be from a time from before the new engine failure system. Kerbalism recently introduced ignition failures and engine failures based on engine operation duration, which means that engines can fail fare more often than they used to. To... ahem: compensate for that, most engines can be repaired by any kerbal. There are however some that require special skills. If I remember correctly, a NERV requires an engineer, and ion thrusters require a scientist - but that might have changed again and I forgot about it.

You're way ahead of me, I've never gotten to the point where I can put a mining station anywhere but right besides the launch pad You can get CO2 from Ore, see here. There also is a chart with all processes that exist in Kerbalism at the top of that page.

Just to be sure: you did update to version 3.1, right? If so, I think it would be best to troubleshoot this on Discord

There is no explicit configuration for BDB, which means Kerbalism will run on some rough estimates regarding volume and surface of crewed parts. But it will work, maybe some numbers aren’t realistic but that won’t be game breaking. I recall someone having the same issue with CO2 scrubbers, but don’t remember what was causing it. Probably a mod conflict, I think they also had TAC LS installed.

Deleted

Kerbalism isn’t doing anything to commnet.

How about this: Added slider in preferences to tweak engine burn failures Ignition failure preset is now reduced, but the very first ignition on the launch pad has a higher failure probability Engine failure probability due to burn duration failures lowered a bit

The compatibility between mods did not change with 1.8.1, but it might be that some of the mods on that list don't yet support KSP 1.8. Whoops, thanks for that - fixed the link! (go there -> https://github.com/Kerbalism/Kerbalism/tree/master/GameData/KerbalismConfig/Support) Nah that's perfect, thanks. I'd like to have values that work for the game: failures should not be the first and foremost consideration, but bite you occasionally - just enough to be a constant reminder that they can and will happen. The 10th landing on mun should still feel like a small achievement, instead of routine. And one should have at least a bad feeling when launching a crewed rocket without considering the possibility of a booster ignition failure. The burn duration failure rate is probably a bit too agressive right now, and I'm thinking about lowering the possibility of an ignition failure on subsequent ignitions (relatively high probability on very first ignition, lower on ignitions after that).

Nope. Radiation damage only affects solar panels, transmitters and RCS wheels (not thrusters). Engines are immune to radiation. Unless, of course, you change the config files. Engines are guaranteed to get 35% of the rated burn duration without a failure to material fatigue, and after that the probability of a failure raises exponentially. If my math doesn't fail me, this means that you will get, roughly rounded: 0% failures up to 35% of the rated duration 3% failures at 50% of the rated duration 20% failures at 75% of the rated duration 56% failures at 100% of the rated duration 80% failures at 110% of the rated duration 100% failures at ~117% of the rated duration So, for mission critical engines, I'd suggest you plan to burn it not longer than 50% of the duration, plan the ignitions very very conservatively and hope for the best. From what I can see based on the feedback I get the feeling that engine failures might be happening a bit too frequent. What do you think, should they be changed to be more reliable?