ShotgunNinja

@aluc24 To clarify, are you seeing this bug happening in version 1.1.5 pre1?

@AVaughan Thanks for the detailed report. No idea on this one. Maybe unrelated with this mod, albeit I am setting a 'frozen state' on EVA kerbal deaths. This is a limitation of my background consumption algorithm, that I plan to address in the near future. I was able to replicate this. Don't know how it went unnoticed from my side... @SavageAngel My pleasure And you are right, the fields not rendering must be (yet another) Nvidia/Unity issue. I will fix it in a way or another before releasing a stable version. Two things you can try right now to help me: enable Signal, launch a vessel with an antenna in LKO and check if the signal lines are rendered correctly set LowQualityRendering to true in Settings.cfg, and try to see if the radiation fields are rendered

Yes, but the latter was meant to reproduce the former. And in doing so, working when the habitat is not pressurized (so the crew is suited, but you still need to scrub the CO2 they produce). I also tried a more complex internal atmosphere model before this one: Kerbals were breathing Atmosphere directly, that was composed of Oxygen and Nitrogen (the CO2 was on another 'layer' like now). This worked, and was a bit more realistic. But it had some issues: (1) it was not intuitive for the player how the Oxygen estimate was separed from the Atmosphere and (2) kerbals were not able to breath inside a non-pressurized vessel (while in reality they would suit up). (1) I tried to solve it by improving the algorithms that deal with resources (and those efforts ended up in the new order-less chain algorithm) (2) could not be solved without some inelegant hacks in the rule system (to allow kerbals to consume either Atmosphere or Oxygen), and the efforts here evolved in the current concept that pressurization only influence quality of life (that make sense actually). An idea I had, and didn't really explore, was to simulate the Kerbals suits directly, even when they are inside a vessel.

@raxo2222 Well I had to make some simplifications in the internal atmosphere simulation: Each habitat has a capacity of WasteAtmosphere (determined by its volume, and the density of CO2 at STP) Kerbals consume Oxygen directly from the oxygen tanks (eg: it is not stored in the internal atmosphere) Kerbals however produce WasteAtmosphere (at a realistic rate, for overall mass conservation) at any moment the co2 level is the amount of WasteAtmosphere, divided by the WasteAtmosphere capacity

Hi, I have found a minor issue with the 'science boost from the home body' policy. Raised an issue here. Cheers.

All the extra profiles in the OP were made for the version you find in the OP, not the experimental one. 'None' is an empty profile, it remove everything. You can create your own profile, look at both Default.cfg and Classic.cfg to see how it is done. Some documentation is coming in a few days. The Scrubber sequester CO2 from the internal atmosphere. If then there is no storage for it, it is dumped. You can configure the pressurized tanks to store it. Similar thing for Waste. Mmm okay. I'll see what I can do. See answer to @Gotmachine below. That is because those 'science alert' mods scan the vessel for stock ScienceData, to remove the experiments you did already (but still have not recovered/transmitted). With kerbalism Science, there is no ScienceData on the vessel, so these mods will never detect that you already have the experiment results on the vessel. There is no fix for this. If the alerts are important to you, maybe it is worth to just set Science to false. Thanks for the detailed info. I am going to guess that the bigger data sizes of the experiments are making Strategia do the wrong things. But they shouldn't: what I'm doing with the data is simply to scale its size using the stock 'dataScale' property. I may have a clue why this is happening. And thanks again for the detailed report, these are useful. I was surprised too, but that is based on real data. A man breathing in a 1.5m^3 volume will cause the CO2 level in that volume to rise with the speed you see in game. Compare with how slow it goes up in a 100m^3 volume (eg: the big orange tank as a wet workshop). It does. As soon as it is below 91 kPa (or something like that, don't remember the exact value) the crew suit up, diapers included.

@jo_jo_binks Thanks. I know why it happen and is not obvious how to solve it. There is a game event in KSP that is usually triggered when you recover or transmit science. Some stock function listen to that even, namely the 'collect science from X' contracts. So, in the new Science system, I have to trigger the game event when transmitting science, to keep those contracts working. Apparently, Chatterer is listening to that event too, and playing sounds when it is triggered. So I need to find an alternative way to support science collection contracts...

@nosscire Thanks, I know what's going on now.

Sorry, I was not able to replicate it. I launched in LKO with an extra nitrogen and an extra oxygen tanks. Here there is consumption and estimates are correct. If you are not using too many mods, can you send me your savegame? It could be related to the fact that I had to pack the shaders in an asset bundle in the new Unity version. Could you provide me with the first few lines in KSP log (@SavageAngel you too if possible). I'm interested in these lines here: OS: Windows 7 Service Pack 1 (6.1.7601) 64bit CPU: AMD Athlon(tm) X4 740 Quad Core Processor (4) RAM: 8150 GPU: AMD Radeon HD 5670 (1010MB) SM: 30 (Direct3D 9.0c [aticfx64.dll 8.17.10.1429]) RT Formats: ARGB32, Depth, ARGBHalf, Shadowmap, RGB565, ARGB4444, ARGB1555, Default, ARGB2101010, DefaultHDR, ARGBFloat, RGFloat, RGHalf, RFloat, RHalf, R8

