Failures rework

[gotmachine]

Current state of affairs :

• All the rewritten modules (ProcessController, Experiment, radiation coils, etc...) are entirely missing reliability features support.
• The reliability module radiation handling is entirely unaware of the new radiation system.
• The engine reliability related features have a few issues (poor mod support, failing/buggy MM-fu parsing)

@SirMortimer notes :

• Make high quality a configurable option
• Add API to delegate calculation of MTBF-based time of failure to 3rd party plugins
• Add API to delegate part failing to 3rd party plugins (what happens if the part breaks)
• Make radiation-hardened option configurable, and decouple from high quality (you can have standard, radiation hardened, standard+high quality, radiation hardened + high quality)

I'm quite undecided on the future of the reliability features and I have low personal interest in it. But from a technical POV, this is my recommendations regarding an implementation rework :

• Have a single "MTBF/radiation" module per part, referencing every other targeted module.
• The module handle a list of "ModuleReliabilityHandler" derivatives, which implement module type specific handling, both for our modules and stock/mod ones. Similar to the approach we have in SolarPanelFixer.
• The module configs contain a list of nodes, one per target module on the part, and instantiate the relevant handlers depending on the module type.
• We could use an IFailableModule interface applied to ModuleData (not KsmPartModule) for handling failure behavior within our own modules.
• Re-implement the engine ignition / burn time features in a separate module (or possibly in a separate mod). Those features don't need to run in the background and don't need all the MTBF and radiation stuff of the classic reliability.

Regarding the feature itself, my personal wish would be to get ride of the hardcoded low/high quality thing and instead provide :

• A "desired reliability MTBF" editor field, freely configurable.
• Another one for radiation, "desired radiation resistance".

Config-wise, we define ;

• a base MTBF / radiation tolerance
• a base extra cost/mass per year of extra MTBF / per rad/h of radiation tolerance.
• an extra cost/mass vs time scaling function : a floatcurve would offer the best customization, but a set of hardcoded functions could do too.

This would allow :

• To make long-lasting missions a possibility.
• To avoid the micro-management and annoying mistakes in the editor, by allow to set a vessel-wide MTBF target before launch.

Regarding a possible API, I would suggest to keep it simple. Have a delegate method that provide a factor for the base MTBF, and another that provide a factor for the extra cost/mass per extra year of MTBF.

I really don't see the point of having the possibility of delegating the failure handling to another mod. No mod handle background (unloaded) failures.

[hemeac]

One aspect that I really like from Oh Scrap! is that "Subsequent 'new models' of parts become more reliable than their earlier counterparts." Is there scope to tie in a feature to the reliability modules of either engines and possibly other modules? In the case of engines, that creates a real incentive to test engines in stands prior to launch and not need to "roleplay" that feature in campaigns.

[gotmachine]

The approach taken by Kerbalism is to allow you to improve reliability at a cost/mass, which is an abstraction of "research/engineering more for better reliability". Personally I really don't like the idea of having to run dummy/test flights, but I guess it depend on your playstyle.

Anyway, tracking per-part usage isn't trivial to implement, and even more lately due to the increasingly common presence of configurable / switchable / procedural parts. Moreover, there is already a bunch of mods doing that (OhScrap, TestFlight, TestLite, PayToPlay...).

Currently we aren't decided on the future of the feature. Due to the massive changes in the 4.0 codebase, we need to re-code it almost from scratch. We will focus first on the "unique" features of Kerbalism : radiation damage, passive components MTBF failures working in the background for our own modules. Then possibly explore how we can delegate/integrate with other failure mods, mainly OhScrap and TestFlight/TestLite.

We might strip out the whole engine-specific features (ignitions, burn time) in a separate sub-mod, or just drop it altogether. There are even more alternatives for that specific feature, and it require a lot of constant maintenance in terms of mod support, which we aren't really able to provide.

[hemeac]

Just expanding on my previous comment, this does not need a reply. On a personal level, I like the idea of 3.11 engine implementation being available as a sub-mod if it is easy to separate. Unlike Oh Scrap, the performance hit seems to be negligible and is fairly straightforward. I haven't tried the others so can't comment. I thought the implementations of the ignitions was a great base and I added variation in the burn duration by having it based on a cubic (s-shaped) function of the vacuum isp and differs depending on whether the engine is kerolox or hydrolox/metholox. For start failures, I have just set that to be global upgrades so it declines as one progresses through the tech tree. That gets the majority of the way there and close enough that as I said earlier, can roleplay the testing aspect.