Reliability issues (and Tech Transfer)

[NathanKell]

Think we probably need to police reliability data. Issues I'm skeptical of / worried about:

• [ ] Are we double-dipping on failure chance? 80% cycle reliability and 80% ignition chance is 64% actual success chance, e.g. (It's actually slightly lower due to the 5s of increased failure chance)

• [ ] If possible we should tweak the configger to take the increased failure chance in the first 5s into account. Right now it's a uniform (but inversely proportional to burn time) increase in failure chance.

• [ ] Some configs just don't make sense. The Altair starts at like 99.8% reliability but the Antares starts very low, e.g.

• [ ] The LR79 has a serious problem where S-3D is cheaper but has better specs, and better reliability than the config that unlocks one node later (LR79-NA-9).

• [ ] In general, IMO we should not simply have exactly the same values for cycle reliability and ignition chance. Pressure-fed hypergolics, e.g., should have rather higher ignition chance and lower cycle reliability, and the reverse for pump-fed engines I think.

• [ ] Another issue with ignitions: subsequent relights should probably have a higher success chance. That might need a TF change however.

• [ ] We might want to include some level of tech transfer between branches. E.g. XLR41 data -> XLR43 -> LR79/89/105, but also LR87 tree should probably inherit from XLR43 since it does for the ECM. Antares should inherit a bit from Altair and GCRC (and probably Sergeant too). Not much, like 5% rather than 50%, but some. With TF's branch support, it will work fine, e.g. LR79-NA-13 gets 50% of previous LR79 data or 10% of LR87 data, or 20% of XLR43 data, etc.

• [ ] Engines with tech transfer: while the reliability of a given config is calculated based on flown models of that config, that is implicitly including tech transfer in real life but not ingame: Example: Castor 1 vs XM20 config. The XM20 is quite unreliable, the Castor 1 ludicrously so even at the start (99+% reliability). But the reason few production Castor 1s failed was precisely because of the XM20 test program--which we should model by tech transfer rather than starting reliability. This is true for any engine with tech transfer. AJ10-37 to AJ10-42 is another example: AJ10-42 had a great track record in part because of all the AJ10-37 failures that gave data.

• [ ] Tech Transfer: we should make better use of multiple branches for tech transfer. In particular, you shouldn't get the full 50% going from, say, the XLR43-NA-3 all the way up to the LR89-NA-7.1; you should get the full transfer only from the immediately prior config (maybe 2 back if they're close?), and lower values for earlier configs. We also can use this system for limited transfer across lines, i.e. some transfer between LR79, 89, and 105.

Anything else?

[leudaimon]

We could define a consistent way to deal with engines that have too few data for a good estimation of reliabilities, I have the impression this is all over the place

[jwvanderbeck]

