ShotgunNinja

I finalized the pressure system. Some simplification was necessary at the end (most notably: no airlocks), but I'm satisfied with the result. Habitat Some parts, including all crewable ones, have an Habitat module. This module calculate volume and surface of the part (can be overridden in config node). These values are then used to add capacity for Shielding (from surface), Atmosphere (from volume) and WasteAtmosphere (again from volume). Atmosphere and WasteAtmosphere These are two hidden pseudo-resources used internally by the pressure system. You don't see them, you don't tweak them. They are an implementation detail. Processes A process is like a ModuleResourceConverter, but operate very fast at the vessel level (while still being controlled per-part). They are not specific for the pressure system, but some processes are used by it so that's why I mention them here. Pressure Control This is a process that consume Nitrogen and produce Atmosphere. The end result is that it maintain pressure at 1 atmosphere, when active and if it has enough capacity to do it. Leaks This is another process, that can't be turned off or controlled by the user. It consume Atmosphere in proportion to the vessel surface. The end result is that atmosphere slowly leak out of the vessel. Breathing This is the old oxygen-related rule. For each kerbal, it consume Oxygen and produce WasteAtmosphere. In some experiments it was consuming Atmosphere (that was produced by Oxygen and not Nitrogen) but now it is back at consuming Oxygen directly and the reason is that pressure is optional: more on this later. Scrubber The scrubber is another process that consume WasteAtmosphere and produce CarbonDioxide (that is dumped overboard with no storage capacity). The end result is that WasteAtmosphere slowly accumulate unless there is a scrubber active and with enough capacity. The effect of no pressurization Pressurization is optional in a vessel: without it, Kerbals just use their suits. This has a big effect on quality of life. So to summarize: pressurization is not required for the Kerbals to breath, but it is pretty much required if you want to keep them out there for more than a month. The effect of no scrubbing Scrubbing instead is not optional at all. If the WasteAtmosphere level reach 4% they will be breathing co2 and dying shortly afterward. In the planner All of this is exposed in the planner, and can to a large extend be controlled in the VAB. There is a new 'habitat' panel and the 'quality of life' one include some details on the effect of pressurization. Inflatable habitats An 'inflate' animation can be specified and will be driven by the part pressure automatically. So to inflate an habitat you now need pressure control and nitrogen. Unfortunately I don't have any inflatable hab parts, but it is trivial to make patches for the ones that are around. Enabling/Disabling habitats Habitats can be disabled (if not manned) and re-enabled. Transfering a crew inside a disabled hab will automatically re-enable it. This also work in the VAB. You disable habitats to choose a subset of the vessel to be active in regards to shielding, living space and pressure calculations. For pressure, disabling an habitat will vent the atmosphere out (to the rest of the vessel) and enabling it will equalize the pressure with the rest of the vessel before enabling it. It sound complex but the user is just clicking one button and all the rest happen automatically. I'm sure I forgot something, but this is all for now.

Some questions for people with the ' no-EC-burn-death-timewarp bug', as it has been called. Please answer all the questions or else it will be useless. are you using the BackgroundProcessing mod? does the vessel have Labs? does the vessel have fixed panels? are there EC consumers/producers provided by other mods on the vessel in question? is the log being spammed by exceptions when the vessel is unloaded? press ALT+F2 to see the log in-game, exceptions are red

@bpilgrim That may be it actually. At high timewarp the fixed panel exposure is evalued a limited number of times per-orbit (eg: one) and by chance it is evalued when the clamped dot product between sun direction and panel normal is zero. It is very similar to the sun visibility problem that I solved simulating it analytically over the whole orbit. However this one will not be trivial to solve I'm afraid. I'll think of something.

