[1.2.2] TestFlight - v1.8.0 - 01 May 2017 - Bring Flight Testing to KSP!

[John FX]

So I`m noticing that when I fly with no physics warp my engines seem much more reliable than when I fly with it.

Anyone else notice this?

EDIT :

I also have noticed that the RD-108_8D75PS engine does not accumulate du and stays on 0 although it does not seem to fail either.

Is there a particular log or similar I could post? I`m running RO/RSS/RP-0 with one of the recommended engine packs although I`m not sure which, could check if needed.

EDIT 2 : yup multiple launches now and the RD-108_8D75PS is still on 0du with no failures. I`m suspecting a .cfg issue as the other engines accumulate du fine.

EDIT 3 : I will provide the following, seen from another thread.

On 06/03/2016 at 3:49 AM, NathanKell said:

Can you follow the steps in the How To Get Support sticky in modded support? A complete modlist with versions, and your log (output-log.txt)

Here is my output.log

this is my modlist

Spoiler

KSP: 1.0.5 (Win32) - Unity: 4.6.4f1 - OS: Windows 7 Service Pack 1 (6.1.7601) 64bit
Filter Extensions - 2.4.1.3
Advanced Jet Engine - 2.6.1
Ambient Light Adjustment - 1.5.4.2
B9 Aerospace Procedural Parts - 0.40.1
Community Resource Pack - 0.4.9
Connected Living Space - 1.2.0.1
Contract Configurator - 1.9.6
CustomBarnKit - 1.1.4
Deadly Reentry - 7.3.1
DMagic Orbital Science - 1.2
EditorExtensionsRedux - 3.0.2
Engine Lighting - 1.4.1
Ferram Aerospace Research - 0.15.5.7
Firespitter - 7.1.5
GCMonitor - 1.3.2
RasterPropMonitor - 0.24.2
Kerbal Construction Time - 1.3.1
Kerbal Engineer Redux - 1.0.19.4
Kerbal Joint Reinforcement - 3.1.4
KSP-AVC Plugin - 1.1.5
ModularFlightIntegrator - 1.1.2
Docking Port Alignment Indicator - 6.2
Procedural Parts - 1.1.11
RCS Build Aid - 0.7.7
RealChute - 1.3.2.7
RealismOverhaul - 10.9.2
RealSolarSystem - 10.4.1
RemoteTech - 1.6.9
Saturatable RW - 1.10.2.1
SCANsat - 1.1.4.8
SolverEngines - 1.15
StageRecovery - 1.6.3
TestFlight - 1.5.1
TestFlight - 1.5.1
TextureReplacer - 2.4.12
TAC Life Support - 0.11.2.1
Kerbal Alarm Clock - 3.5
VenStockRevamp - 1.9
[x] Science! - 4.14

 

Edited March 7, 2016 by John FX

[NathanKell]

Yep, there are some issues here we're trying to fix as we speak...thanks for the report and log!

[MajorLeaugeRocketScience]

Does this work in sandbox mode or just career? I downloaded the RO version and went into a RO sandbox and it didn't work. Any thoughts on it?

[Agathorn]

1.5.2.0

IMPORTANT

This release has some changes and fixes that can affect existing saves and .craft files.

• A change to how part names are determined will cause some parts to be registered with a new name that no longer matches what might already be stored in the save file. In this case those parts will reset to 0 data!
• A fix to how data is persisted in the .craft files has been fixed. This bug could cause saved .craft to not initialize properly and thus never gain any data from previous flights. This bug has been fixed however the fix is not retroactive and thus will only affect new saved craft and not fix old ones.

CHANGES

