[0.90] TestFlight [0.4.6.1][04FEB15] -Configurable, extensible, parts research & reliability system

[Agathorn]

There is an annoying bug in KSP where sometimes the flight data isn't saved. In addition due to polling rates and what not its possible to lost a few bits and bytes of flight data after a flight. Which is why I wanted to know if the actual amount of data is reported the same in the VAB and Flight even when the reliability is being shown different.

In other words is it a matter of the "known data" changing between end of flight and the VAB, or is it a matter of the reliability calculations being bugged.

On my test branch where i'm incorporating the new MTBF system, so far stuff seems to be updating properly in my tests.

[Agathorn]

Experimental Release

https://github.com/jwvanderbeck/TestFlight/releases/tag/v0.4.0e4

This is an experimental release of a development branch. This version is released to allow people to test upcoming changes and should be considered unstable and buggy. Do not use an experimental release in any save you care about.

Highlights

Initial implementation of new Mean Time Between Failure (MTBF) system.

Due to major underlying data changes you must start a new saved game for this release, and do not use any previously saved craft files

Some things to understand about the new MTBF system.

1. MTBF does not mean time until failure. A MTBF of 60 seconds does not mean your part will fail in 60 seconds. It could fail well before 60s or well after 60s. But on average it will fail sometime around 60s. Maybe.
   
2. Probability is a ...... Just because something is highly unlikely does not mean it is impossible.
   
3. As a part's operating time approaches the MTBF its change to fail increases. Things are currently tuned so that at Operating Time = MTBF, the part has a 50% chance to fail.
   
4. 
   

Important testing in this update is "How does it feel?". I know this is subjective and everyone will have a different opinion, but please let me know how it feels to you. Both on early flights, and later flights once your parts have gained reliability. I have some knobs I can tune.

Also please note that I haven't done up any real configs yet, so right now every part has the same starting MTBF and the Flight Data -> Failure Rate conversion.

Change Log

• Initial implementation of new MTBF system
  
• MSD now shows MTBF
  
• MSD now shows Failure Rate
  
• Make font in MSD smaller, and adjusted window to accommodate new data
  
• Updated settings pane in MSD to remove no longer used settings, and rename/tweak ones that are left.
  

Edited January 23, 2015 by Agathorn

[Agathorn]

I'm wrapping up on initial implementation of a public interface that can be used by other mods to integrate with TestFlight. The next experimental release will have that initial implementation.

[Agathorn]

Experimental Release

https://github.com/jwvanderbeck/TestFlight/releases/tag/v0.4.0e5

This is an experimental release of a development branch. This version is released to allow people to test upcoming changes and should be considered unstable and buggy. Do not use an experimental release in any save you care about.

Change Log

• New Reflection Interface for other mods to integrate with TestFlight. This is still a WIP and feedback is more than welcome.
  
• Fix issue #11 - Settings Dropdown List hard to read
  
• Fix issues #14 - Data rate multiplier being incorrectly applied and giving zillions of data units (or none!)
  
• New API methods to allow repairs to take time to complete
  

Edited January 23, 2015 by Agathorn

[Agathorn]

Has anyone had a chance to try out the new versions? I'd like to get some feedback on how they are working so I can move towards rolling the changes back into the master branch. Thanks!

[razark]

Sorry, I haven't had a chance to play lately. In fact, I'd barely had a chance to use 0.4.0e4. Hopefully I'll get some time tonight or tomorrow to test this out.

[seronis]

First time seeing this mod. Not installing it just yet but its one I really want to start using eventually. Right now im polishing up my general craft design skills since Im a newb who just finally learned how dV works and the diff between Ap and Pe.

[razark]

Bad news. It looks like any testing is going to face further delay. The wife just surprised me with a brand new computer to replace the 2007 beast I've been using.

I'm going to have to spend time transferring my life from one machine to the other.

Not installing it just yet but its one I really want to start using eventually.

Come on... install it! From the last few pages, it looks like I'm the only one using it, and the more testers, the better.

[Agathorn]

First time seeing this mod. Not installing it just yet but its one I really want to start using eventually. Right now im polishing up my general craft design skills since Im a newb who just finally learned how dV works and the diff between Ap and Pe.

