seregheru

@ShotgunNinja That looks like a pretty neat solution. You'd lose the long tail of rare unexpectedly long-lived parts, but that's possibly a good thing. I can't think of a reason why it won't work. You would have to experiment to see how sudden the onset of wear-out failures feels, but you could always add an extra point or two to the curve to soften it up. Looks promising anyway - would be interested to see how it plays.

Calculating the CDF means you DON'T calculate over and over at 60Hz. Calculating at every time step is much, much simpler but obviously has a huge performance penalty. Calculating the CDF lets you set the lifetime once and then just test "(age>lifetime)" in each step. You are already doing this - the code you have is exactly what you would get if you calculated then inverted the CDF for a uniform probability density function. Age is not on both axes of the CDF. The x-axis is the age and the y-axis is the probability of failure before that time. You generate the y-axis value from random number and then read across to the curve and down to the lifetime on the x-axis.

@ShotgunNinja [Ah, inverted plot in edit is more clear] Approximating the bathtub function still leaves you the survival function to calculate and the integral to do. The cumulative distribution is the important one, as that's the one that gives you the lifetime value. That will start at zero and grow towards 1. The gradient is always non-negative. I'm not totally sure on the exact shape in between - I think its a curve that starts steep, curves off and then straightens slightly.... but I'd need to put some numbers in a spreadsheet to be sure.

@ShotgunNinja Regarding malfunctions - have you considered a "bathtub curve"? From what I can see in the source, every part is guaranteed to fail eventually, some time between min_lifetime and 10*min_lifetime... Under the current system, it looks like a part that *could* fail on a trip to Minmus would *always* fail on a trip to Duna, whereas a part that *could* survive on a trip to Duna would *never* fail on a trip to Minmus. [If I've understood this correctly] it will be very hard to set a malfunction rate that gives a total number of failures that isn't at one extreme or the other - which extreme depending on tech level and mission length. A bathtub curve combines a falling "early failure" curve, an increasing "wear" curve and a constant random failure rate. The combination has a fairly flat middle portion with steeper sides at the beginning and end of the expected lifetime. From a gameplay perspective, a bathtub curve would let you set a very low baseline rate of failure per unit time, allowing longer continuous time-warps, while still ensuring that even short missions would have at least some chance of failure and that missions far beyond the design lifetime would still suffer multiple failures. Tech progression could both scale the curve and maybe add a "starting age" to the components. IRL, rigorous testing and selection means that space-going components are typically only used during the flat middle section of their lifetimes, so this wouldn't be an entirely realistic model for a space program - but I figure Kerbals aren't *that* rigorous in their testing anyway. Currently, the uniformly distributed lifetime roughly approximates only the increasing "wear" curve - the linear cumulative distribution function implies a constant probability density function. But a component can only fail at time t provided it has already survived at least as long as time t. This implies an increasing instantaneous probability of failure (or hazard function) that will be extremely difficult to tune for balance. A flatter hazard function would be much easier to tune as well as being closer to reality. From a coding perspective, implementing a bathtub curve wouldn't be all that different from your current code. You could still have a simple "(age>lifetime)" test at the per simulation step level, but you would initially set lifetime according to the inverse of a different cumulative distribution function (in other words the random number you generate, x, is given by x=cdf(lifetime), which you rearrange for lifetime.) As far as I can see, this is the only code change. As the aim is satisfying gameplay, rather than mathematical accuracy, an approximate CDF would be sufficient (as the "bathtub" shape describes only the hazard function, to do things properly you'd need to get from that to the PDF by multiplying by the survival function, integrate the result to get the CDF and then invert that to get the lifetime...). I think the result should allow you to satisfyingly tune the failure rate over a much wider range of mission durations, keeping malfunctions relevant throughout career progression without completely crippling longer missions.

@ShotgunNinja - that was some quick work! Even hoping this might happen, I didn't expect it would happen quickly. Thanks for all the work!

@pip12345 Water can be recycled. This means that a vessel does not need to carry the weight of its water requirements for the entire mission. Instead you carry the food you need and recycle the water. Combining water and food into a single resource was something that I could live with, but it was still a real disappointment. Be careful about making statements about balance between realism and fun as clearly there is no objective scale. Stock strikes the perfect balance between realism and fun - for some people. TACLS struck the perfect balance between realism and fun - for some people. Kerbalism strikes the perfect balance between realism and fun - for some people. On the whole, Kerbalism has a realism oriented tone - it's not surprising that a chunk of the audience interested in Kerbalism is also interested in the greater realism that separating food and water would allow. There is a good case for abstraction where resources will be consumed at a constant rate and renewed under the same circumstances - there is no gameplay difference between carrying "food" vs carrying "breakfasts+lunches+dinners". Abstracting these meals away into a single resource cuts down on tiresome inventory management without affecting ship design or gameplay. The same cannot be said for abstracting away water. It is an important design decision whether or not the weight of a recycler can be justified for a mission, whether replacement water can be sourced from the ice on planets and moons, whether the water can be electrolysed for hydrogen and oxygen, whether the vessel can handle the additional EC load. Importantly, the additional complexity and depth is largely optional. TACLS offered single parts with a balanced inventory of oxygen, food and water that would be consumed in the correct proportions - players could simply add the part and forget about it. If you want to treat water as pristine bottles of unopened mineral water then you can. But there can be real gameplay differences in the way that water as a resource plays - and a lot of players that enjoy that gameplay. With the apparent demise of TACLS there will be a lot of players looking towards Kerbalism as a replacement, and probably a lot more requests for water to be added.

This looks like a really great mod and clearly took a lot of work. I'm struck by the scale of it. I've been playing around with it for a day, not really long enough to see much of it, but was quite excited about some of the features. Unfortunately, it was only after grinding the science I needed to launch a keostationary relay network, that I realised this mod completely kills RemoteTech functionality. Sadly, that means game over. Most mods add some additional seasoning to an already excellent stock game but, without a communications mod and a life support mod, playing vanilla feels like cheating. For me, RemoteTech is the centre-piece around which the rest of my game is organised. It is the premier communications mod currently in existence for KSP. It's a non-optional requirement of all of my career saves. Completing a 4-satellite keostationary relay network is always the first major landmark achievement of my space program. Without it - without signal delay and the flight computer - unmanned launches are just a cheaper, lower-risk alternative to manned missions. With RemoteTech, unmanned missions play in a fundamentally different way. RemoteTech changes the *character* of KSP, in a way that the communications system of Kerbalism simply does not. I think it's dangerous to imagine that there is a quick fix that you can implement yourself to encourage users of RemoteTech to use your system instead. RemoteTech has years of development, over 20 contributors, and iteration upon iteration incorporating player feedback. It is also highly configurable for users with different tastes and tolerances. No doubt similar arguments can be made by fans of other mods that Kerbalism overrides. I appreciate that Kerbalism took an awful lot of unpaid time and effort, and that I have no right to expect anything from it. But at the same time, I'm uninstalling it now and starting a new career save without it. I think that's sad. I'm disappointed that I won't get to experience radiation sickness or capsule fever or being struck with a coronal mass ejection. Kerbalism feels like a realism oriented mod, and that's a tough audience, as everyone has their own ideas about which concessions towards gameplay are acceptable. Compatibility with other mods goes a long way towards solving that issue. I understand that full inter-operability with other mods is a daunting amount of work, but a simpler on/off toggle for certain systems may have direct advantages to your own mod. Generally, tightly coupled systems end up being a real maintainability headache further down the line. Not being able to deactivate the conceptually distinct components of this mod without breaking others sounds like an early warning sign. Thanks for the time and effort, good luck for the future. Hope to play again one day.