• CHANGE: TestFlightReliability_DynamicPressure - Clamp evaluated dynamic pressure reliability curve to TestFlightUtil.MIN_FAILURE_RATE
• CHANGE: DynamicPressure minimum modifer value now configurable
• CHANGE: TestFlightContracts linked to latest version (1.9.7) of ContractConfigurator
• CHANGE Support Passive RT antennas as well.
• API CHANGE: TestFlightScenario.AddValue methods have been renamed to SetValue as that more accurately represents how they function (setting an absolute value).  New methods have been added to the Scenario called AddValue that do just that, taking the existing stored value and adding to it. Obviously not available for string and bool types.
• API NEW: Added TestFlightScenario.ToggleValue(string key, booldefaultValue). This method will either take the existing stored value and set the opposite (so false to true, true to false) or if there is no existing value it will set the defaultValue
• FIX Part.name is unreliable. Use a corrected version of the part name (code borrowed from RealFuels) that should be reliable. Spelling ftw
• FIX: Fixed duplicate TestFlightInterop modules on some parts that could cause errors on the RL10x2 series and LR91-AJ series engines
• NEW: Light bulb flickering failure
• NEW: MaxQ reliability module to lower reliability at high Q
• FIX: Science failures now have experimentID to support multiple experiments
• CHANGE Start XLR11 at 0 data.
• FIX Increase data rates for XLR11, XLR99.
• CHANGE ResourceLeak now supports resource to leak "all"; persistence fixed, refactored to use leak lists.
• FIX Update resource leaking to use fixed timesteps rather than realtime.
• FIX Engine fixes. Flight Data Recorder (Engines) binds to first engine on the part. The failure modules grab all engines matching passed spec, defaulting to 'all' engines on the part. The wrapper is cleaned up and does not use scriptable objects anymore. Also fixed some KSPFielding and now don't recalculate dynamic pressure.
• FIX: EngineModuleWrapper spam removed by properly treating ScriptableObject as Unity requires. Because reasons.
• FIX: XLR11, XLR99 configs to apply to all of them (use different MM pattern). Fix LR91 part matches for other LR91s.
• CHANGE: Remove unneeded persistence flags.
• FIX: Proper data initialization for saved .craft files.  NOTE: Fix is not retroactive and will only work properly on new saved craft.
• FIX: Properly accumulate flightData when multiple parts with the same underlying part name are on a vessel. Fixes #101

Edited March 8, 2016 by Agathorn

[Agathorn]

9 hours ago, MajorLeaugeRocketScience said:

Does this work in sandbox mode or just career? I downloaded the RO version and went into a RO sandbox and it didn't work. Any thoughts on it?

It works fine in sandbox mode, but bear in mind that not all parts currently have configs for TestFlight.  Couple things:

1. Make sure your RO is up to date.  Only the most recent versions started adding in more configs for RO parts.

2. In the flight scene, open the TF Window.  Are any parts at all listed in there? If so, but they just aren't getting data then this release hopefully fixes that.  check the release notes for more information. If there are no parts listed, then can you please reply with what engine parts you have on our rocket? Thanks!

[John FX]

Wow, that`s a lot of fixes.

EDIT : Just to let you know, it is not yet live on CKAN.

EDIT 2 : Just installed manually and now a craft which was saved on the launchpad with RD-108_8D75PS engines now accumulates du on them.

Thank you very much for this update.

Edited March 8, 2016 by John FX

[Agathorn]

6 hours ago, John FX said:

Wow, that`s a lot of fixes.

EDIT : Just to let you know, it is not yet live on CKAN.

EDIT 2 : Just installed manually and now a craft which was saved on the launchpad with RD-108_8D75PS engines now accumulates du on them.

Thank you very much for this update.

CKAN happens automatically but sadly usually takes a day or two for their bots to pick it up.

Glad it fixed your issues!

[John FX]

21 hours ago, Agathorn said:

CKAN happens automatically but sadly usually takes a day or two for their bots to pick it up.

Glad it fixed your issues!

True. I see a couple of mods that AVC says are updated yet CKAN does not yet. I have yet to see whether physics warp makes engines less reliable but I will post here once I do.

EDIT :