Fair enough. No sense making things even harder while you are still learning.

- - - Updated - - -

Bad news. It looks like any testing is going to face further delay. The wife just surprised me with a brand new computer to replace the 2007 beast I've been using.

I'm going to have to spend time transferring my life from one machine to the other.

Come on... install it! From the last few pages, it looks like I'm the only one using it, and the more testers, the better.

Haha that sounds like a good thing for you not a bad one

[Agathorn]

Experimental Release

https://github.com/jwvanderbeck/TestFlight/releases/tag/v0.4.0e6

This is an experimental release of a development branch. This version is released to allow people to test upcoming changes and should be considered unstable and buggy. Do not use an experimental release in any save you care about.

Change Log

• Expanded Reflection Interface and API
  
• MSD can now show failure rate in addtion to MTBF
  
• failure rate in MSD now properly shows the 'worst' momentary failure rate
  
• DataRecorder modules can now control when a part is considered "operating"
  
• Mission time is now calculated from activation of first stage, not from MET which KSP does not start until you leave the pad. This means two main things.
  
  • Engine test stands are a thing
    
  • The practice of igniting your first stage before releasing the launch clamps is a good one, to ensure you engine(s) are ignited and running properly.
    

  [*] Added new Reliability module that increase the failure rate of an engine for the first 5 seconds after ignition. This is also a sample of the power of the new system to do things like this! Currently enabled on liquid engines.

[Agathorn]

Experimental Release

https://github.com/jwvanderbeck/TestFlight/releases/tag/v0.4.0e7

This is an experimental release of a development branch. This version is released to allow people to test upcoming changes and should be considered unstable and buggy. Do not use an experimental release in any save you care about.

Change Log

• Added new API methods to control flow of Flight Data
  
  • SetDataRateLimit()
    
  • SetDataCap()
    

This will *most* likely be the final experimental for v0.4. I might try to get the contracts stuff in there as well, but I think i'm pushing this branch already, and its about time to roll it back into the master.

[NonWonderDog]

I haven't had a chance to play the game really at all, but your failure check seems pretty harsh. It's got an exponentially increasing *chance* (not rate) of failure, and after the "MTBF" time parts have a 50% chance of failing every five seconds. That's probably fun for testing the mod, but seems like it would be impossibly aggravating if you were to play with this mod on all the time.

For a "correct" MTBF implementation this:

survivalChance = Mathf.Pow(Mathf.Exp(1), currentFailureRate * operatingTime * -0.693f);

should probably be:

survivalChance = Mathf.Exp(-currentFailureRate * (operatingTime-lastcheck));

or equivalently:

protected double lastReliability = 1;
protected double currentFailureRate = 1/MTBF;

public double reliability(operatingTime) {
    // assuming MTBF and operatingTime are in the same units
    return Mathf.Exp(-currentFailureRate * operatingTime);
}

...

    r = reliability(operatingTime);
    survivalChance = r / lastReliability ;
    lastReliability = r;

That would give a perfectly constant chance of failure over time, no matter how often you check (with max reliability in the last case set by the resolution of "Random.value", unless you can use "Random.NextDouble()"?). If you wanted a different failure distribution you could just extend the class and change the reliability function.

If I went that route I'd probably also make it ignore all failures past the first when resuming from time acceleration, as a difficulty option. Just so things don't get out of hand.

(I don't have any experience with C# or Unity; is there some reason you're using "Mathf.Pow(Mathf.Exp(1),...)" instead of "Mathf.Exp(...)"?)

Edited January 26, 2015 by NonWonderDog
fixed a silly mistake in the third snippet

[Agathorn]

Well I didn't implement it "correct" because I made alterations for gameplay. I don't really want a constant chance of failure, I do want the chance of failure to increase the closer you get to MTBF.

Am I misunderstanding you?

[tater]

This looks pretty darn cool. I'm gonna grab this and mess around.

What parts are affected? Looks like tanks and engines, correct?

I'd like to see RCS lock up, or lock ON in one vernier? (like Gemini 8) Chutes… gear. Or lose/mitigate SAS.