@Schtiebuu I did most of the hard coding. Need to finalize how the user interact with pressure and the habitats. I refactored the rule system and how profiles are specified. Also I finally managed to made the configure module re-configurable in flight, and that made trivial to implement wet workshops so I'm also experimenting with them. Then after much pain I surrendered and implemented my own harvester module, for both drills and atmospheric harvesting. And the planner had to be extended to deal with all of this. Then found out about the stock 'extension interfaces' for modules and started using them, and adding some of my own, for a general polish of all modules code. I will say with some realism that I'm halfway done overall. Thanks for the offer, I will need some brave testers after I get to the point of rebalancing and hunting the last bugs. I'll post it here once it is ready.

It does consider rotation for the fixed panels, but the orientable ones are assumed to be always facing the sun.

That's good thinking but I already switch to determining sunlight exposition analytically for the whole orbit if there are less than 16 samples per-orbit. So lets say that particular orbit has a sunlight exposure of 70%, when the timewarp is high enough so that the sun visibility is evalued less than 16 times per-orbit, then the vessel is assumed to be always in sunlight, but with 70% intensity. But what you describe seem like my fix is not working as expected. Can you provide more details: on what body and at what altitude your vessel is when the problem manifest, what are the ec consumers/producers on the vessel in question, and how many vessels you have in total?

@morigenos You are missing CommunityResourcePack.

@John Nowak You got it perfectly, that's the intended usage. Also it could be used when you have a big station/base and you want to disable some of the habitat parts to not waste resources, as now there is oxygen leaking based on surface of enabled habitats and climate control cost is proportional to internal volume of enabled habitats. To avoid clicking on all habitats and disabling them individually, you could use a script in the automation system maybe. I'll make the habitats controllable by script. Anyway I'm open to suggestion if you or anybody else has some ideas on how to improve this conceptually.

In current version, shielding and quality-of-life factors are calculated for each internal space. If you are using CLS, this mean each contiguous set of habitable parts (as determined by CLS) has its own factors. If you don't use CLS, then these factors are calculated for the whole vessel. In the new version, the above has been replaced by 'habitats' modules, that can be enabled/disabled individually even in flight. The shielding and quality-of-life factors are simply calculated for all non-disabled habitats. This was necessary for the new pressurization system, and I believe it will be more intuitive for the user.

@The-Doctor Technically the sabatier process produce methane, however as a compromise I'm going to have it output LiquidFuel. The alternative is to go all the way and use realistic fuels, but that's a lot of work better done in other mods. So LiquidFuel represent Kerosene/Methane, Oxidizer is Hydrogen Peroxide, and Monoprop is Hydrazine. That's a necessary simplification. Pods can include a small Solid Oxide Electrolyzer, after the necessary tech has been discovered. But this has an efficiency less than 100%, so that the player need to look into other ways to produce oxygen from other available sources. There will be processes to produce it from water, from ore or from atmospheric carbon dioxide. I'll do some infographic on all the available processes for the next week. @bradleyjh The supply resource containers will be configurable in the VAB.

Ok guys good news and bad news. Good news #1: support for arbitrary complex resource chains Kerbalism has a 'resource cache' that is used to deal with resources, both for loaded and unloaded vessels. It has been developed not only for performance, but to resolve all issues with consumption/production at high warp speeds. And it worked well. One of the thing that were required to make it happen was to have 'atomic recipes' of resource transformation. However order matter, and is not trivial to solve dependencies because there are loops in the resource transformations. Up until now the order of some processes was hard-coded: this worked in most cases, but it was possible to fabricate some problematic sets of producers/consumers that would break it to some extent. That was always a temporary solution, in fact, and the last 'hint' that the time was ripe for me to actually solve the problem came today when, dealing with the new pressurization system (and after my sixth espresso), I realized that hard-coded order was not possible because the correct order is dynamic based on resource levels, in that specific case. So the actual good news: I found a simple algorithm to deal with order automatically and dynamically. It can digest messy chains like this, and it just work in all cases (tm). Good news #2: fast simulation of massive numbers of converters This one is even more complex to explain. The problem encountered was that, with the new converter-galore, I was simulating a ton of ModuleResourceConverters in background, and there were a ton of them in general. And ModuleResourceConverter is not exactly lightweight. It does a lot of things, all of them useless to me. So in a single stroke I found an elegant way to just get rid of it once and forever and to finally scale to huge numbers of converters simulated at once, both on loaded and unloaded vessels. The way it work: there is an hidden pseudo-resource defining the 'capability' of some part to execute a resource conversion. Then, elsewhere, there is a definition of that resource convertion process. Finally there is a token module used to 'start/stop' that process but in reality it just set the flow to true/false (just like that little arrow icon next to a resource indicator). In code then I merely check the amount of the pseudo-resource and run the process at most once per-vessel, irregardless of the number of actual converters the user see. This work transparently for unloaded vessels too. Example: Bad news: way behind schedule I vastly underestimated the changes that were required for the new features, and how long it took to design them. In addition free time is very scarce at the moment (that's an understatement), and KSP 1.2 is changing a lot of stuff. So the next release could be one or two months from now, perhaps. Who really knows. If you are waiting, make yourself comfortable. I prefer to do this right, at my own pace, instead of rushing an half finished 'product'.

