Depending on what is behind the semi transparent window, the MSD can be hard to read. Especially the Green "safe" text.

The eventual goal is to replace the stock UI window with a custom one.

This should be easy to do. Make AttempRepair() return a double instead of a bool. -1 indicates failure to repair. 0 indicates repaired. Any value above 0 indicates time to finish repairs.

Add new method GetTimeUntilRepairComplete() that returns the same information. In this case -1 would indicate that something happened during the repair time that caused a failure to repair, such as a prerequisite condition no longer being valid.

The MSD/FlightHUD will need to display a countdown when a part is being repaired, and the UI will need to adjust for this. Might be able to put this in the tooltip, but not sure if that will be very good. Need to think on it.

If the EngineIgnitor mod is installed, then the IgnitionFail module should have an option to reset the ignition that failed, so as to not use it up.

For some odd reason KSP is creating multiple instances of the main ScenarioModule. Since pretty much all operating data is stored there, this is causing major issues. When other modules atempt to get/set data they aren't always getting the same instance.

In order to work properly with MFT and RF, we need to treat engines with a ModuleEngineConfig as a stand-alone part.

Add in "configuration" property to all modules to indicate that the module and its settings apply to a specific ModuleEngineConfig

Would be nice to be able to build a JSON definition for a part that copies an existing definition but overrides a few properties.

1. Engine fails with EngineShutdown failure
2. Part is repaired
3. After repair, the part's Reliability module will start doing failure checks again, even though the engine has not been restarted.

When this occurs, FlightData is not accumulating so the DataRecorder properly recognizes the engine is not operating. Most likely the Core is not properly checking for active operation, and so the operatingTime starts running again, which causes the Reliability module to start checking for failures.

Should be able to tie in and allow different settings per size or radius or something.

So you can pay money and (in-game) time to do non-flying research. Per discussion in IRC.

When a part fails, it continues to accrue operating time that will then be added when it is repaired - often resulting in an immediate second failure due to delta difference.

When a part is failed it should not be accumulating operating time, and it should start at 0 time when repaired.

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

This appears to be a display bug only and the proper du is still stored.

The flight data appears to get reset to the initial flightdata level that was on the parts at the start of the mission.

Since the settings page dropdown has a semi transparent background, it is hard to read.

The options in the Difficulty Settings window are old and very much out of date. Needs to be looked at and the ones no longer valid removed.

For compatibility with RF, we should reduce both the min and max thrust instead of just the max.

Also need to smooth out the process of the multi-branch setup

Provide ways to integrate closely with Kerbal Construction Time for a more in-depth experience with the two mods.
XREF: magico13/KCT#32

Make TestFlight create in game contracts to get a certain amount of FlightData for a part in a certain scope. Assuming KCT integration happens, there would need to be a check that ensures this happens in flight and not in a sim.

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

Currently global settings can only be edited directly in the CFG file. There needs to be a way to do this through the GUI in game.

Perhaps simply make the data show up in the TF window when mousing over a part on the ship, just like it does for the bins.

When the Flight scene starts up, the ModuleEngineConfigs configuration is the base value initially, and doesn't change to the proper value until a bit later. Unfortunately TestFlight is attaching based on that incorrect initial value, causing all derivative engines to not work properly.

Need to find out if there is a way to tell when MEC is correct and then grab it through a coroutine maybe.

This is the cause of #36 and probably more yet unseen bugs.

Check with @NathanKell in case he has any ideas.

I have some concerns that some of the checks in there are either incorrect or not working properly. Verify each is correct.

Add the ability for flight data to be transferred from one part to another part which would be considered an upgrade. This "Tech Transfer" is to simulate applying the lessons learned from say Part X model 1, to Part X model 2.

If a failure destroys a part, no failure shows up because no part.

For example, the IgnitionFail might be better as a one-shot failure where the part fails, IE doesn't ignite, but the part is not put into a failed state.

In the current test builds, all failures are easy to repair. The consume no resources to repair and have a 100% repair rate.
Need to work in the code to allow repairs to consume resources, like spare parts, have a chance to NOT succeed, and verify preconditions such as EVA requirements, etc.