It might be neat if any of the otherwise dumb "run test" contracts could supply extra units of data, then they'd not be entirely pointless grinds (some would clearly remain bizarre, lol).

[Agathorn]

This looks pretty darn cool. I'm gonna grab this and mess around.

What parts are affected? Looks like tanks and engines, correct?

I'd like to see RCS lock up, or lock ON in one vernier? (like Gemini 8) Chutes… gear. Or lose/mitigate SAS.

It might be neat if any of the otherwise dumb "run test" contracts could supply extra units of data, then they'd not be entirely pointless grinds (some would clearly remain bizarre, lol).

Right now the configs for parts are more testing than anything else. Attaches to engines, and tanks. That includes RCS.

As for contracts I have on my wish list to integrate into contracts.

[tater]

Very cool. I'll install and maybe play tonight.

[tater]

Played a little (version 3?). Failure happens rather a lot.

I did maybe 6 flights in a new career, and I had multiple failures per flight. Leaks, lower thrust, mostly.

Do part classes start off as very unreliable, then get very reliable after time? The individual parts that are flying a long time then get less reliable again as they approach the MTBF?

I was thinking that for me, what I'd like to see is this (and it might be impossible, I'm just saying what I'd like):

A class of part would have some % chance of a design failure. Once that failure happens, then you reduce the chances of that failure ever happening in future parts of the same type. The overall chance of a new (different) failure with that part would then be set very low. If a 2d failure occurs, that gets a design change. All this is separate from MTBF events near the end of life of a given part. This is for classes of parts.

Failures should be rare, in other words, and your space program should be able to learn from them, and correct them.

[Agathorn]

Played a little (version 3?). Failure happens rather a lot.

I did maybe 6 flights in a new career, and I had multiple failures per flight. Leaks, lower thrust, mostly.

Do part classes start off as very unreliable, then get very reliable after time? The individual parts that are flying a long time then get less reliable again as they approach the MTBF?

I was thinking that for me, what I'd like to see is this (and it might be impossible, I'm just saying what I'd like):

A class of part would have some % chance of a design failure. Once that failure happens, then you reduce the chances of that failure ever happening in future parts of the same type. The overall chance of a new (different) failure with that part would then be set very low. If a 2d failure occurs, that gets a design change. All this is separate from MTBF events near the end of life of a given part. This is for classes of parts.

Failures should be rare, in other words, and your space program should be able to learn from them, and correct them.

Hi Tater,

They definitely get more reliable the more you fly, but also bear in mind its all being tuned so nothing is final yet

[tater]

Yeah, I get it.

I want failures, but I want them to be not terribly frequent, and then future parts are even less likely to fail assuming you diagnose the problem (perhaps a job for an engineer? Dunno if that is accessible to mods, but that might be interesting).

[NathanKell]

Said it in IRC, I'll say it here. Cool beans, man.

[Agathorn]

Yeah, I get it.

I want failures, but I want them to be not terribly frequent, and then future parts are even less likely to fail assuming you diagnose the problem (perhaps a job for an engineer? Dunno if that is accessible to mods, but that might be interesting).

Like I said that is pretty much what it models. Not on the case of a specific failure like you mention, its more abstract than that, but it builds up and gets better and better over time. Having engineers on board does make them get more reliable faster yes

[tater]

Awesome. Will keep messing around

[Agathorn]

Awesome. Will keep messing around

Right now i'm kind of bogged down in migrating everything over to CI and automated builds, but once i've finished that I will be making some more tweaks to the failure rates.

[Headhunter09]

Don't know any of these have been mentioned before, but here some possible failure modes for the future:

- control surfaces get stuck

- batteries lose their ability to recharge/discharge

- solar panels don't open

- solar panels don't close

- solar panel doesn't charge

- wheel failures: steering lock, motor stuck on, draws way more power than it should

- antennas draw more power/get stuck closed or open

Basically any toggleable animated state should be able to get stuck. Manually setting it with an EVA should be possible though (or maybe only sometimes).

[tater]

Nice list. I also like the fact that many of these might be repaired by engineers, giving them something useful to do.