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

[Agathorn]

The thing that will make this mod hard, and the reason why I said you'd need an understanding of the literature, is the randomness. If you try to balance it by play, you will simply never get a good result. You have to have a a result in mind and the ability to implement it, and then have the willingness to ignore people (or yourself!) who complain that their engines fail every launch or never fail at all. You have to design the reliability of the entire population of RT-10 boosters amongst all players, and trust that individual RT-10 failures follow the pattern.

Trust me I have no problems with this. It really is the whole point, and as long as the code is working properly (IE there isn't a math or logic error) then all is good. It is the desired end result anyway!

To that end, you have to understand real failure distributions, and the math needed to model them. It's actually not that bad as long as you keep things simple.

If we take the simplest case, say we have 1000 widgets, and 10% of them fail each day. 100 widgets will fail the first day. There are only 900 left, so 90 widgets will fail the second day. 81 will fail on the third, 73 on the fourth, etc. As you see, the simplest model has an exponential failure distribution. This constant risk of failure -- a constant hazard rate -- is the basic assumption behind the Mean Time Between Failures metric.

The hazard rate h(t) is actually somewhat of an abstract concept in order to account for non-constant rates. It's equal to the expected number of failures in a population divided by all the accumulated time of all the items in the population, over an infinitesimal time slice, given that every item in the population is t hours old. Stated in a way that actually makes sense, the probability of an item experiencing its first failure over the next dt hours, starting at time t, is equal to h(t)*dt as dt approaches zero.

But for an exponential distribution, it's easy. The math works like this:

Hazard rate is constant, so let's call it lambda. MTBF is equal to 1/lambda for an exponential distribution. Hazard rate can be estimated directly from a sample population (the measured failure rate): if there are 10 failures in a sample of 100 devices scheduled to operate for 100 hours each, the hazard rate is 10/(100*100) = 0.001 -- A MTBF of 1000 hours.

The probability of a failure at time t (divided by duration) is f(t) = lambda*e^-(lambda*t). This is the failure density function. (10% of widgets fail each day (lambda = 0.1), 100 fail on the first day (f(0) = 0.1), 90 on the second day (f(1) = 0.09)), 81 on the third day (f(2) = 0.081), etc.)

The probability that that item will have failed after t hours is the integral of the density function, F(t) = 1 - e^-(lambda*t). This is the failure distribution function. F(infinity) is equal to one.

The probability that an individual item will survive is one minus that, or R(t) = e^-(lambda*t). This is the reliability after t hours.

With our 1000 hour MTBF, the probability that any individual item will survive for 100 hours is:

R(100) = e^(-0.001*100) = 90.5%

The probability that it survives for 1000 hours is:

R(1000) = e^(-0.001*1000) = 36.8% (Yes, 63.2% of our samples have failed after the mean time between failures. Math is weird.)

And honestly, if you don't go beyond an exponential failure distribution that's all you need. The probability of surviving for the next 1000 hours is 36.8% no matter how many thousands of hours it has survived so far, so you can just use the reliability function and be done with it. Only thing to keep in mind is possible numerical precision issues past 100,000 hours MTBF, and any fiddling you might have to do to get all the bits out of Unity's RNG.

Wow thanks for that. I was doing a lot of reading over the last bit since your first post, and I see now that I was getting close but this really, really helps cement things for me.

Things get a lot more difficult with a variable hazard rate. If I'm feeling particularly brave I'll try to work out the math for a Weibull distribution, since front-loaded failures would make launches a bit more exiting, but I'll ignore wear-out as probably a bad idea for gameplay.

I don't think that will be necessary though I appreciate the offer. While I want to make the system as good as I can, I don't necessarily want to 100% accurately model reality. I think what we have here will be good enough. Also bear in mind that we will be cheating a bit, as we are in essence front-loading the determination of a failure rate. In other words in the real world parts are tested and from those tests a failure rate is determined. But for our cases, we are generating a failure rate right from the start, before any parts are used (though this will start from a base configured number that feels right), but further more we are making them more reliable over time based on the amount of flight data accumulated from test flights. So we are fudging the other end of the system, and then using all the fun math above to help determine based on the derived numbers, whether a failure has occurred or not.