Are we double-dipping on failure chance? 80% cycle reliability and 80% ignition chance is 64% actual success chance, e.g. (It's actually slightly lower due to the 5s of increased failure chance)

You have a 20% chance to fail one check and a 20% chance to fail the other. They aren't cumulative because one isn't dependent on the other. (one doesn't influence the other)

[StonesmileGit]

If the probabilities are completely independent, that means you can multiply them, P(igniting) x P(burn for t seconds)

[StonesmileGit]

Two more things:

• [ ] Solids shouldn't get their ingition chance changed by dynamic pressure.
• [ ] The starting reliability of the Castor 1 is too high, it should get transfer from the first config.

[NathanKell]

Are we double-dipping on failure chance? 80% cycle reliability and 80% ignition chance is 64% actual success chance, e.g. (It's actually slightly lower due to the 5s of increased failure chance)

You have a 20% chance to fail one check and a 20% chance to fail the other. They aren't cumulative because one isn't dependent on the other. (one doesn't influence the other)

To put this another way: say an engine is classed as "98% success chance". If you naively set both cycle reliability and ignition reliability to 98%, the actual success chance becomes (probability of ignition, 98%) x (probability of making it through the burn, 98%) = 96%. You've just doubled the failure chance. If in fact the engine is usually involved in a two-burn flight it's worse, 94.1%.

[marsh1832]

To add, they are cumulative in the sense where the ignition chance must pass before the burn chance can be checked. So the failure rate is cumulative. And as NK showed in an example of a second ignition, then that’s a third check in a row which must pass, so the mission failure rate is all three cumulative.

I love the idea of the failure rates being tuned to where the pump fed engines have a higher ignition failure but lower burn failure, and the inverse for pressure fed. Adds more character to the engine feed choice.

[NathanKell]

I have updated this issue to mention tech transfer and branches.

[Capkirk123]

2539 addresses most of these issues.

For the reliability of pump fed vs pressure fed engines, that depends a lot on the engine itself. For example, Soviet pump-fed uppers almost never failed to ignite, but had their turbopumps fail during or shortly after their burn pretty frequently. The exception being the RD-58, which explodes on ignition to this day, but is usually fine once it starts. Even solids aren't immune, some had a propensity to explode, while other would just fail to ignite.

[ec429]

If possible we should tweak the configger to take the increased failure chance in the first 5s into account.

FWIW TestLite already accounts for this internally: if an engine has a failure chance of (say) 10% across its 120-second rated burn time, then there will be a 1.5% chance of failure in the first 5s and an 8.5% chance in the next 120s, for 10% total over the 125s.

you should get the full transfer only from the immediately prior config

Doesn't techTransferGenerationPenalty already cover that (to some extent)? (As long as the configs are listed in the right order…)

[NathanKell]

No. Consider running an XLR43 until it's 10k data and then using an RS56. You should not start at 2000 data for the RS56.

Sent by my thumbs, slowly.

On Thu, Dec 9, 2021, 2:51 PM Sound and Fury @.***> wrote:

If possible we should tweak the configger to take the increased failure chance in the first 5s into account.

FWIW TestLite already accounts for this internally: if an engine has a failure chance of (say) 10% across its 120-second rated burn time, then there will be a 1.5% chance of failure in the first 5s and an 8.5% chance in the next 120s, for 10% total over the 125s.

you should get the full transfer only from the immediately prior config

Doesn't techTransferGenerationPenalty already cover that (to some extent)? (As long as the configs are listed in the right order…)

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/KSP-RO/RealismOverhaul/issues/2505#issuecomment-990373156, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABHH4IV3RBF6VJ2Z35SVXDLUQEXFRANCNFSM5CNPEIHQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[ec429]

Ah fair point, you're thinking of the max transfer. But branches don't fix that either; they, like techTransferGenerationPenalty, only set the transfer coefficient. The cap (techTransferMax) is the same no matter which config the transfer is coming from.

Maybe we need to add a techTransferSourceMax, that caps the du before the branch modifier is applied, so that weaker links can't supply as much even if you have 10k on the old part.

(Either that or you're just referring to the fact that RO sets techTransferGenerationPenalty stupidly low, at 0.05. Why isn't that higher?)

[NathanKell]

My point is that afaik generation penalty only applies when you fly multiple generations. In the example I cite it wouldn't be used, the transfer is direct from original to current part. How would the game know those parts are many generations apart?

Sent by my thumbs, slowly.

On Fri, Dec 10, 2021, 5:33 AM Sound and Fury @.***> wrote:

Ah fair point, you're thinking of the max transfer. But branches don't fix that either; they, like techTransferGenerationPenalty, only set the transfer coefficient. The cap (techTransferMax) is the same no matter which config the transfer is coming from.

Maybe we need to add a techTransferSourceMax, that caps the du before the branch modifier is applied, so that weaker links can't supply as much even if you have 10k on the old part.

(Either that or you're just referring to the fact that RO sets techTransferGenerationPenalty stupidly low, at 0.05. Why isn't that higher?)

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/KSP-RO/RealismOverhaul/issues/2505#issuecomment-990978325, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABHH4ITPIFF6ICITA7S6V53UQH6UJANCNFSM5CNPEIHQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[ec429]

Generation penalty is nothing to do with indirect transfers. Generations are the comma-separated items within a techTransfer branch. (In TL, indirect transfers don't happen at all.)

The breakage in your example only happens because the config is written backwards (#1968). LR89-NA-7.1 has:

techTransfer = XLR43-NA-1,A-6,A-6H,A-7:20&XLR43-NA-3,LR43-NA-3,LR89-NA-3,LR89-NA-5,LR89-NA-6:50

which means it gets 50% transfer from XLR43-NA-3 but only 40% (0.50 * (1 - (4 * 0.05))) from LR89-NA-6. (Under TestLite it's 30% instead (0.50 - 4 * 0.05) because I did things Differently for some reason.)

If it were written correctly as

techTransfer = A-7,A-6H,A-6,XLR43-NA-1:20&LR89-NA-6,LR89-NA-5,LR89-NA-3,LR43-NA-3,XLR43-NA-3:50

then the percentages would be the other way round and XLR43-NA-3 would be four generations away.

[NathanKell]

Ohh gotcha! Yeah that solves the problem

Sent by my thumbs, slowly.

On Fri, Dec 10, 2021, 12:06 PM Sound and Fury @.***> wrote:

Generation penalty is nothing to do with indirect transfers. Generations are the comma-separated items within a techTransfer branch. (In TL, indirect transfers don't happen at all.)

The breakage in your example only happens because the config is written backwards (#1968 https://github.com/KSP-RO/RealismOverhaul/issues/1968). LR89-NA-7.1 has:

techTransfer = XLR43-NA-1,A-6,A-6H,A-7:20&XLR43-NA-3,LR43-NA-3,LR89-NA-3,LR89-NA-5,LR89-NA-6:50

which means it gets 50% transfer from XLR43-NA-3 but only 40% (0.50 * (1

• (4 * 0.05))) from LR89-NA-6. (Under TestLite it's 30% instead (0.50 - 4
• 0.05) because I did things Differently for some reason.)

If it were written correctly as

techTransfer = A-7,A-6H,A-6,XLR43-NA-1:20&LR89-NA-6,LR89-NA-5,LR89-NA-3,LR43-NA-3,XLR43-NA-3:50

then the percentages would be the other way round and XLR43-NA-3 would be four generations away.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/KSP-RO/RealismOverhaul/issues/2505#issuecomment-991259774, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABHH4ISRCIKSMIMRZG5PWGTUQJMS7ANCNFSM5CNPEIHQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.