[1.8.x] Oh Scrap!- A ScrapYard based Part Failure and Reliability Mod 2.0.1 (07/12/2019)

[severedsolo]

10 hours ago, Gordon Dry said:

Could you please add StoredCharge to be fully recognized by Oh Scrap! because actuall the Tank Safety Rating is always zero?
This is the reason why the RealBattery parts have so many failures, even with my patch.

I think on balance, I'm not going to include MM patches for every mod that has non-leakable resources, I feel it should be up to the mod maker to include patches themselves. For now though you can use this patch:

OHSCRAP_RESOURCE_BLACKLIST:NEEDS[OhScrap]
{
	name = StoredCharge
}

 

12 hours ago, Kwebib said:

EDIT: Looks like something screwy is happening down at line 23659 and beyond in the log. Not sure what it means, though.

That looks like a reflection error on KCT's part - meaning it's not found a mod it's expecting to be installed (nothing serious, I assume it's KK or something)

12 hours ago, Kwebib said:

Problem: Generation also increments by one after recovering craft and hitting "Quick Apply" in ScrapYard.

Suspect I know what this is, but just to confirm - does this only happen when the Editor auto loads a vessel when you start it up?

Edited May 15, 2018 by severedsolo

[Gordon Dry]

7 hours ago, severedsolo said:

For now though you can use this patch

Simple like that, ofc - it was late for me obviously.

[Kwebib]

On 5/15/2018 at 1:16 AM, severedsolo said:

Suspect I know what this is, but just to confirm - does this only happen when the Editor auto loads a vessel when you start it up?

Doesn't look like that's the case. I made a second vessel and loaded it, then reloaded the "pad tested" vessel and the Generation is still 2.

Also, I just realized that this bug does not happen if you uninstall KCT.

Edited May 17, 2018 by Kwebib

[Kwebib]

I worked my way back to Oh Scrap 1.3.1 and the bug is gone. Don't know if this helps.

EDIT: Found a workaround which may provide more information, still using Oh Scrap 1.3.4. Go back to the space center instead of recovering your vessel, disable KCT, recover the vessel, the reenable KCT.

Edited May 17, 2018 by Kwebib

[severedsolo]

Just now, Kwebib said:

I worked my way back to Oh Scrap 1.3.1 and the bug is gone. Don't know if this helps.

It sounds reproducable. I should be able to find the issue.

[strudo76]

I think I'm missing something. I have an aircraft that I've flown 6 times, each time returning to the runway and using the recover vessel option of KCT. Oh Scrap! is telling me the cockpit's safety rating is zero, with failure imminent. So I edit the recovered craft and no matter what I do I can seem to get the cockpit to use a new part. I tried selecting it and clicking the new part button, but it didn't seen to do anything with regards to build time or safety rating. Am I doing it wrong or am I not understanding something?

On the fun side, this happened. failures! First an engine fuel leak destroyed the engine, then an elevron got jammed, then a fuel tank started leaking. Not a bad landing considering (both considering the damage to the craft, and my less than ideal skills at designing or flying aircraft in KSP)

Edited May 19, 2018 by strudo76

[severedsolo]

32 minutes ago, strudo76 said:

I tried selecting it and clicking the new part button, but it didn't seen to do anything with regards to build time or safety rating. Am I doing it wrong or am I not understanding something?

Known issue - if you have Quick Apply turned on, be sure to discard the broken part from the inventory once you have replaced it. Then right click a couple of parts to make the stats regenerate (basically, the vessel has to be "modified" before it bothers to check, right clicking seems to trigger that).

Edited May 19, 2018 by severedsolo

[Beetlecat]

7 hours ago, severedsolo said:

Known issue - if you have Quick Apply turned on, be sure to discard the broken part from the inventory once you have replaced it. Then right click a couple of parts to make the stats regenerate (basically, the vessel has to be "modified" before it bothers to check, right clicking seems to trigger that).

Ah. I think this was getting me, too. It kept reinstalling the bad part.  Bad mechanic! Bad!

[strudo76]

9 hours ago, severedsolo said:

Known issue - if you have Quick Apply turned on, be sure to discard the broken part from the inventory once you have replaced it. Then right click a couple of parts to make the stats regenerate (basically, the vessel has to be "modified" before it bothers to check, right clicking seems to trigger that).

I'm not using the auto quick apply, and I have no cockpit parts in the inventory. I'm not building a new craft, but using the kct recovered vessel, so the aircraft is already built.

I guess the way to do it will be too strip everything off the cockpit, remove it and delete from inventory, user a new part and reattach everything? I'll post a pic or two later in case we're not talking about the same thing.

[severedsolo]

13 hours ago, strudo76 said:

I'm not using the auto quick apply, and I have no cockpit parts in the inventory. I'm not building a new craft, but using the kct recovered vessel, so the aircraft is already built.

Either way, once you've replaced the part, you need to right click a part (or two) to get it to refresh.

Edit: actually I need to check whether it clears the EndOfLife flag when it refreshes. I have a feeling it might not.

Edit2: I've just realised what you meant. I suspect OhScrap is not going to refresh the part because Scrapyard hasn't fired an event. Hmm, leave that with me. Might just need to give you a button to force the stats to regenerate. In the meantime yeah the workaround would be to strip it out completely and replace it if it works the way I think it does.

Edit3: Ok I've determined it's a ScrapYard issue - applying a new part, and applying a part from the inventory directly does not trigger any of the "inventory changed" events, but using Quick Apply does.

Basically, OhScrap doesn't know it should re-check the stats, because ScrapYard isn't telling it that it should. I've reported it on the ScrapYard thread.

Edit4: I can put a workaround in for this, but I'd rather it be fixed in SY, as otherwise I'll have to be constantly querying a parts ID.

Edit5: @strudo76 - May not have been ScrapYard after all. try the latest dev build see if that helps.

Edited May 20, 2018 by severedsolo

[severedsolo]

Oh Scrap 1.3.5 Released

• Fixed issue where generation wouldn't be properly calculated when using KCT.

 

[Austinator48]

Just an idea: Engineers should be able to fix all failed parts or be the only ones able to, gives more of a reason to bring engineers along.

[StarkRG]

12 hours ago, Austinator48 said:

Just an idea: Engineers should be able to fix all failed parts or be the only ones able to, gives more of a reason to bring engineers along.

I'll +1 this, and also add the suggestion that, if something is on the grounds of the KSC and landed, repairs should be able to be done "remotely" since it's not really remote. Additionally, once a vessel has been recovered and stored in KCT there should be an option to repair or replace all faulty parts in a vessel without having to bring it into the editor first (repair would be the default and replace only if the part was flagged for trashing). Finally it'd be nice to have an in-game config for the failure chances. Parts on my vessels seem to fail inordinately frequently, even when they've been used once (bypassing the beginning of the bathtub curve) and have safety ratings of 3, 4, or 5 (having six or seven safety 5 parts with one or two uses under their belts is very annoying, not to mention that new safety rating 5 parts shouldn't be failing as much as new safety rating 2 parts, even accounting for the bathtub curve).

I just thought of another nice feature: burn in. Once you've used a type of part enough that all new parts of that type are given safety rating 5, you should be able to spend a bit more (10-15%) to bypass the beginning of the bathtub curve. This is what server-grade hard drives are, they're no different than consumer-grade hard drives, it's just that they've been tested beyond the point that most of the early failures have already taken place.

Second afterthought: If an engineer is on board, make "remote" repairs more likely to succeed.

Edited May 22, 2018 by StarkRG

[Beetlecat]

I must be conflating something in my brain, but I thought there *was* some affect of having engineers on a craft, etc. This must be for KCT, or Ground Construction, or some other kind of failures modeling (Maybe USI?).

[severedsolo]

40 minutes ago, Beetlecat said:

I thought there *was* some affect of having engineers on a craft, etc

There is. Engineers give a +10% to the chances of a successful repair (whether EVA or remote)

[Austinator48]

6 hours ago, severedsolo said:

There is. Engineers give a +10% to the chances of a successful repair (whether EVA or remote)

IMHO I think it should be a lot higher then that, they are engineers after all. (Is there a way to make a config file to edit that amount? and if so what would be the variable?)

[Beetlecat]

PSA: Always preform run tests on your engines before you need them in a mission.

Always.

[EatVacuum]

On 5/22/2018 at 11:33 PM, Austinator48 said:

IMHO I think it should be a lot higher then that, they are engineers after all. (Is there a way to make a config file to edit that amount? and if so what would be the variable?)

Maybe 10% plus 10% per level of engineer? Even one fresh out of university and astronaut camp should make a difference. But more experienced Engineers shoud also make more difference. Scotty could probably cludge a fix for a broken transporter from a rubber band, two paper clips and and his pocket lint so a level 5 Kerbal engineer should make a major difference IMHO.

[severedsolo]

So, it's pretty obvious from my own playtesting and some of the recent posts on here that the failure balance is still off. I've been giving it a lot of thought, and I have a few proposals to change it, but I'd like some input from you guys (all this is subject to balance testing and such, and may change as we go along).

Goals:

• Stop vessels made of first used parts from falling apart within 30 minutes. To my mind, the ideal would be a 1/3 chance of a vessel made out of nothing but Gen 1, 1st use parts going wrong.
• Make parts that are "super safe" have a slight chance of going wrong still.

Proposed Changes

• 1) Massively reduce the failure rates (by at least a factor of 3, possibly as much as a factor of 10)
• 2) To balance the above, introduce a "recurring failure check" chance (ie it won't just happen on first load) - I'm thinking somewhere in the region of every 2-5 (real-time) minutes - failures still won't happen while the vessel is unloaded.
• 3) Remove the "cascade failures" (the fact that a part can immediately re-roll a failure when you repair it. It's annoying)
• 4) Steal @EatVacuum's idea and have repair chances go up with engineer level (other kerbals will still be able to do repairs, but they will never get a better chance of repairing than even a basic engineer).
• 5) Adjust the random number generator so it's capable of spitting out failures of <1% (don't worry, if I do it right, it will still have a not very high chance of coming up)