In the most general case, I think you only need the reliability at time t (when you last checked), the reliability at time t+dt (now), and Bayes' theorem to determine if something should fail. You should be able to foist the reliability calculation itself off on another module. (At least, that's how I remember probability working. I'll have to run through that.) I get incredibly confused when I think about the *second* failure using that method, though...

Don't worry about second failures. We will assume that once a part is repaired, if it is, that it is as good as when it was launched. You've been so very helpful and I appreciate it, but I have to ask for one more thing which seems like it should be obvious, but as I said i'm just not a maths guy, and certainly not a statistics guy. How would I be using Bayes' Theorem in this? Are we talking something like P(t)=P(dt)*P(t)/P(dt) ?

[Agathorn]

Ok so I am fairly certain that GUI Experimental 2 is ready to go. I'm taking a short break before jumping in on some testing. Assuming I don't find any issues, I should be cutting a release within a couple hours.

[Agathorn]

v0.2.1 experimental 2

https://github.com/jwvanderbeck/TestFlight/releases/tag/v0.2.1e2

This is an EXPERIMENTAL release. Experimental releases are very much "development snapshots" and are released for the express purpose of getting user feedback or testing on a very specific bug or feature that is being worked on. If testing an experimental release, please limit feedback to the scope of that release.

This is an alpha release and thus should be assumed to be buggy, and capable of breaking your game and game saves.

Experimental release of the new reworked GUI. This is still very much a WIP.

This release implements the new TestFlight GUI skin, addresses issues in Experimental 1, and adds a new compact Flight HUD.

• New TestFlight GUI Theme designed for clarity
  
• Settings pane is now split into multiple "sections", each of which can be selected from the drop down list at the top of the settings pane.
  
• The Master Status Display now has a maximum height for display of the part status. If too many parts need to be displayed, the GUI will start to scroll instead.
  
• Added scroll view for Part Display
  
• Added filter to show only failed parts in Master Status Display
  
• Added setting to set size of scroll view in one of three increments, Small, Normal, or Large
  
• Added setting to hide/show flight data on part
  
• Added setting to hide/show resting reliability on part
  
• Added setting to hide/show momentary reliability on part
  
• Added setting to hide/show part status text
  
• Added setting to truncate/shorten display names for parts
  
• Added setting to lock/unlock the Master Status Display window
  
• Added setting to enable/disable the compact Flight HUD
  
• Added new compact Flight HUD which displays *only* the parts that have failed, and a repair button. Part names are colored for quick identification of the severity of the failure. Green = Minor, Yellow = Normal, Red = Critical
  
• Moving the Master Status Display (after unlocking it) now saves the window's position
  
• Moving the Flight HUD save's the windows position
  

- - - Updated - - -

Proposal For Reliability and Failure System Redesign

https://github.com/jwvanderbeck/TestFlight/wiki/Proposal-For-Reliability-and-Failure-System-Redesign

[NonWonderDog]

Here's the Bayes' Theorem explanation:

What you really need probability wise is the reliability of a part over time dt, starting at time t. You can compute this directly, but you have to know the details of the probability density distribution and take an integral, and you don't want that.

For whatever failure distribution a part has, it's fairly trivial to compute R(t), or the probability of survival between 0 and any time t. For specificity's sake we can also call this R(0,t). So you can get R(0,t) and R(0,t+dt) directly just by calling the reliability function once every dt.

But we need R(t,t+dt), which is a conditional probability. What is the probability that, given no failure at time t, that there will continue to be no failure at time t+dt?

Bayes' Theorem is P(A| = P(B|A) * P(A) / P(.