@SavageAngel I need to calculate stuff before visualizing the fields. The calculation start as soon as you create/load a game session, and last for 30-60 seconds. When you try to visualize the fields before the calculations are done, I show you that message. So you just need to wait 60 seconds and try again. No upgrade to tracking station needed.

@The-Doctor I'm still working on the documentation so I got no link to give you. But Science change how data is stored and transmitted. You got a mod that change the planets, and another that has specific mission control positions. Maybe the former is messing with the latter? Or the latter is not configured correctly for the former? In any case this isn't related to Kerbalism at all.

@SavageAngel Unfortunately that is a stock issue. A module can add mass/cost, but for some reasons the VAB display is only updated on some circumstances. But you are right, the cost is applied even if you don't see the updated one. I see them... could be Scatterer I don't know. Could you try without it and letting me know? I'm looking into it. Can you be more clear on the issue? You need a scrubber enabled at all times to avoid co2 poisoning, that's all. There is zero interaction with Realism Overhaul in this mod. It is removed because it has no reason to exist when Science is enabled, its original functionality is now available in all parts that can store data (like all pods or probe cores). If you want it back, you can set Science to false in settings.

I guess I could clamp the file size. Make sense actually. This was always like that. When resources are consumed in background, effectively I am using the equivalent of ALL_VESSEL. The pod is often the first part on the list so it get consumed first. Maybe I could try to use the equivalent of ALL_VESSEL_BALANCED and see how it goes. The performance cost should be low enough. I am doing a full simulation of the resources in the planner, and that deal with a lot of issues and corner cases automatically. However this has the drawback you noticed. It can't detect that a resource was consumed because there was none to consume. I am dealing with symmetry for the Configure module (that is used in the radial containers)... so there may be some weird things going on there. I'll take a look. Thanks for the feedback.

In any case, the mod shouldn't CTD. So why not, send me the log. I used undesired word, instead of unexpected, to include balance issues too. Can you expand on this? Intentional. When Signal is enabled, CommNet get disabled automatically (what you call Kerbnet here...) Antennas require to be extended in new Signal system, but this behaviour can be disabled in settings. I suggest you go in Settings.cfg and set 'ExtendedAntenna = false'. This is probably related to the antenna module changing. Anyway, this is a complex mod and adding it to an existing savegame may have complex consequences. Intentional: CommNet (what you are calling KerbNet here...) is not only disabled automatically when Signal is on, it is also constantly re-disabled. So if you go in game settings and turn it on, I disable it automatically as soon as you change scene. The connection lines you see are from Signal (you may notice the proper antialiasing). This is the same problem as [2]. To elaborate on that: when you add this mod to an existing savegame, the old 'extended' state disappear because I'm using a different module to handle the antennas. So please see the answer to [2]. When you collect same experiment/biome/situation combination, more data is added to the same file. But when you transmit/recover it you do not get more science points credited. When you click the remove icon, you are simply deleting that file. Transmitting data is as simple as flagging a file for transmission, clicking on the '>>' icon next to it. I'll check this. You are right on the feeling. I am using the 'science report window' only to support stock/other mods experiment parts. But as soon as you click 'keep' or 'transmit' in that window, the collected science is then stored in my system. So long stock experiment report, you will (not) be missed. I agree with this, will try to make the situation/body/biome more visible.

The ISS has about 900 m^3 of habitable volume, for a crew of 6 (up to 9). This is an eagle view of all the life support systems.

At last. This is an experimental version, potentially unstable and unbalanced. Report any undesired behaviour you encounter. Version: v1.1.5-pre1 Require: KSP 1.2.1, ModuleManager 2.7.5 Download: github Changelog:

@The-Doctor Balance-wise the stress now work along these lines: kerbals break down after 10 thousand days (24 years), in the best conditions. These conditions are determined by: living space (volume per-capita, against an idealized living space of 40 m^3) comforts (a set of 5 different factors, that are provided by environment conditions and/or by parts) pressurized habitat (that is maintained by consuming Nitrogen) Each one of these 3 factors increase the time to breakdown by an order of magnitude. So with none of these, kerbals break down after 10 days. Here are the comforts: Comfort Environment condition Parts that provide it How much does it contribute firm-ground landed on a body gravity ring 0.4 exercise none hitchiker treadmill 0.2 not alone more than 1 crew ... 0.1 call home vessel can communicate with mission control none 0.1 panorama none cupola 0.1 All of the above can be configured, this is just what the default profile is using.