@inigma In the planner there is a 'radiation' panel. Click on the body name and situation until it match your mission plan (eg: Mun, Landed). Now the radiation panel show you some useful info. Hover on it to see even more info in the tooltip.

@JeffreyCor That RTG is on the todo list already, but I have lots of things to do still so it will probably remain on that list for a while. @SiCaRiO31 No, this mod only require line of sight with the home body and not specifically with KSC. @Benji13 Well I think the gravity ring is fine graphically. It does spin, consume electric charge and provide comfort to the crew when active. @Senior Slaphead That is a known bug in KSP 1.1.3, not related with Kerbalism: it also happen in unmodded stock. Found it myself after another similar report. Essentially stock doesn't detect the celestial body as occluder in some circumstances, that seem to be related to low altitudes. That's why it is happening on minmus flatlands. There are some chances it is fixed in KSP 1.2. Thanks, you are right I was able to reproduce it. Will fix in next version.

I had some spare time today and refactored the quality of life mechanics. Now there are two modifiers in the rule system that replace the old 'qol' one: 'living_space' and 'comfort'. Both have values that can go from 1 to 10. The 'stress' rule in the default profile use both of them at the same time, so that the time to instability can scale quite a bit from a cramped, zero-comfort vessel to one with generous living space and plenty of comforts. The living space factor is determined by volume per-capita on the vessel, versus an 'ideal' living space that can be configured in settings (in cubic meters). For the comforts instead, there are a set of them and their contribution can be specified in settings. These are provided or not depending on some vessel condition (not much changed here): firm-ground: if vessel is landed not-alone: if crew is 2 or more call-home: if the vessel has a link home panorama: no conditions The thing that changed is that there is a Comfort module (that somehow replace the old Entertainment one) that can provide one of these comforts even if the conditions don't apply to the vessel. So this module specify a string, not a value, and is easier to balance the whole thing. The gravity ring now provide the 'firm-ground' comfort (so it is useless on the surface). The cupola provide the 'panorama' one instead. That's all for today.

@seeingeyegod You need to provide log/savegame/etc, or I can't determine what's wrong.

@Jimbodiah It should be in the last build 1517, according to the dev notes. They added 'wheels', 'thermal stuff', 'electrics' and 'antennas' categories.

@3ngin33r Thanks. Technically mods that scale parts and change things like resource capacity, or even type of resource stored, should not be a problem. The planner will see the new resource immediately. Even if a mod change these things in flight my system should just see the new capacity and work from there. For background simulation, if a resource producer/consumer is not supported then it is not simulated in background. The consequences of this vary depending on the module in question, I guess. Example: you build a vessel around a non-supported nuclear reactor, and it get not enough EC generated when not loaded. As far as I know the signal system work flawlessly, so you should not see weird issues at all. All the modules have their properties documented here. Also take a look at the patches already distributed with the mod as an example. If you end up writing a patch that you want to contribute, post it here (or send me a PR on github) and chances are good I'll integrate it in the next version.