Edited May 27, 2018 by severedsolo

[Gordon Dry]

@severedsolo I only can repeat my kinda demand of a new approach in base reliability calculation.

Not that all mechanics, engineers and scientists start from scratch on each project, the progress in R&D tech tree is taken into account for the base reliability calculation of a new part.

For example; I have unlocked miniturization and decide to send a classic PolarSat vessel with an old engine technique that I never used before to polar orbit, lifting a small, lightweight but sophisticated satellite that was impossible before unlocking that node.

The specific engine that I never used before, why should it have a "chance" of 80% to fail on first launch, when the engineering is already at a level of let's say 40% of the whole tech tree?

Just my 2 or 5 cents.

Edited May 27, 2018 by Gordon Dry

[BlueTiger12]

@severedsolo

I have some suggestions, but i don't know if they go too far. But nevertheless i will suggest them, perhaps something of it is usefull to you.

Generally i like your mod and the direction it is heading very much. There are only 2 things i would like to see changed.
One of them is related to your rebalancing.

1. I would like the possibility of failures while it is not the active vessel.
2. I would love the concept of parts wearing out during flight - so that they have a mean expected liftime.

For example that the batteries of my comsats are slowly dying and therefore i have to think about redundancy and replacing them at some time.
It also would add a little bit to the KCT concept - where time is valuable - as you should think twice if you make missions one after another as your satellites wear out faster if you timewarp a lot, or do them in paralell.
But with failures only on loaded vessels, for example my comsats would never wear out.

I think they would also play nicely together, as you think about rerolling in intervals.

I think of something like this:

1. Let failures happen on vessels, regardless if they are loaded or on rails

2. Dices for failures like engine ignitions, solar panel deploy mechanism, antenna deploy mechanisms or parachutes are rolled on activation, as these are instant failures.
This is also the way it is currently implemented, i think.

3. Failures for things like batteries, fuel tanks and so on are rolled on launch.

4. Failures for engine overheating and so on are also rolled at engine ignition.

5. If a failure if point 3 or 4 is determined, it will occur somewhere between now and the part's expected lifetime.

6. If no failure is determined, the dices are then again rolled when the expected liftetime is reached. Then if a failure is determined, it will happen between now and a part of the original expected lifetim (1/3 for example)

7. At the end of the 2nd expected lifetime, dices are rolled again. The time is again 1/3 of the previous lifetime (which was already 1/3 of the original lifetime).

8. This goes on every time the lifetime ends. Obviously there should be a cap to prevent the dices from rolling to often and making a failure unavoidable. Maybe a minimum time of 30 ingame minutes.

This way the possiblity of a failure would increase tue to roling dices more frequently, after the expected lifetime is reached. The lifetime concept would also give a more variable time when a failure will happen, opposing to your fixed 2 minutes for engines or 6 hours for other parts, after which no more failure will happen, as long as you don't switch back and forth.

Also the expected lifetime should increase with the failure rate decreasing. So the more often a part is build, the longer it's expected lifetime will be.
Maybe the lifetime could also be increased by paying additional money for that part.

Lifetime for engines should be pretty short then, but the lifetime should only be counted while they are running (Failure described at point 4).

Due to a failure roll when activating a part (Failure described at point 2), it would also mirrow the risk of moving parts and engines (solar panels getting stuck the more often they are retracted and extended,
antennas getting stuck on extracting, engines failing with more frequent shut-down and activation)

With this you would have a little risk at the start, where you activate engines and antennas and solar panels, then you would be pretty safe for the expected lifetime (though there is still a small chance for a failure) but after the expected lifetime, your vessel/satellite will slowly start to degrade, as it would in real life. But you could calculate with that. A part with an expected lifetime of 2 months will most likely not make it to Duna, but a part with an expected lifetime of about 3 years most likely will make it and also be able to operate in orbit for a long time.

