[WIP] [Dev thread] Dang it! A random failures mod

[Paul Kingtiger]

Hi Ippo,

Loving this mod, you've struck a really good balance between having to worry about reliability without over complicating things. Couple of suggestions.

Are you planning to add a UI component during flight that shows the likely reliability of each part, for example the MTBF / Time since last failure. Or some other metric that gives you an idea of how likely the part is to fail without telling you exactly if it will or not.

Secondly how about adjusting part reliability based on how many times it's been used (mostly for career mode I think) so that newly unlocked parts would be less reliable, becoming more so as the part is ether used more or time passes since it was unlocked. This would model ironing out the kinks of a new part and give the older parts a small advantage over newly unlocked but more advanced parts.

[Ippo]

Are you planning to add a UI component during flight that shows the likely reliability of each part, for example the MTBF / Time since last failure. Or some other metric that gives you an idea of how likely the part is to fail without telling you exactly if it will or not.

At one point, definitely. In alpha 3 I'll need a gui anyway, so I'll throw something in. I am still to decide exactly what values you should see though: my original idea was to have every part glow in a shade from green to red according to how worn out it was, but I've seen that not everyone is so fond of the glow, so we'll need an alternative.

Maybe I could show the percentage of the current MTBF over the original one, plus some random noise to simulate uncertainty?

Secondly how about adjusting part reliability based on how many times it's been used (mostly for career mode I think) so that newly unlocked parts would be less reliable, becoming more so as the part is ether used more or time passes since it was unlocked. This would model ironing out the kinks of a new part and give the older parts a small advantage over newly unlocked but more advanced parts.

Well, this is an interesting suggestion. I'm not really sure how that could be implemented, but it might be a little too realistic anyway. I'll think about it (of course, I'll also consider the feedback in this thread: if everybody loves your idea then I'll get to it).

[IsamuHigashi]

At one point, definitely. In alpha 3 I'll need a gui anyway, so I'll throw something in. I am still to decide exactly what values you should see though: my original idea was to have every part glow in a shade from green to red according to how worn out it was, but I've seen that not everyone is so fond of the glow, so we'll need an alternative.

Maybe I could show the percentage of the current MTBF over the original one, plus some random noise to simulate uncertainty?

Well, this is an interesting suggestion. I'm not really sure how that could be implemented, but it might be a little too realistic anyway. I'll think about it (of course, I'll also consider the feedback in this thread: if everybody loves your idea then I'll get to it).

Hallo since i like the mod a loot i thought id throwin my thouthgs on this as well.

In Regards to nummber one i would rather have a Display giving me the data kinda like in the VAB just updatet to the current Level as a Glowing Rocket just fells kinda wrong in my opinion.

It could also be Intresting to fife the Player Aditional Information if he takes a look at it with a Kerbel, for Exempel (i know this might be Difficult to do ireally dont knbow mutch about coding so i will just gife my opinion) a Failure astimate from the Kerbel and the Precicion of witch would be depended on the Inteligence of that Kerbel.

For Exempel it will say that the Kerbel X thinks that its likly for the Part to break within X Hours but should be fine for the next XHours of use, kinda like a Precieser value of the MTBF or somthing.

Also is if read you want to ad Servicing Parts to prevent defekts that would be a good combination you could look at the Parts really quick and then plane the Next Service of the Rocket (maybe make it so that you need a service station to perform Maintanece)

Sorry if im taking it to far just tell me to stop i get carried away easaly when im Excietet xD.

About Nummber 2 i think its a great idea but it should be that the Part at the beginning is more likly to brake, and over time (be it depended on use or how long ago you unlocked it)it would come to the Current Levl and not that it Starts at the Current one and then goes further up.

For further increasing the Reliability the best Option Would be (as many have wrote i guess, and you already sayd its comming so sorry for mentening it again) that you have to Spend more Money on it when 0.24 comes out with the Budget.