@JadeOfMaar This is a total eyeballed understanding of how the resource distribution is generated. If I'm wrong somebody will correct me I'm sure. a 'noise' map is generated, like the above one: it is a 'sum' of the same random image but with multiple scales (called octaves) the 'variance' value should regulate the weight and scale of the individual octaves: less variance will lead to more sharp features the 'dispersal' should be radius of the blur applied after the noise is generated: not in pixel, but in proportion of the width (or height) of the map the 'PresenceChance' value (in 0..1 range) is then used to 'clamp' the pixel values: those with values below '1 - PresenceChance' are set to zero all the non-zero pixel values are then mapped from [1 - PresenceChange, 1] range to [MinAbundance, MaxAbundance] range. The fact that PresenceChance appear to map to the proportion of surface with resources is only an artefact of the uniform distribution of random values: for example if PresenceChange is 0.8 then 80% (more or less) of the pixels will pass the clamping without being set to zero, leading to 80% of the surface having a value other than zero.

The Electric category is now stock, with some other useful ones. For this reason in next version I will be removing the Electric category provided with the download, that was meant to be an example more than anything. @Jimbodiah you may want to adapt the categories you authored to the stock changes.

@N70 Well, yes unfortunately. Some modules do not exist anymore, others were introduced. @evileye.x I agree 100%, that is a bit ridiculous. There are some modifications to the science system that I'm working on (for a while now...) where the 'ladder dances' should be gone for good, among other things.

Reconfiguration in flight will be added later. I agree it would be cool to have it. I'm thinking more of stuff like wet workshops and the like, however. Mesh switching is not planned. But texture switching could be added in future. The configure module is not using the stock 'part update' features because: I started developing it a month ago, and also the stock update thing can't enable/disable modules or add resources on-the-fly. One of the available reactions is 'Molten regolith electrolysis' that extract oxygen out of ore. So it should be possible to do something about oxygen on airless worlds. Self-sustaining bases however will be harder, moving toward more realistic mechanics. Yes! The gravity ring will be some kind of special case of living space (still working on porting it on the new system). Inflatable habitats may even get their 'inflated' animation controlled by the pressure directly (also still working on this). They could be implemented. The recent changes to Reliability allow multiple types of malfunction per-component, and per-part. And a pressure leak is pretty much the same as a tank leak in the new system. These kind of things can be added later, after the thing is up and running. A simpler profile could be authored, with limited life support mechanics, and people could share it here. About the difficulty settings in 1.2: I just can't use them for technical reasons, that are the same ones for which there is not a settings window to choose features. Ammonia is harvested in some celestial bodies, and also can be produced using the 'Haber process' (from Nitrogen and Hydrogen). It is then used as fertilizer in the Greenhouse. It can also be used to produce Oxidizer and Monoprop. The greenhouse will also accept Waste (as in organic crap waste) as an alternative fertilizer.

@theJesuit It is a bit more complex, but probably the way I explained it make it look even more complex than it is. You have now a volume in m^3 on the vessel and some of the things are related to it. The scrubber is scrubbing, the pressure control is something that is here but completely automatic. Managing internal spaces is gone, replaced by a much simpler system of just disabling some living space when the need arise. Then the fact that one can select multiple life-support components (adding one in a part, one in the other, etc) make for more customizable experiences for each vessel. And the planner consider all these things, as usual, to help the user. Consider that I'm trying to streamline the whole of this so I get more realistic stuff and also more interesting gameplay. For the ETA, this probably will be released as some experimental builds some time after KSP 1.2 is released. To help me iron out problems and balance stuff.