Haven`t noticed physics warp causing engine failures to happen more often, seems better.

Edited March 9, 2016 by John FX

[Agathorn]

TestFlight 1.5.3 Beta 1

• NEW: New Failure module EnginePerformanceLoss causes the engine's Isp to degrade by an amount specified in the config property ispMultiplier. A second property ispMultiplierJitter can be used to add some small extra random variance to the degredation Use aliased format for kspPartNames when coerced from blank string as it is cleaner.
• NEW: TestFlightInterop now adds an intervop value named kspPartName which is theinternal KSP name of the underlying part. This does not change. Can be used in config queries and should be used instead of blank queries or queries with just part names.  config = kspPartName = squadFoo.
• CHANGE: Internally, any empty configuration string is coercedinto kspPartname = squadFoousing the new interop value and theparsed part name.
• FIX: If a part has starting flight data from the config, add that to the scenario data store when first initializing it. Should fix issue with needing to record past the startFlightData before it would stick.
• NEW-API: Added TestFlightPartData.AddValue and overloaded versions for int, float, and double that do what it says on the tin.
• NEW-API: Added TestFlightPartData.ToggleValue for bools
• NEW-API: AddedTestFlightManagerScenario.AddFlightDataForPartName helper function toadd to existing flight data for a part.
• CHANGE-API: Renamed TestFlightPartData.AddValue to TestFlightPartData.SetValuefollowing in accordance with the previous similar change to TestFlightManagerScenario which wraps these for convenience.
• CHANGE: Removed persistence from TestFlightCore.startFlightDataas it is not dynamic.
• CHANGE: TestFlightFailure_ResourceLeak - Use System.Random from TestFlightCore instead of Unity's broken random.
• CHANGE: All RealismOverhaul configs have been removed from TestFlight and are now managed and provided by Realism Overhaul directly.
• CHANGE: TestFlight Realism Overhaul Config pack is no longer built or provided by TestFlight.Updated build process to omit RO configsUpdated Netkans (this also needs to be done with CKAN)
• CHANGE: Removed Aerobee engine line from RealismOverhaul configs, as these configs now live in the RO project
• NEW: Reliability modules for SkinTemperature and InternalTemperature

 

Important

Please be aware that this is a beta release and is released for testing purposes only.  It may or may not be stable, but any testing helps us ensure that normal release are more solid.  Beta release do not show up on CKAN so you will need to install manually.

Please report any bugs or issues on Github.

Edited March 11, 2016 by Agathorn

[Deimos Rast]

So I figured I would give this another go, since other mods aren't quite giving me the level of explosions that I require. Initially, I was (and still kind of am) put off by the amount of leg work this requires, but diving into and messing around with the configs for the past hour or two, I have to say you guys have created something really cool here. (I still don't get why there is a combination of both good documentation and great features, but almost no configs! I feel like I'm missing a download or something, but no ). All I've really done is read through the wiki, taken notes, read through the Stock and RO configs, taken even more notes, all so I can blow myself up more frequently. How kerbal.

So if you'd please, I have a few questions, which if you could answer some or all of, I'd be much obliged (even if it's just a link to more info). In no particular order:

---------------------------
What would the TestFlightReliability_SkinTemperature (or InternalTemperature) curves look like? It says "1.0 is normal, higher fails more" so for a 10% failure rate at 0 data...?

temperatureCurve
        {
            key = 0 0.9
            key = 10000 1.0
        }

I looked through the entire Stock Config and RO config, and nowhere are these curves used, so I don't have any examples to go by (and up till now, I never knew what these "curves" even were!).

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

duRepair = 50
duFail = 100

What does this mean? If I remember correctly, "du" is the data unit, correct? I thought it might be the minimum data required to repair, which might make sense, but having a minimum required to fail doesn't really.

--------------
Failure Rates:

I feel like I should know this already, but are failure rates solely determined by the curve, and then the type of failure it determined based on the weight assigned to it?
-------------------------
TestFlightReliability_EngineCycle -------> ratedBurnTime

What are the units on this? My guess is seconds?
-------------------------
Repair Module:
canBeRepairedInFlight

Does this mean in the "Flight Scene" (as in while you have the vessel actively selected) or while the vessel is "In Flight", as in engines burning, flying. It has to be the former, but it's late, I'm tired and I need clarity. I have a great mental picture of the latter, though.

canBeRepairedByRemote

The opposite of above I'm guessing (assuming the former is correct)?

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

That's it for now. If you have any suggestions for further reading, please let me know (I still have to read through this thread). Off to go see if my test engine config works!
Thanks.

 

[Agathorn]

um wow I typed up a long response to all your questions and then the forum ate it

sigh.. I will reply again I promise but I need to get some breakfast first.

[Agathorn]

Sorry you are finding it a struggle. I’m afraid this is really a consequence of the fact that I don’t play stock, ever. I am a Realism Overhaul player, so that is all I know. The “missing download” you mention is the RO configs On the stock side things aren’t so good and I acnkowledge that but sadly there isn’t much I can do about it

What would the TestFlightReliability_SkinTemperature (or InternalTemperature) curves look like? It says "1.0 is normal, higher fails more" so for a 10% failure rate at 0 data...?

temperatureCurve
        {
            key = 0 0.9
            key = 10000 1.0
        }
I looked through the entire Stock Config and RO config, and nowhere are these curves used, so I don't have any examples to go by (and up till now, I never knew what these "curves" even were!).

Ok so first the curves are what is known as a FloatCurve and is a standard KSP thing. You can google them, but essentially it is a list of key value pairs that describe a curve if plotted on a 2D plane. There is also a KSP plugin for Unity that will let you see and create them visually in the Unity editor which is great.

Now when it comes to Reliability modules, first off it is important to understand that there are essentially two different types of Reliability modules. The first is the basic module which provides a Base Failure Rate to TestFlight. This Base Failure Rate or BFR decreases as more data is accumulated on the part. You must always have one (and only one!) of these modules on a part. The second type is a essentially a modifier. These Reliability modules work on top of the base modules and provide a Momentary Failure Rate or MFR to the part based on moment to moment conditions. Skin Temperature in the case of this module. This MFR is a multipler applied against the BFR. The MFR does not change based on data but on conditions. Since it is a multiplier, a value of 1.0 essentially means no effect. A value less than 1.0 would actually make the part have a lower than base failure rate and a value greater than 1.0 would make the part have a higher than base failure rate. So essentially in this case you could make the part more likely to fail as its skin temperature increases.

Now the curve in the config, as mentioned is a FloatCurve. Specifically in this case the key (first value) is the temperature and the value is the MFR applied for that temperature. The curve you quoted above would make the part slightly less likely than normal to fail when it has a skin temp of 0, and then it would linearly increase until at 10,000 degrees it has a normal failure rate. I’m fairly certain that isn’t what you wanted, but hopefully you now have the information to do what you want.

If you haven’t already, you can read more about MFR and BFR in the TestFlight Quick Start guide on the Wiki.

duRepair = 50
duFail = 100

What does this mean? If I remember correctly, "du" is the data unit, correct? I thought it might be the minimum data required to repair, which might make sense, but having a minimum required to fail doesn't really.

These give the part a specified amount of data units when a part fails or is repaired. Think about it like this; If a part fails during a flight you learn from that, so this gives you a bonus chunk of data when that occurs.

Failure Rates:

I feel like I should know this already, but are failure rates solely determined by the curve, and then the type of failure it determined based on the weight assigned to it?

The failure rate of a part at any given moment is Base Failure Rate * Momentary Failure Rate. Additionally there is a slight modifier based on operating time, because all things being equal a part is more likely to fail as its operating time approaches its MTBF.

When a part fails as part of the normal survival checks each tick, then a random failure is picked based on weight. That said some failures can work outside the system and trigger themself based on conditions, and will not be triggered with random failures. TestFlightFailure_IgnitionFail is an example of this.

TestFlightReliability_EngineCycle -------> ratedBurnTime

What are the units on this? My guess is seconds?

Yes, in seconds.

Repair Module:
canBeRepairedInFlight

Does this mean in the "Flight Scene" (as in while you have the vessel actively selected) or while the vessel is "In Flight", as in engines burning, flying. It has to be the former, but it's late, I'm tired and I need clarity:lol:. I have a great mental picture of the latter, though.

canBeRepairedByRemote

The opposite of above I'm guessing (assuming the former is correct)?

canBeRepairedInFlight means can the part be repaird while the craft is actually flying, and has nothing to do with the scene. canBeRepairedByRemote means can the craft be repaired wthout any crew, like a software update sent over the comm. The repair side of TF really never got fleshed out as much as I wanted, but originally there was the intention of making it so some repairs would require crew to EVA to the part to fix it.

[Deimos Rast]

Thanks for taking the time to reply. Twice. I think this is also a good intro, that answers a lot of the questions I had, but I didn't find it until recently.

And I don't play stock either - perish the thought! I have a lot of mods, just not RO. (The reason I don't have RO, is because I have too many mods already, heh.)

It'll take a bit of digesting your response before I can make a proper one myself, I just wanted to say thank you.

Also, since everyone seems to be focusing so much on Engines for whatever reason (my guess is they're neato and there is a lot of data available), I decided to head in the opposite direction: Life Support, specifically TACLS. I didn't care for the one size fits all approach of the Resource/Fuel config (though serviceable enough), and I felt that life support was a bit more of a delicate matter (not everything should explode in other words). I also like the idea of almost always being able to have a slight chance to repair the damage and stem some of your losses (when it makes sense) - adds to the drama. Will I be able to repair the leak in my O2 canister or do I have to sit here and watch it slowly leak out into space?

I also tried to incorporate multiple reliability curves (such as pressure and temperature) for added variety when relevant, (although I don't know what the pressure curve looks like at the moment).

Unfortunately, I haven't had much time to test it yet (I'm actually building a test craft for it on my other monitor as we speak), but I do successfully get data on the parts I've tested. No failures yet.

 

I figure I'll work on Heatshield and Parachute failures next, which will no doubt be a winning combination (I play with DRE and FAR).

Cheers.

[Agathorn]

TestFlight 1.5.3.0

 

• NEW: New Failure module EnginePerformanceLoss causes the engine's Isp to degrade by an amount specified in the config property ispMultiplier. A second property ispMultiplierJitter can be used to add some small extra random variance to the degredation
• NEW: TestFlightInterop now adds an intervop value named kspPartName which is the internal KSP name of the underlying part. This does not change. Can be used in config queries and should be used instead of blank queries or queries with just part names.  config = kspPartName = squadFoo.
• CHANGE: Internally, any empty configuration string is coerced into kspPartname = squadFoousing the new interop value and the parsed part name.
• FIX: If a part has starting flight data from the config, add that to the scenario data store when first initializing it. Should fix issue with needing to record past the startFlightData before it would stick.
• NEW-API: Added TestFlightPartData.AddValue and overloaded versions for int, float, and double that do what it says on the tin.
• NEW-API: Added TestFlightPartData.ToggleValue for bools
• NEW-API: AddedTestFlightManagerScenario.AddFlightDataForPartName helper function to add to existing flight data for a part.
• CHANGE-API: Renamed TestFlightPartData.AddValue to TestFlightPartData.SetValuefollowing in accordance with the previous similar change to TestFlightManagerScenario which wraps these for convenience.
• CHANGE: Removed persistence from TestFlightCore.startFlightDataas it is not dynamic.
• CHANGE: TestFlightFailure_ResourceLeak - Use System.Random from TestFlightCore instead of Unity's broken random.
• CHANGE: All RealismOverhaul configs have been removed from TestFlight and are now managed and provided by Realism Overhaul directly.
• CHANGE: TestFlight Realism Overhaul Config pack is no longer built or provided by TestFlight.
• CHANGE: Removed Aerobee engine line from RealismOverhaul configs, as these configs now live in the RO project
• NEW: Reliability modules for SkinTemperature and InternalTemperature

[Maxsimal]

Been playing with test flight for just a bit now.  My experience here is very early, but just thought I'd give you a little feedback.

Using the aerobee engines, gaining additional data doesn't really their MTBF of 622.12.

But, despite this MTBF, I'm guessing that their rated burn time is closer to 40 seconds?  Around that point in flight, their MTBF starts increasing very rapidly.

Overal, this makes the MTBF sound much like a lie to a player who doesn't understand that there's another factor under the hood - how can a part's  MTBF be 10 minutes when you can never fly it without a failure past about a minute, after all?

I would suggest at least one of the following:

A: that the rated burn time for the part needs to be exposed in the UI.

B: That for the MTBF you have the curve integrated over the lifespan of the part, so that when you see its status in the VAB, the rated burn time is factored in - and that during the flight, you can show an MFR that's much lower until the part reaches its expected lifespan, but the MTBF remains constant.

C: (Just a suggestion) That rated duration for a part can be increased with additional testing, so that the MTBF does track upward.

[NathanKell]

The rated burn time is exposed, it's just a bit buried. It's in the modules list (the scrolling list on the right of the 'more info' part tooltip when in the VAB/SPH and mousing over a part in the part list). The way it works, during the first few seconds of burn, reliability is lower (and so MTBF is lower), then it goes back to normal, then once rated burn time has elapsed it starts climbing, reaching 100x fail chance around 1.5x the rated burn time.

[Maxsimal]

Yeah I feel like an idiot for not seeing that.   I like how the RP0 pack of mods rides the line between really fun and frustratingly hard.  Keeps me coming back, even when I'm tearing my hair out.  

[Agathorn]

The new version, about to be released, makes it easier to see this data.

[Agathorn]

TestFlight 1.5.4.0

Highlights

The TestFlight R&D System is finally here! It has been teased forever by the nonfunctional R&D tab seen in the TestFlight window in the KSC screen, but now it is finally implemented.

The R&D system is an optional feature that allows you to spend funds and time to increase part reliability without actually flying them and risking bad things happening.  Gaining data through flight will still often be quicker, but not as safe. R&D will be safer but slower and cost funds. The choice is yours. Parts do have maximum R&D limits however, so while engineers can get you to a better reliability before flight testing, they won't get you all the way.

R&D can be assigned to any supported part while in the editor constructing your vessel. Simply right click on the part and click the R&D Window button to toggle the R&D window. Here you can assign one of several teams to begin researching that part. Choose the one that works for you, balancing time and cost.

Every research cycle, which defaults to one day but may be changed by other mods, your part will receive flight data assigned to it by the research team, and funds will be subtracted.

You can stop/pause/resume research at any time either in the editor or as a shortcut by using the R&D tab in the main KSC screen. Research will also auto stop if the part reaches its maximum R&D level.

In addition to the R&D system, I also took this time to redo how TestFlight information is displayed in the editor. The old TF window in the editor is now gone, and is replaced by the new R&D window for assigning research and a new "Info Overlay" window which can give you detailed TestFlight information on any placed part with a simple Middle Click.

Upgrade Notes

Upgrading from 1.5.3.0 release to 1.5.4.0 release should not cause any issues. If you are upgrading from a dev or beta version of 1.5.4.0, it is suggested that you first stop all R&D teams before upgrading.

Changes

• FIX: Fix editor info window not hiding properly
• FIX: Fix editor info window not shrinking in size when changing parts or hiding the window
• NEW: EngineCycle module now displays information on idle decayand thrust modifiers if applicable in the info window
• FIX: Fixed a possible NRE in TestFlightRNDScenario load, as wellas making that code a bit more robust in the case of unexpected data.
• FIX: Apply rndRate and rndCost to display in R&D window. Fixes #136
• FIX: Fixed internal burn time handling on TestFlightReliability_EngineCycle
• FIX: Fixed major bug that was causing time handling to be truncated, causing part updates to happen less and less frequently the longer your save went on
• FIX: Moved TestFlight settings file to PluginData so that it doesn't cause ModuleManager recaching when settings change.  Important Note: TestFlight will automatically migrate the settings file for you the first time, but it won't be able to clean up the old file. Once migration happens you can freely delete the old file if desired.
• FIX: Fixed to RND Teams getting reset due to a race condition during RND scenario load.
• FIX: Fixed Editor R&D Window position not being properly read from settings on initial load.
• NEW: Parts no longer can gain data while in the PRELAUNCH situation. This means no more static test firing. The new R&D system should be used instead if you don't want to risk parts on an actual flight.
• NEW: Expanded Info window data for Core and Reliability modules
• FIX: Major bug fix that was preventing pretty much all modules from properly attaching!
• NEW: Placed parts in Editor now have a quick info overlay window that can be accessed by right clicking on the place part. This info window will display TestFlight information on the part.
• NEW-API: TestFlight modules now all have an interface method for GetTestFlightInfo which is used to return data the module desires to be displayed in the Editor Info window
• NEW-API: Interop changes now fire an event on the active Core module allowing for reactions to the change.
• FIX: Fix duplicate R&D Window buttons showing up in editor tweakables.
• NEW: R&D Window in Editor now displays information on how the system works, how much teams cost and how many points they contribute
• NEW: R&D settings can no be configured by other mods using Confignodes. Place all settings in a node named “TFRNDSETTINGS”.updateFrequency is a double indicating how often the R&D teams tick. Value is in seconds and the default is 86400 or 1 day.
• NEW: R&D Teams can be configured by mods using a Config node. For each desired team add a node named “TEAM” under the main “TFRNDSETTINGS” node with the following properties: points indicates the amount of research points (directly mapped to data units) generated by the team per update. Default is 100. costFactor indicates the cost per point of the research team. Defaults to 1. Added ConfigNodeExtensions from @stupid_chris with license information.
• NEW: TestFlight supported parts in the Editor now have a right click menu button R&D Windowwhich allows you to quickly open up a window to control research team allocation for the part.
• NEW: TestFlight now has a new Research and Development feature. This R&D System is optional, but allows you to trade off time and funds for increased part reliability. Rather than risking failures during a mission with low reliability parts, you can instead assign engineering teams to work on the parts over time, slowly increasing the part reliability without risk.
• NEW-CONFIG: New property added to ITestFlightCore to support R&D: rndMaxData defines the maximum amount of flight data that can be obtain by using engineering teams. This is defined in absolute units and if not present, R&D ill cap out at 75% of the part's maximum data
• NEW-CONFIG: New property added to ITestFlightCore to support R&D: rndRate defines the speed at which the part is research by engineering teams. This is a multiplier against the number of points generated by a team each cycle and defaults to 1, IE no modification.
• NEW-CONFIG: New property added to ITestFlightCore to support R&D: rndCost defines the cost at which the part is research by engineering teams. This is a multiplier against the cost of the team each cycle and defaults to 1, IE no modification.
• FIX: The following failures will re-apply themselves on loading a game: EnginePerformanceLoss, LockGimbal, ReducedMaxThrust, ResourceLeak
• NEW: TestFlightReliability_EngineCycle can now optionally modify accumulated burn time based on the actual thrust output of the engine. This is defined as a modifier curve using the FloatCurve thrustModifier
• NEW: TestFlightReliability_EngineCycle can now optionally decaythe used burn time on an engine when the engine is turned off. Can bedefined by using the property idleDecayRate. This value is directlysubtracted from the engine's current burn time each second, so a valueof 1 would be an approximate 1:1 time decay. This can optionally allowengines to have extended usage when shut off during coast periods.Note that this only kicks in if the engine is shut off (not ignited).
• NEW: TestFlightFailure_IgnitionFail can now apply an additional modifier to the chance of ignition based on the number of previous ignitions used. Use the FloatCurve ingitionUseMultiplier. This is a straight multiplier and thus values below 1 will lower the chance of the engine igniting and values above 1 will increase the chances.
• NEW: TestFlightFailure_IgnitionFail can now cause an additionalfailure to occur if the ignition fails. The chance of this occurringcan be set in the property additionalFailChance and is a value 0-1f,with default of 0. If this additional failure triggers then theengine will receive one of the existing random failures assigned to thepart.
• NEW-API: Add new property Failed to ITestFlightFailure interface.
• FIX: Persist the failed state on a part
• NEW: Add EngineModuleWrapper method to set the number of ignitions directly.
• NEW: ShutdownEngine failure now also removes all ignitions from the engine. They are restored is the failure is repaired.
• NEW-API: Add method to EngineModuleWrapper to return the current number of ignitions on an engine. int GetIgnitionCount()
• NEW-API: Added new functions to EngineModuleWrapper to Add and Remove ignitions from compatible engines. void AddIgnitions(int numIgnitions) and void RemoveIgnitions(int numIgnitions) Passing < 0 to RemoveIgnitions will remove all ignitions on the engine.

[Deimos Rast]

now that's an impressive update

[rgr]

if anyone wonders why testflight keeps forgetting it's settings, create GameData\TestFlight\Plugins\PluginData folder.

After that, I found out it'll be fixed in the 1.6 (1.1only) release...

[Filigan]

Has anyone a working config for KW Rocketry? There was a dropboxlink a few pages back but it is not available anymore 

 

[Agathorn]

On April 4, 2016 at 11:51 AM, rgr said:

if anyone wonders why testflight keeps forgetting it's settings, create GameData\TestFlight\Plugins\PluginData folder.

After that, I found out it'll be fixed in the 1.6 (1.1only) release...

Sorry I didn't see this post, but FYI this is also fixed in 1.5.4.3 and 1.5.4.4 which are both for KSP 1.0.5

[garwel]

Hey @Agathon, thank you for making this mod! Don't want to hurry you or anything. But as I'm preparing to start a new career and wanted to include TestFlight from the beginning, I'm curious if a 1.1-compatible version is in the works or if I should skip it for now.

UPD: After writing this, I discovered that there's a 1.1-compatible beta in Github. Guess I'll give it a try as soon as all other must-have mods are updated.

Edited April 22, 2016 by garwel

[garwel]

Ok, I ran the beta 2. Overall it appears ok, but the HUD in flight scene is just an small empty square window (I don't know what it was like in previous versions). It also looks like the Mk-55 "Thud" engine is not tracked by the mod.