Hope some of the Ideas are usefull.

(BTW please go easy on me with Writing mistakes im not a naitive and my skills are coming only from the Internet and Speaking it, so theres not mutch writing Practice in there)

[Paul Kingtiger]

The glowing UI would be ok if it was an toggleable option using a toolbar button. Switch on to check, turn off once you're done. I agree that glowing all the time would be annoying.

A mouse over UI like the VAB would provide good data, but it would be really annoying to mouse over every part of a 100 part craft in flight. With the glow you can quickly check the entire thing.

A nice effect of the in flight UI is that you could carry out preventative maintenance by fixing an unbroken part to reset the clock. Say you're about to launch from the mod and you notice your engine is red. You'd send the kerbal out to fix it back to green before launch to reduce the chance of failure during the take off burn.

[Ippo]

The glowing UI would be ok if it was an toggleable option using a toolbar button. Switch on to check, turn off once you're done. I agree that glowing all the time would be annoying.

Well of course it wouldn't be all the time, but only on request. What I mean is that some people don't like the glow at all and asked me to disable it even for failed parts, so as cool as it is imho it wouldn't fit the taste of everyone, that's why I need to think of an alternative.

EDIT: btw, inspections and pre-emptive maintenance is already planned for alpha 3.

[IsamuHigashi]

Well of course it wouldn't be all the time, but only on request. What I mean is that some people don't like the glow at all and asked me to disable it even for failed parts, so as cool as it is imho it wouldn't fit the taste of everyone, that's why I need to think of an alternative.

EDIT: btw, inspections and pre-emptive maintenance is already planned for alpha 3.

How about making a Window that you can Open where all the Parts are Listet in and then Color the Text in regards to the Status of the Part for Peopel that dont want it to be on the Rocket, Problem will be thoe how to find that Part on the rocket if you have several similar Parts, unless it would be possible to highlight the Object if you hower over the Name of the part on the window.

(BTW with the VAB style window i meant to put it together in a log or somyhing like the window above just with the current values vor MTBF and How long you used the Part especialy usefull for engins i think, and then the color of the Text tells you the current Status)

[Cleric2145]

I like the red shading, I would just prefer it to fade/disappear after a period of time.

[DerTroglodyt]

While you're at adding ModuleEngineFX could you also add ProceduralPart to Tanks please. I do like the clean looks of them but would also like to have your great mod affect them.

From the procedural parts config I guess that's what needs adding in your tanks module:

MODULE