@Yemo Here are the new consumption rates in the 'default' profile. Food: 1.77 Kg/day (6.29 units/day) Water: 2.42 Kg/day (2.42 units/day) Oxygen: 0.84 Kg/day (595.74 units/day) I'm using the same resource definitions as CRP. In my case, the issue was to detect what features to enable from user settings and the profile choosen, and then to make those features available to be checked against in MM patches using NEEDS[] statements. I ended up adding a 'loader' in the KSP asset loading system, that is run before MM, and inject MM patches on-the-fly. So it work in this way: KSP start my loader start parse settings node parse choosen profile node detect features to use inject MM patches on-the-fly MM loader start apply patches (including the ones I injected) The patches injected are very simple, of the form '@Kerbalism:FOR[FeatureName] {}'. Then any MM patch can do some conditional patching depending on the feature set, just with something like: '@ANY_NODE:NEEDS[FeatureName]'

@elpollodiablo The rule framework changed, all those third-party profiles will have to be rewritten. Also, changing the set of rules for an existing savegame may lead to undesired results. The exact issues depend on what changes in detail. Pods will probably get the resources however. @Yemo I got an idea. You could make and ship a profile with your mod, that add some rules you deem appropriate (and to run together with TAC-LS, eventually). Then from my side I will add a way for a third-party mod to force some settings (such as profiles and features), so the user doesn't need to change them manually when your mod is installed. You may wonder, can this be done by simply MM-patching the settings node? It could in the past, but in next version I am messing with the KSP loading system and long story short, the user settings are parsed before MM apply the patches. There is definitely water in the new 'default' profile, and also co2 poisoning and pressurization. The consumption rates I taken from real NASA data (about humans). I don't know if they match the TAC-LS ones, but is possible they are not that much different. The container capacities are calculated from the container volume, taking in consideration pressure/state when appropriate.

@Yemo Let me explain my rationale better. Kerbalism is an environment simulator and a rule framework. The 'default' set of rules (and the parts that comes with it) are an extra, a showcase of what can be done with it. But you can write your very own 'life support' mod by simply authoring a .cfg file, what I call 'profiles'. That is why I want to avoid forcing the player to use one. I could detect when TAC-LS is installed and force the profile to 'none'. I could do that, is trivial. However, what if a player want to create a profile to use togheter with TAC-LS? In that case he can't change it. Such profile may for instance just deal with radiation or quality of life, or anything else that he may deem legit to run together with TAC-LS.

@Yemo I can't do that because it is legit for the player to use a profile (that let's say, add a radiation rule) together with a third party 'life support' mod (such as TAC-LS). In any case, it is really as simple as changing 'Profile = default' to 'Profile = none' in Settings.cfg. @karst45 Kerbals from resque missions are detected and ignored for all mechanics. Then when you get in range of the vessel to resque, some supply resources are 'gifted' (including monoprop) and all mechanics start to apply.

@nightstalker101s You can run this togheter with any life support mod, including Snacks!, by simply setting the Profile to 'none' in Settings.

Guys I'm in 'feature-lock' until I get a stable version out. What @Drew Kerman said gives me an idea about how the new CME blobs will interact with signals, to improve on the current blackout model. For the sun disturbing the signal, what is the reason: rarefied plasma extending around the sun? gravitational effects? Please elaborate. On some good news: I made the background data transmission a part of Science, and it is now agnostic against the communication system used. This mean that it will work with Signal, CommNet, RemoteTech or no signal system at all. I'm also getting the connection status from CommNet or RemoteTech for the other mechanics that use it Then two new contracts: Analyze samples in space (double as tutorial for the new samples/lab mechanic), and Reach interstellar space (cross the heliopause, good luck with that).

@Gotmachine I will definitely have temperature/pressure/gravity/etc sensor definitions. I didn't mention them in the previous post because these will ideally just fit into the appropriate stock part, and that part can only store that sensor (not configurable). The only difference for the user will be that these sensor capture data over time. Every 'sensor' will capture data at a certain rate, and for a particular situation there is a certain amount of data that can be captured in total. So is possible to balance the two such that the whole data is obtained after N days, that's what I meant with 'take N days to complete'. Sensors can be started/stopped. The experiments too are just 'sensors' (but we don't tell the user), that can be stored in 'containers' (goo, matlab, science lab, pod) in the VAB. My reason to have them divided by container type is purely to organize them: it will be better to get this started, balanced and then used by the player. But if some of these 'experiments' make sense in multiple types of containers, that is okay. Experiments will be unlocked with technology progression. That is also a reason to have just a few experiments, to not clutter the tech tree with them. This is not bad. However I will reserve the goo for small biology-related experiments. Something like this doesn't fit in any of the stock parts, unfortunately: it would need a rover camera part. I don't think unbounded data from experiments is a good idea, and more importantly it can't be patched in the stock science system. The situation thing is still fuzzy. Even things like the atmospheric situation is dubious: how is the user going to collect data over days or even months while in atmospheric flight... But assume the one that make sense to be supported. And if an experiment require an ad-hoc situation for me to detect, that's okay. This is good. @The-Doctor I agree, that is a nice idea. I would love something like the STEREO mission.

You work fast buddy! This looks very good already.