I'm going to introduce and explain some of the changes that are coming in next version. Most of this is still in development, and some are still in design phase. Configure Module This is a module that allow to select in the VAB a set of 'setups' for the part. Each setup contain modules and/or resources. This is used by some of the new things. Setups can be unlocked by technologies, have extra mass and cost. In future they will even be reconfigurable in flight by an engineer. ISRU changes The stock converters 'reactions' have been replaced with some others based on reality. I say 'based on reality' instead of 'realistic' because some of the reactions still end up producing the magical resources LiquidFuel, Oxidizer and Monoprop. This was a necessary compromise, else I would had to replace the stock fuels (and tweak the engines). That surely would have not scaled, especially with other mods. Then, the atmospheric processor experiment now also double as an atmospheric harvester. This was necessary as atmospheric ISRU is now the main source of useful raw materials. Finally, all converters, drills and atmospheric harvesters are configured in the VAB to determine what they can transform or extract. The small stuff get less selectable setups than the big one. LivingSpace module This module specify the internal volume, and the external surface, of a part that is meant to contain kerbals. Even if it has no crew capacity. It has so many features that I have to make a list to not clutter this post: the volume is used in the internal atmosphere simulation (read below) the external surface is used to determine amount of shielding required volume and surface are calculated automatically from the bounding box if not specified it has a 'comfort' property (that replace the Entertainment module) it can consume electric charge (to represent lights and other minor amenities in the habitat) it can be 'disabled', to exclude it from all calculations: this replace the 'internal spaces' mechanic that was using CLS it can have a 'deploy' animation (for inflatable habitats, or the ring) Internal atmosphere simulation The vessel internal atmosphere is now simulated using two hidden pseudo-resources. This together with the volume specified by LivingSpace make possible to calculate some data about the internal atmosphere: pressure mass level of carbon dioxide temperature This data is used from various things, and is all exposed to the rule system. I considered adding Nitrogen in the mix (that could allow to model fire hazard and oxygen toxicity), but for now it has been discarded. LSS The LifeSupportSystem module represent a more 'realistic' take on the matter of life support systems. This is still being designed, but there will be different components that can be installed in some living space parts (such as pods). These components can be selected using the 'configure module'. Here are some of the ones I'm designing: Cabin Pressurization System (CPS): inject oxygen in the internal atmosphere to maintain a target pressure Air Revitalization System (ARS) sequester carbon dioxide from the internal atmosphere and store it Temperature Control System (TCS) maintain the internal atmosphere temperature inside the survival range ec cost depend on internal atmosphere mass, OR each TCS has a limited capacity (still in design) Water Reclamation Unit (WRU) your usual waste water recycler, no filters used Solid Oxide Electrolyzer (SOE) transform carbon dioxide in oxygen Extra supplies/batteries this just provide extra storage for resources ... expect more in future... Default profile The consumption rates are now more realistic, and water consumption is added. The realism profile is removed: in a certain sense, it became the default one. So long realism profile, you will be missed. Only CRP resources are used, and there is mass conservation (when appropriate). A carbon dioxide poisoning rule is added. The climatization rule don't consume EC now, and refer to the internal atmosphere temperature instead. Greenhouse Need water, and ammonia. I have the idea of having different 'crops' that can be selected in the VAB, each one with different tradeoffs between food produced, amount of water and ammonia required, and growing time. This is still in early design phase. Probably something for a later version. Containers The old food containers can now be configured to store food, water or food/water. The old oxygen containers can be configured to store oxygen, carbon dioxide, hydrogen, nitrogen or ammonia. The stock ore tanks could also be made configurable to store different resources, so as to act as more generic containers. But wait, there is more There is another thing that I will mention another time, as it require a lot of writing on its own. Let me know what you think of the changes or if you have some ideas that may play well with them. Oh, and is pointless to say that these changes are savegame-breaking. That's one of the reasons I'm doing them all at once.

@Yaar Podshipnik The storm frequency depend on the planetary system distance from the sun. At 1 AU (so, at Kerbin distance), it vary between StormMinTime and StormMaxTime seconds, at random (both of these are in Settings.cfg). Then once it hit, it last for StormDuration seconds (also in settings).

Unrelated but... economic sustainment secured for next years.