A is no failure over (t,t+dt). B is no failure over (0,t). P(B|A) is... well, it turns out that P(B|A)*P(A) is equal to P(A∩, the probability of the intersection of events A and B. The intersection of events A and B simply means no failure over (0,t+dt).

R(t,t+dt) = R(t+dt) / R(t)

Okay, that was all kind of mean of me. All you have to do is divide.

[razark]

v0.2.1 experimental 2

I like the new HUD, and the look of the new MSD window.

Does a 100% reliability mean there's no chance for a failure? If so, it might be good to have an option to hide those parts that can't fail.

Suggestion: Add a warning tone when a part fails.

Issues noted:

Option: "Short Failed Parts Only", believe this should say "Show Failed..."

Settings Pane Selection: The background is transparent. I found it slightly hard to read with the test below showing through.

Slider: "Minimum Time Between Failure Checks" does not fit the space provided, and is slightly truncated by the slider.

HUD: I'd suggest either adding the failure type to the window, or the pop-up that lists repair conditions.

HUD: If I can't repair a part, instead of the "R" button, can it display another button to acknowledge the status and clear it from the HUD?

Does the Momentary Reliability field mean anything right now, or is it a placeholder for later expansion?

Edited January 8, 2015 by razark

[Agathorn]

I like the new HUD, and the look of the new MSD window.

Does a 100% reliability mean there's no chance for a failure? If so, it might be good to have an option to hide those parts that can't fail.

Right now it probably does but that whole system is getting rewritten so.. Your point is valid though and I will keep it in mind.

Suggestion: Add a warning tone when a part fails.

I do want to do something like this, as well as better communicate the fact that a failure has occurred. I need to do more research on *how* to actually do that though

Issues noted:

Option: "Short Failed Parts Only", believe this should say "Show Failed..."

Copy/paste yay!

Settings Pane Selection: The background is transparent. I found it slightly hard to read with the test below showing through.

Noted. I noticed this myself but not sure at the moment how to fix it.

Slider: "Minimum Time Between Failure Checks" does not fit the space provided, and is slightly truncated by the slider.

This slider will be going away so I didn't bother making the window wider still.

HUD: I'd suggest either adding the failure type to the window, or the pop-up that lists repair conditions.

I'll add it to the tooltip. There are some more things I want to do with this window as well, but I want to keep it as small as possible.

HUD: If I can't repair a part, instead of the "R" button, can it display another button to acknowledge the status and clear it from the HUD?

Very good suggestion. I didn't even think of that.

Does the Momentary Reliability field mean anything right now, or is it a placeholder for later expansion?

Placeholder

Thanks for the feedback!

[Agathorn]

I have found a bug that is causing the saved window positions to get reset when leaving the Flight scene. Trying to track it down now.

[razark]

I have found a bug that is causing the saved window positions to get reset when leaving the Flight scene. Trying to track it down now.

I hadn't noticed when I made my last post, but I did later. Glad to know the minor annoyance will be fixed.

One more: Is there a way to see part reliability numbers in the VAB? It would be useful to know how much I can count on the parts I'm using while building. Bonus if it let me know numbers for situations the part has flown in vs. a more general idea of untested situations.

[Agathorn]

I hadn't noticed when I made my last post, but I did later. Glad to know the minor annoyance will be fixed.

One more: Is there a way to see part reliability numbers in the VAB? It would be useful to know how much I can count on the parts I'm using while building. Bonus if it let me know numbers for situations the part has flown in vs. a more general idea of untested situations.

Not yet. It is on my todo list, but requires a whole other system for handling it and a nice UI to manage it as well, so it isn't something I wanted to slap together.

[Musuko42]

I was dubious about installing a mod like Dangit, but THIS mod I really like the look of, because it adds in some interesting strategy options: I've just unlocked a new engine which is better, but not yet reliable, so do I risk the unreliability, or invest the time and money in testing it to make it more reliable, or do I stick with my older, less-advanced, but more reliable engines?

In short, do I go the NASA route, or the Soviet route? And having that choice is GLORIOUS!

Idea for you, in case nobody else has mentioned it (not gonna check through eleven pages!): Make the repair function have a success rate, affected by Engineer Kerbal stats and the base reliability of the part. A level 0 Engineer, or a Pilot or Scientist, has a base percentage chance of repairing a failed part. A levelled up Engineer has a better chance to repair it. And a part that has a higher reliability also gives a better chance to repair (reflecting the better familiarity they'd have with the part).

Then, if you're feeling fancy, separate out the repair situations, with some more randomness. For example, a failed engine might have a 20% chance or successful repair from the cockpit, and a 60% chance of successful repair if performed via EVA interaction.

You could also add in a chance that the part will be irrevocably broken by an unsuccessful repair. Again, better familiarity with the part and better engineer training would reduce that chance.

And finally: you could add in a time delay for the repair, depending on the severity, reliability of the part, and the Kerbal performing it: some repairs might take seconds, some minutes, hours or days. You could add some randomness to this, but display an estimated time to repair before you press the repair button...and once again, the accuracy of that estimate could depend on the reliability of the part and the Kerbal performing it.

So much scope for coolness with this mod! Thank you for making it.

Edited January 9, 2015 by Musuko42

[Yzangard]

Lol, I'm about to cry, was the mod I was planing to create (with Neural Network for experiencing but not really important)

Nice mod, I can focus on something else now

Will try asap

[Agathorn]

I was dubious about installing a mod like Dangit, but THIS mod I really like the look of, because it adds in some interesting strategy options: I've just unlocked a new engine which is better, but not yet reliable, so do I risk the unreliability, or invest the time and money in testing it to make it more reliable, or do I stick with my older, less-advanced, but more reliable engines?

In short, do I go the NASA route, or the Soviet route? And having that choice is GLORIOUS!

That is pretty much what I was going for, so thanks The intent wasn't to just make random failures so that the game is arbitrarily harder, but to actually give deeper gameplay and give meaning to testing your hardware like in real life.

Idea for you, in case nobody else has mentioned it (not gonna check through eleven pages!): Make the repair function have a success rate, affected by Engineer Kerbal stats and the base reliability of the part. A level 0 Engineer, or a Pilot or Scientist, has a base percentage chance of repairing a failed part. A levelled up Engineer has a better chance to repair it. And a part that has a higher reliability also gives a better chance to repair (reflecting the better familiarity they'd have with the part).

Then, if you're feeling fancy, separate out the repair situations, with some more randomness. For example, a failed engine might have a 20% chance or successful repair from the cockpit, and a 60% chance of successful repair if performed via EVA interaction.

You could also add in a chance that the part will be irrevocably broken by an unsuccessful repair. Again, better familiarity with the part and better engineer training would reduce that chance.

The really nice thing about TestFlight is that it itself is moddable. All of those things are completely doable, even if the included base Failure modules don't do it. That said there are plans to implement most of that in the base included modules. Modders can go farther (or not as far) if they want though.

And finally: you could add in a time delay for the repair, depending on the severity, reliability of the part, and the Kerbal performing it: some repairs might take seconds, some minutes, hours or days. You could add some randomness to this, but display an estimated time to repair before you press the repair button...and once again, the accuracy of that estimate could depend on the reliability of the part and the Kerbal performing it.

Time based repairs were originally a thing, and then I removed them because it was adding a complexity to the code that was getting unmanageable. That said, I have been thinking about it and I think I see how I can work them into the new system that I am building, so I will keep it in mind.

So much scope for coolness with this mod! Thank you for making it.

Thanks!

- - - Updated - - -

Lol, I'm about to cry, was the mod I was planing to create (with Neural Network for experiencing but not really important)

Nice mod, I can focus on something else now

Will try asap

lol. I'm sorry?

No sense doing the hard work if someone does it for you Feel free to offer up suggestions and feedback and I hope TestFlight will provide the gameplay elements you were looking for as it matures.

- - - Updated - - -

So just a heads up everyone. In trying to track down the issues with the GUI not saving properly, I have discovered the root problem which is much more sinister. Apparently I am managing to get multiple instances of the TestFlight KSP Scenario all running at the same time

I am digging into this and will get a new release out as soon as I figure out what the heck is going on.

[magico13]

I'm only keeping up with this mod a tiny bit, but my primary tester for KCT I think has been and I have a tendency to check out what he's been involved in since it tends to be pretty good (found out about MKS through him). From my limited understanding of this mod, it's a part failure mod that has increasing reliability the more you use a part in a specific location (atmosphere, orbit around X, etc), correct? I feel like KCT's simulation feature could have interesting interactions with this (a simple example, simulations could have their time spent contribute to reliability but at a reduced rate. Or you could pay more to have a simulation where no parts can fail. Things like that.) I may look into extending some things, or at least adding some interaction in the future.

[Agathorn]

I'm only keeping up with this mod a tiny bit, but my primary tester for KCT I think has been and I have a tendency to check out what he's been involved in since it tends to be pretty good (found out about MKS through him). From my limited understanding of this mod, it's a part failure mod that has increasing reliability the more you use a part in a specific location (atmosphere, orbit around X, etc), correct? I feel like KCT's simulation feature could have interesting interactions with this (a simple example, simulations could have their time spent contribute to reliability but at a reduced rate. Or you could pay more to have a simulation where no parts can fail. Things like that.) I may look into extending some things, or at least adding some interaction in the future.

Those are some very interesting ideas magico13. While I haven't actually started testing with KCT yet, it is definitely in my long term plan for tight integration, so i'm happy to hear you are open to the idea.

From my limited understanding of this mod, it's a part failure mod that has increasing reliability the more you use a part in a specific location (atmosphere, orbit around X, etc), correct?

That is correct. The more you fly "Part A", the more flight data you accumulate on how that part operates in different conditions, and the more reliable future instance of "Part A" on new craft become.

I like both of your integration ideas, especially paying more to have a simulation with no failures, as that could be very useful. The idea of gaining data during a sim makes sense in a logical manner, though it would have to be balanced so that a player couldn't just run a ton of back to back sims and make everything perfectly reliable.

I like both ideas though, so let me bounce them around in the back of my head and see how they could be implemented on my side.

[magico13]

I like both of your integration ideas, especially paying more to have a simulation with no failures, as that could be very useful. The idea of gaining data during a sim makes sense in a logical manner, though it would have to be balanced so that a player couldn't just run a ton of back to back sims and make everything perfectly reliable.

I like both ideas though, so let me bounce them around in the back of my head and see how they could be implemented on my side.

I opened a GitHub issue for it so I don't forget, so you're welcome to bring any discussion there if you don't want it cluttering up the forum and getting lost in the future The simple solution I thought of for preventing people from doing a bunch of simulations is that you set a cap on the maximum reliability you can get out of simulations. They already should gain reliability at a reduced rate since you're conceivably modelling the part in the simulation based on known data, so you obviously can't cover every real world case. The same argument can be made for why you wouldn't be able to get 100% reliability from simulations because you wouldn't be modelling those unknowns.

I think I need to start working on an API for KCT soon-ish. It would likely be beneficial for you, and other mods, to know when a flight is a simulation or is real, and other things like that.

Edit: Limiting the available failure pathways for a particular part (assuming there's more than one failure mode) to only known ones would be pretty cool. Same with the ability to force a failure, for testing abort operations.

Aaaand, a GitHub issue for discussion on creating a KCT API.

Edited January 9, 2015 by magico13

[razark]

I am digging into this and will get a new release out as soon as I figure out what the heck is going on.

Speaking of new releases of the mod, I have a question. Is the data/reliability stored in the persistent.sfs file, or is it getting wiped out every time a new version is installed?

[Agathorn]

Speaking of new releases of the mod, I have a question. Is the data/reliability stored in the persistent.sfs file, or is it getting wiped out every time a new version is installed?

It is stored in the persistent.sfs file, however during these early phases of development it is entirely probable you may have to start a fresh game if things get corrupted or change too much.

[razark]

It is stored in the persistent.sfs file

Thanks.

however during these early phases of development it is entirely probable you may have to start a fresh game if things get corrupted or change too much.

Understandable, and I have no problem with restarting games while testing. I've actually got this installed on a second copy of the game.

(I actually haven't gotten into a serious campaign since 0.90 was released. I've been waiting on mods to update, or trying out new ones, or trying to motivate myself to actually rearrange the tech tree into something that makes sense to me.)

[Agathorn]

Ok its been a bit of a painful day and a half of fighting with this code, but after essentially re-writing the entire core persistence handling, I have fixed most of the issues with settings saving/loading, and multiple scenarios being spun up by KSP.

I'm still tracking one bug, if you leave a ship "in mission" and then come back to it, the flightdata is lost -- but I think that bug might actually be in the existing released versions of TestFlight

- - - Updated - - -

I'm still tracking one bug, if you leave a ship "in mission" and then come back to it, the flightdata is lost -- but I think that bug might actually be in the existing released versions of TestFlight

Ok well I hate to say it but this seems to be a bug in KSP itself. I swear to god *sometimes* KSP simply doesn't save the game state even though it should, or at best it partially saves it.

- - - Updated - - -

v0.3.0 Alpha Released

==============

https://github.com/jwvanderbeck/TestFlight/releases/tag/v0.3.0

Alpha Development Release

======================

**This is an early alpha development release and thus should be assumed to be buggy, and capable of breaking your game and game saves. Please do not test this in a game save that you care about!**

**IMPORTANT NOTE** Due to many changes in how settings are handled, and stored, as well as the removal and addition of different settings than previous releases, please completely delete any previous install of TestFlight before installing this version. In addition it is *highly recommended* to start a new save game for this release.

Highlights

-------------

* Brand new TestFlight GUI

* Configurable Master Status Display gives you all the details on your parts you want, and nothing more

* Settings GUI lets you change TestFlight settings easily in game

* In Flight HUD gives you a compact view of the most critical information

* Rebuilt underlying persistent handling to hopefully be more reliable

All new TestFlight GUI

------------------------------

Javascript is disabled. View full album

* New Master Status Display is highly configurable and automatically scrolls to hand craft with lots of parts. You can turn on/off all data displays with the exception of the part name (which you can shorten) and the Repair/Acknowledge buttons. *NOTE: The Momentary Reliability data is a temporary placeholder and will never contain any data in this release*

* New tooltip for repair requirements uses color highlighting to let you quickly see which conditions are met (green), which are not(red), and which are not met but optional (orange).

* You can set the size of the main MSD to one of three preset sizes, Small, Normal, or Large which will adjust how tall the window is and how many parts you can see before scrolling.

* MSD can be filtered to show only failed parts. Repairing or Acknowledging a failure will remove it from the list.

* New In Flight HUD provides a compact status display that shows only failed parts, and shows only the name of the part and the buttons to repair or acknowledge the failure. Part coloring in this HUD quickly identifies the severity of the failure (Green = minor, orange = normal, red = critical).

* MSD can be docked, or unlocked and moved

Change Log

----------------

* Added entirely new Master Status Display (MSD) for TestFlight

* Added settings window for configuring TestFlight settings in game

* Added ability to independently toggle on or off various pieces of part status in the MSD

* Added new compact in flight HUD that can be toggled on/off and positioned as desired

* MSD can be either docked, or unlocked and moved around

* MSD now scrolls if there are too many parts to fit

* MSD height is adjustable

* Settings pane broken into multiple pages so as to not require a huge window

* Repair Requirements tooltip is now color coded for clarity and quick assimilation of data

* Fixed spelling error in settings dialog

* Added button to "acknowledge" a failure. This will clear it from the Flight HUD and the MSD if set to show only failed parts, but will not repair the failure. It will still remain in the full MSD list (If the show only failed parts setting is OFF)

* Added the failure title to the tooltip of the Flight HUD

* Rebuilt ScenarioModule to provide a more reliable data store

[Agathorn]

So just an update on things here. I'm in the works on moving from a "pull" system where the main manager polls all the parts for updates to a "push" system where each part is semi-autonomous and handles its own state, reporting back to the manager as needed.

I am about halfway done on this. Currently flight data is being recorded in the new system and being pushed back up the chain as needed. Tomorrow I will work on the remaining pieces.

Once that is done I will start work on implementing the overhauled reliability and failure system as discussed in the proposal.

[razark]

I haven't run into any issues with the 0.3.0 release. The only things I can say at this point are:

1. Failures seem quite frequent. Testing new tanks and engines on the pad has become standard procedure. I've made it to orbit a few times, and most of those times I couldn't make it back down due to engine failure or fuel leaks. (This looks like it will be changing in the future, so don't take it as a complaint... yet )

2. This has become very familiar:

3. Thank you so much!

[Ser]

Nice idea. I'll definitely try it. Seems like every space mission could now be a real challenge with this and stuff like Construction time + Remote Tech + Engine Ignitor.

Don't know if you already implemeted this, but it would be nice if you could make parts that are labeled as experimental the super unreliable, so much as they could be used for testing purposes only. Because currently we have a kind of exploit in stock: you may accept a test contract for a part that is expensive to research and use that prototype 365+ days without any penalty. But if it was extremely unstable then a hard choice ought to be made: pay for research or have a damn risk of failure right in the middle of a mission.

[Agathorn]

I haven't run into any issues with the 0.3.0 release. The only things I can say at this point are:

1. Failures seem quite frequent. Testing new tanks and engines on the pad has become standard procedure. I've made it to orbit a few times, and most of those times I couldn't make it back down due to engine failure or fuel leaks. (This looks like it will be changing in the future, so don't take it as a complaint... yet )

Well it is certainly intended that you actually find the need to focus on testing, but yes I agree that failures are way too high. We'll see how things fare after the change over to the new system. And once that is done I can also spend some time tuning settings.

2. This has become very familiar:

[/quote

Haha. It would be funnier still if it wasn't all true Hopefully the ending of that movie is also familiar though as your parts get better.

3. Thank you so much!

You are very welcome! I'm glad you are enjoying it.

- - - Updated - - -

Nice idea. I'll definitely try it. Seems like every space mission could now be a real challenge with this and stuff like Construction time + Remote Tech + Engine Ignitor.

Most definitely. And look forward to some actual integration with things like these in the future!

Don't know if you already implemeted this, but it would be nice if you could make parts that are labeled as experimental the super unreliable, so much as they could be used for testing purposes only. Because currently we have a kind of exploit in stock: you may accept a test contract for a part that is expensive to research and use that prototype 365+ days without any penalty. But if it was extremely unstable then a hard choice ought to be made: pay for research or have a damn risk of failure right in the middle of a mission.

That isn't a bad idea. It has also been suggested that TestFlight eventually provide contracts of its own for testing parts.

[Agathorn]

I just want to give a heads up to anyone who has written any modules for TestFlight or is working on writing any. The next release will contain major changes to the module API, so those modules will not only need to be recompiled but also restructured. There will be a few experimental releases first that contain these changes, and then they will make it into the next alpha release after that.

In addition there is a good chance of more changes as we then focus on moving to the new reliability and failure system.

I apologize for these changes, and I know its a hassle. But that is what these early alphas/experimental are for. In the early days the API will be unstable as we narrow in on the optimum layout and make changes to make things better. The light at the end of the tunnel though is that once we have things looking good and stable, then the API can be mostly locked down and changes going forward will be minor and rare. So I apologize for the short term pain, but it will reap long term benefits

[Agathorn]

Experimental Release

v0.4.0 Experimental 1

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

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

• TestFlight API completely overhauled and is not backwards compatible
  
• Totally rewritten underlying core systems
  
• Migrated from a polling "pull" style system to a "push" style system where the individual parts are responsible for their own state, and the core manager/GUI only asks for that state when needed to update the GUI or save to disk
  

API Changes

The TestFlight API starting with this experimental version is not backwards compatible with previous versions

This experimental release contains a completely overhauled API and more changes will be made moving forward as I work towards implementing the new Reliability and Failure system as proposed. If you have written a module for TestFlight it will need to be updated to use the new API, and will probably need minor changes as we move through the next few releases.

The good news is that while the API got a lot more flexible and a lot more powerful,most of the changes for now are in the Core, not the plugin modules. Changes to compile against this experimental release will probably be minor. But do expect more changes coming.

Change Log

• Rewrote core scenario code. TestFlightManagerScenario is now only a data store for the persistent data, and contains no appreciable game logic
  
• Redesigned TestFlightCore API to accommodate both the new "push" method as well as upcoming changes to the underlying reliability and failure architecture
  
• Flight Data and Flight Time now stored as doubles
  
• Implemented brand new Test Flight API
  
• Changes to ITestFlightCore interface
  
• Changes to ITestFlightDataRecorder interface
  
• Changes to ITestFlightReliability interface
  
• Core system refreshes status more often now that there is less of a performance hit
  
• Changed method of configuring how FlightData converts into Reliability in the config files. This is now done using a FloatCurve which allows the modder to make it as simple or as complex as desired
  

This is, as stated, nearly a complete rewrite of the entire mod. It has taken me about 3 or 4 days, but it will be worth it moving forward. However, despite it being a nearly complete rewrite, from a user's perspective not much should change. Aside form some minor differences in reliability rates based on flight data (IE how much flight data = how much reliability) and the fact that failure checks are currently hard coded at 30 seconds, you should not see anything different.

In fact that is the point of this experimental. So here it is. Everything rewritten yet it should be all the same Please let me know if you see something broken or that looks to be very different from before. My goal is to stabilize this re-write first, and then move forward into the next and hopefully last big chunk which is implementing the new reliability and failure system as proposed about a week ago.

Edited January 15, 2015 by Agathorn