I also agree with @Gordon Dry that it would make sence that a part being build more often should have an impact on all other older parts of that category, i.e. a highly reliable Poodle should have made a LV-909 a little bit more reliable, too. But i don't know if that is just too dificult or complex to implement.

I hope something of the above can help you in your decision in which direction you will go in balancing the failures.
Thank you very much for your mod :-) It makes the game way more fun to play for me.

Edited May 28, 2018 by BlueTiger12

[linenoise42]

@severedsolo I've been thinking about this too

I really like the idea of new tech being less reliable than the tried-and-true older tech, but the way its implemented I find myself just cheesing it.  A reliability level 1 item is going to fail, so it's not worth trying to use it.  That's easy to solve though - just make a "ship" with a bunch of random items, head out to the launch pad, and then recover the vessel.  This, of course, completely defeats the purpose, but it's almost necessary when dealing with uncommonly used, but long-lifetime items, such as space station components.

What's interesting about tracking the reliability of each part is that you open up a new sink for different resources that the base game is somewhat lacking.  Some ideas that might or might not be interesting:

Repairing:
- Parts should be repairable, but based on the skill level of the engineer.  If you divided the tech tree up into tiers based on the science cost to research, a 5 star engineer should be able to repair any part, but a 0 star engineer could only repair the lowest-tech items.  As others previously mentioned, this gives a reason to bring engineers along.  Since any part can fail, it also makes the higher-tech items permanently have a higher cost - if you're taking a 1 year trek out into space with the top level nuclear reactors, you better bring along the best-of-the-best in technicians.

- The above could be tweaked so lower-level engineers have a chance to fix higher level tech, but at risk of making things worse / permanently breaking them

- There should always be a way to fix a part.  I launched a reliability 1 station core, and it immediately short-circuited once it was set up.  I could undock everything, replace this one core with a new one, and effectively rebuild the station.  It'd be neat, though, if instead I could send a repair mission.  Send an appropriately-leveled engineer with some spare parts, and replace its internals.

- Retrofitting older hardware.  You launch a ship with a reliability level 2 item in it.  Later, you progress that engine to level 3 - it'd be neat to send an engineer to retrofit the existing engine to level 3 reliability.

Failures:
- What about critical failures, fore when things go -really- wrong?  (like a low level engineer tinkering with something outside their expertise).  Batteries short out and drain charge - but I wonder if you could simulate a fire by causing that short to also generate heat, which might eventually destroy the part?

Reliability:
- Maybe rather than "number of launches", reliability works more like experience levels for parts, with different actions providing different xp contributions.  The xp needed for reliability levels might depend on mass (complexity?) or science level.
- Parts could "level up" after being in use for X hours - it would provide a real purpose to the engine test platform shown in the OP, rather than immediately recovering the vessel.  Make some weird test platform and part it off of the launchpad for a day.The time needed to level up might be based on mass (complexity?) or science level.
- Successfully repairing a part, or recovering a failed one, should level up the part faster.  Just like in real life, it's hard to fix bugs that haven't happened, and easier when you have something to investigate after the failure
- Not sure how practical this is, but you could use the above as a sink for excess funds/science.  Use your R&D labs (science), or use your funds to outsource testing on specific parts, with a chance to level them up.  This could even take X days, if that's possible to do.  This might be tough to balance, but if done right it might provide a reason to risk using lower reliability parts, or eliminate some of the grind in leveling up the parts

Loving the mod so far!  It's so much more interesting to think of ships as things that can fail outside of pilot error, and ensuring there's redundancy and an actual use for the abort button!
 

[strudo76]

There is also some potential to add some new strategies, that could increase part reliability in exchange for funds/science/rep. Might result in some interesting decisions.

[Tonas1997]

So I know this is a kind of a silly question, but here it goes anyways:

I'm playing on a 1.3.1 save, and I've been thinking about installing a part failure mod. Needless to say, this is the one which grabbed my attention the most

However, while there is a compatible version on the repository, the ungodly amount of bug fixes which occured ever since (mainly for the 1.4.x versions of KSP) is a bit disheartening. In your opinion, is the 1.3.1 version playable enough?

[severedsolo]

33 minutes ago, Tonas1997 said:

So I know this is a kind of a silly question, but here it goes anyways:

I'm playing on a 1.3.1 save, and I've been thinking about installing a part failure mod. Needless to say, this is the one which grabbed my attention the most 

However, while there is a compatible version on the repository, the ungodly amount of bug fixes which occured ever since (mainly for the 1.4.x versions of KSP) is a bit disheartening. In your opinion, is the 1.3.1 version playable enough?

Try RC1 - that's probably the best you'll get. It works (and probably is about as balanced as 1.3.5 is right now) - the "core mechanics" basically work, mostly the issues were with calculations being done badly (but the MM patches were set up to offset that, until I figured out what it was).