{

name = ProceduralPart

Thanks a lot for your work anyway. Looking forward for more features.

[mic_e]

This mod looks like it would add quite a nice touch to my gameplay experience; I'll probably use it in my .24 playthrough.

I think this mod and Deadly Reentry could benefit greatly from each other. Most of the masochists who will end up using this are probably also using DRE, so I think discussing some cross-support with NathanKell would be a great idea.

- G-Forces, high temperatures and high static/dynamic pressures could/should accelerate part aging and/or increase failure probability.

- Failed or duct-taped parts should have lower G-Force and temperature tolerances.

(Personally, I think it's time for a 'base mod' that generally handles part damage/aging/... instead of every mod having its own damage system, but that's a little out of scope here.)

(Sorry if this was suggested before; I didn't read through all posts of both threads.)

Edited June 18, 2014 by mic_e

[Ippo]

I like the red shading, I would just prefer it to fade/disappear after a period of time.

Mmm. That's definitely cool but doesn't fit nicely in my code right now, but this is definitely in the top part of the suggestions list

While you're at adding ModuleEngineFX could you also add ProceduralPart to Tanks please.

ModuleEngineFX will be supported ASAP because it is part of the stock game: unfortunately, support for other mods will have to wait until I sort the stock out.

Anyway, I'm not using procedural parts but I downloaded it to take a quick look at its cfgs. Right now it's not detected because technically those tanks don't have a RESOURCE in them, my guess is that they load it at runtime and therefore my mod doesn't detect them as tanks.

You MIGHT be able to fix it with the following cfg file. WARNING: I didn't test it, I'm not going to, and I'm not going to support it if it doesn't work. So yeah... your own risk, at the moment.

@PART:HAS[MODULE[ProceduralPart]]:AFTER[ProceduralParts]
{
    MODULE
    {
        name = ModuleTankReliability
        MTBF = 48000
        LifeTime = 100000
        RepairCost = 1
        MinTC = 60
        MaxTC = 240
        Silent = false
    }
}

[DerTroglodyt]

Thanks for pointing me in the right direction. After quite some poking around I settled on adding the following to the tanks config:

@PART[proceduralTank*]:FOR[DangIt]

{

MODULE

{

name = ModuleTankReliability

MTBF = 48000

LifeTime = 100000

RepairCost = 1

MinTC = 60

MaxTC = 240

Silent = false

}

}

Reliability now shows up in VAB but has no "puncture" menu item on part when started. Any ideas?

Also I tried to change the battery config:

@PART[proceduralBattery]:FOR[DangIt]

{

MODULE

{

name = ModuleBatteryReliability

MTBF = 16000

LifeTime = 100000

RepairCost = 1

Silent = false

}

}

Which messes up world grafics the same way as adding EngineFX to engines config. So I guess you have to add it to code anywhere. Would be great if you would consider this.

Another suggestion: Could you add some text file "verion" with just the version number in it for reference. I downloaded your mod just yesterday and already can't remember the version I downloaded. Should make life easier for you when sifting through bug reports. ;-)

[Ippo]

...

Yes, these kind of ideas has already been floating around.

Personally I'm not a huge fan of "realism for the sake for realism", and also I don't want to tailor my mod only for the super-realism freaks.

That said, personally I would only consider the temperature of the part, and ignore the G force: ok, they are kerbals, but it's still a space program, so Gs are (theoretically) accounted for in the design. But I'll see about that: does anybody know how I can remove the poll? I want to make a new one and don't know how ^^

[Ippo]

Reliability now shows up in VAB but has no "puncture" menu item on part when started. Any ideas?

Yes, unfortunately. The reliability module looks for resources to leak, can't find them for some reason and so shuts down the same way it does on engines.

Considering what you also said for batteries, I'm afraid that means I will need specific modules to support Procedural Parts. Sorry, no luck

Another suggestion: Could you add some text file "verion" with just the version number in it for reference. I downloaded your mod just yesterday and already can't remember the version I downloaded. Should make life easier for you when sifting through bug reports. ;-)

Actually the logs are the only place I didn't put the version for some reason

If you downloaded yesterday you most likely have Alpha 2.2. Also, windows (or your file manager) should show you the DLL version (0.0.2.2). Finally, if you have a folder called PluginData inside my download, then it's definitely Alpha 2.2 (but I could already tell from the buffed MTBF)

[MissionController3134]

It says that this mod is not compatible with FAR... Why is that? It doesn't seem like anything in the two should conflict.

[Ippo]

Ok everyone, with 2.2 most of the bugs seem fixed (there seem to be some small stuff coming but it's nothing serious), so now it's time to plan things for Alpha 3 and I want to hear your feedback on my plans for it.

Inspections:

Inspections are free to perform: they don't cost any spare part but they don't have any permanent effect.

What they do, instead, is grant you a temporary reliability bonus so that you can carry out some critical manouvre with less to worry about.

In the code, the MTBF is translated to a failure chance for every frame: what an inspection will do is multiply this failure chance by a coefficient going from 0 to 1 over time. Basically, immediately after performing an inspection the failure chance is zero, and after a short time T it returns to its normal value.

Maintenance:

Maintenance is like an inspection in the sense that it can be carried out only on parts that haven't failed yet. It does, however, cost some spare parts (I was thinking 1 spare part for everything and let's call it a day) and have a permanent effect on the part's age, thus a permanent increase in reliability*.

For example, each module could have a coefficient between 0 and 1 and when you do the pre-emptive maintenance on it you subtract this fraction of the part's age. So if a module has a coefficient of 0.3, at each maintenance the part gets its age reduced by 30%.

The cost also has the function to discourage spamming the maintenance: however, it might be best to add a minimum time between maintenance to prevent the player from completely restoring the part to factory conditions, if they are willing to shell out enough resources.

Reliability monitor:

A window, visible in flight, to get the current status of your ship.

I really like the idea of having the whole ship glow (temporarily, of course), each part with a different colour depending on how reliable they are.

However, some people don't like the glowing stuff (buzzkills), so we'll also need a text-only list.

Alternative: should the reliability be only shown to the player when the kerbal performs the EVA inspection? This second option might be more realistic, but personally I think it makes for a much slower gameplay.

And the big stuff: PERKS

As I announced previously, I'm going to implement a perk system. Regarding this part unfortunately your feedback will matter only so much, basically because of technical limitations (I'm writing down my own system as we go, and it can't do much at the moment).

This perk model will have a ton of limitations: I just need it as a starting point, also it doesn't really make much sense without budgets and therefore the possibility of investing in training. Anyway, the first release will see:

• Only 2 perk lines: Electrician and Mechanic. Each perk will have 3 tiers (maybe more but I don't see the point).
  
• Each failure module will have perk requirements: either none, one of the two, or both. This will be an intrinsic property of the failure module and will not change at each new failure.
  
• The perk's tier will give repair bonuses: see below.
  
• Each kerbal is spawned with his own set of perks that cannot change during his life (again, budgets)
  

As for the perk bonuses, I was thinking these tiers:

[TABLE=width: 500, align: center]

[TR]

[TD=align: center]Tier[/TD]

[TD=align: center]Inspection[/TD]

[TD=align: center]Maintenance bonus[/TD]

[TD=align: center]Repair[/TD]

[/TR]

[TR]

[TD=align: center]Unskilled[/TD]

[TD=align: center]Cannot see the reliability stats[/TD]

[TD=align: center]Smaller[/TD]

[TD]

No repair cost discount.

Sometimes the repair might fail.

[/TD]

[/TR]

[TR]

[TD=align: center]Normal[/TD]

[TD=align: center]Can see limited reliability stats[/TD]

[TD=align: center]Normal[/TD]

[TD]

Smaller repair cost discount.

Rarely, the repair will fail.

[/TD]

[/TR]

[TR]

[TD=align: center]Skilled[/TD]

[TD=align: center]Can see full reliability stats[/TD]

[TD=align: center]Larger[/TD]

[TD]

Larger repair cost discount.

The repair can always be performed

[/TD]

[/TR]

[/TABLE]

When I say that the repair fails, I mean that the kerbal tries to fix it and doesn't make it. The part remains broken, but the spare parts are consumed. After that, the same kerbal may try again (provided he has the resources).

... so... comments?

Edited June 19, 2014 by Ippo

[Ippo]

It says that this mod is not compatible with FAR... Why is that? It doesn't seem like anything in the two should conflict.

FAR remove the Control Surface module and replaces it with its own version, which in turn causes a NullReferenceException in my control surface code.

I need to specify that actually it's the only problem: removing the control surface cfg makes it work (without control surface problems, ofc)

[SaSquatch]

Suggestion for the Blacklist. WasteHeat from Interstellar mod.

Also, I don't mean to be making requests but... A special request to make the failures actiongroup compatible? I'm doing a video of a quasi Shuttle abort mode and I have to use a editing trick to get the engine failure while staying in IVA.

[Ippo]

A special request to make the failures actiongroup compatible?

Hmm. Well I hadn't really thought of that because those events are supposed to be hidden in the end, you are only seeing them for testing.

I'll get to it just in case.

[SaSquatch]

It is an unusual thing... when they are hidden for it would almost be a debug mode sort of thing. Not exactly a simple request in the end that wouldn't necessarily be worth the time considering almost nobody would actually use it.

[Athlonic]

Plans for Alpha 3 sounds just perfect to me.

Keep up the good work.

[Tiberius]

This looks great Ippo! I'm completely in love with the concept.

The perks are for Kerbals, like the default Courage and Stupidity? So it will be randomly generated at the Astronaut Academy, I'm guessing. The idea of sending a dedicated technician on-board is fantastic. Also your should make it so the chances of a Kerbal being proficient in both Maintenance and Inspection is low. Requires more of a balancing act.

Also I have an idea on how to treat unmanned probes more fairly. They can't be repaired, because all the Kerbals are millions of km away and it would be cheaper to send a new satellite than send a repair crew. It could be assumed most probes are one of a kind and have a much higher degree of tolerance compared to manned spacecraft like the Shuttle and Apollo. Also probes can't really take advantage of the Inspection boost. Its hard to inspect a probe on top of a rocket on the launchpad, and sending them to an orbital station for Inspection is almost laughable.

If its technically possible, could the mod check if Kerbals are onboard the vessel at flight screen, and if not, assume the craft is an unmanned probe, and increase the integrity of all the probes parts. This way probes get some of the advantages, without becoming a less optimal tool in the game (as they are in vanilla).

I actually downloaded your mod to use with probes! Two antennas on my craft. Disaster strikes and the long range antenna capable of reaching Kerbin breaks near Jool. Dead in the water, my low gain antenna attempts to make sporadic contact with the Jool communication constellation. Contact fades in and out as the satellites designed for Laythe communication ping back commands from the probe and Kerbin. I love these scenarios!

PLEASE make antennas (for use in RemoteTech) and solar panels failable!

[Ippo]

The perks are for Kerbals, like the default Courage and Stupidity? So it will be randomly generated at the Astronaut Academy, I'm guessing. [...] Also your should make it so the chances of a Kerbal being proficient in both Maintenance and Inspection is low. Requires more of a balancing act.

Correct: perks become an individual property of kerbals, exactly like their courage and stupidity. Code-wise it's a little more complicated than that, but yes, they are randomly generated in the academy (technically, the first time that the kerbal is identified by my system).

I hadn't thought about separating the proficiency in maintenance and inspection, to be honest: it sounds a little complicated to me, but well, that's why I asked for feedback in the first place... if enough people think this is a better idea, I'll ditch mine.

Also I have an idea on how to treat unmanned probes more fairly. [...]

Yes, probes will be tough to balance. On one hand, it kinda seems unfair that the same component is better built for a probe than for a manned mission... on the other hand, probes are already a little under-powered in game, so it's really complicated.

I guess that an "unmanned boost" is the easiest way to go.

PLEASE make antennas (for use in RemoteTech) and solar panels failable!

Soonâ„¢

Since we are bringing up RemoteTech: I'd love to use it to check if we have a com link to the KSC and having the worst failures, like engines, require the com link. Unfortunately I see that remote tech is on hiatus, so I'm not in love with the idea of an outdated dependency.

[SaSquatch]

Or use RemoteTech link to determine if a probe is "unmanned" for efficiency. Bring a old probe back online to discover all of the new problems it has to deal with.

[Ippo]

Or use RemoteTech link to determine if a probe is "unmanned" for efficiency. Bring a old probe back online to discover all of the new problems it has to deal with.

Actually, it's just a matter of checking (part.vessel.GetCrewCount() > 0)

[SaSquatch]

I was thinking more thematically then technically how to do it. "No Connection" state equivalent to unmanned, while a "Connection" equals a "manned" vehicle. Thematically... establish a connection to a probe for the first time in months or years to discover all of the issues that have popped up since it went silent.