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

[Agathorn]

TestFlight

Flight testing comes to KSP!

TestFlight is an add-on for Kerbal Space Program that simulates the effect of increasing the reliability of your space hardware through flight testing.

Wikipedia defines Flight Testing as:

Quote

 

Flight testing is a branch of aeronautical engineering that develops and gathers data during flight of an aircraft, or atmospheric testing of launch vehicles and reusable spacecraft, and then analyzes the data to evaluate the aerodynamic flight characteristics of the vehicle in order to validate the design, including safety aspects.

The flight test phase accomplishes two major tasks:  1) finding and fixing any aircraft design problems and then 2) verifying and documenting the vehicle capabilities for government certification or customer acceptance. The flight test phase can range from the test of a single new system for an existing aircraft to the complete development and certification of a new aircraft, launch vehicle, or reusable spacecraft. Therefore, the duration of a flight test program can vary from a few weeks to many years.

 

 

 

 

In a nutshell TestFlight is a persistent, parts based research and reliability program. Your parts start out with an inherent failure rate that might be quite high on some parts, and quite low on others. As you fly those parts, you gain flight data. If the parts fail, and they will, then one of many failure modes can occur, some that can be repaired and some that can't. Either way you will accumulate data from failures and repairs as well. All this data is transmitted back to your spaceport, and the next time you fly the same hardware it will have a lower failure rate based on how much flight data you collected in the previous flight. This happens on a per part basis, along with RealFuels integration so that if you use RealFuels to change the engine to a different config derivative, that derivative will be tracked as well.

 

---

COMPATIBILITY

Kerbal Space Program : 1.0.5 (x86 only - Windows x64 is not supported.  Please don't give bug reports.  Linux x64 is fine, and Windows x64 should be ok come KSP 1.1)

RealismOverhaul : v8 or later of RealismOverhaul is supported. The TestFlight configs for RO are managed by that project and come installed with RO, so simply download the TestFlight Core plugin.

Stock: As of TestFlight v1.3, there is a TestFlight Config Pack for Stock parts as well, for those who want to experience TestFlight without playing RealismOverhaul. Be sure to download and install the TestFlight Config Pack for Stock, found in the GitHub release of TestFlight, or linked on KerbalStuff.

Kerbal Construction Time (KCT): TestFlight does work with KCT, however be aware that any flight data gathered while inside a KCT sim will be lost when you exit the sim. I am working with magico13 to provide tighter integration of TestFlight with KCT. Update: KCT now has some limited interaction to allow oyu to disable failures during a sim for testing.

 

---

REQUIREMENTS

ModuleManager: v2.6.1 or later

 

---

OVERVIEW

NOTE - This video is really old, and there have been lots of changes to TestFlight since then, both in game-play and the UI. However it still gives you a good feel of what TestFlight is all about.

 

 

 

---

CHANGES

TestFlight 1.7.0.0

• Lots of work on reducing TestFlight's Garbage footprint
• Performance improvements
• FIX: When assigning R&D to a part, first immediately apply any applicable tech transfer data
• FIX: KSC TestFlight window is now available even if TestFlight is disabled in that save
• FIX: Cleaned up left over direct log statements that were polluting the output_log file
• FIX: Fix NRE in TestFlightCore outside of Flight scene
• FIX: Fix how modules are enabled and disabled due to interop changes that was causing some modules to never become active when they should
• FIX: Fix NRE in the TestFlight Editor window.
• FIX: Fix issue with part selection locking for R&D Window in Editor
• CHANGE: TechTransfer and MaxRnD now stack
• UPDATE: Recompiled for KSP 1.1.3
• UPDATE: Recompiled for RealFuels 11.3.0

 

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.

 

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

 

QUICK START & DOCUMENTATION

You can find a Quick Start guide to get you up and running in a short amount of time, as well as full documentation (ever expanding) on the TestFlight Wiki.

 

---

DONATIONS

If you like TestFlight and want to give something back for the hundreds of hours of work I have put into it, please consider being kind and donating a few bucks through PayPal.

 

---

FAQ

Q: Can I make TestFlight configs for other parts?

Absolutely! If you want to make configs for other part packs and other play styles, please do! I will give you whatever support I can and answer any questions you may have.

 

Q: Can I use TestFlight for my mod?

Absolutely! If you want to create configs for your own parts, please do, and I will support you in any way I can.

 

Q: Can I extend TestFlight to add my own failures?

Yes you can! TestFlight was written from the ground up to be extendable. It consists of a core system for managing everything, for doing all the work, and a robust API that allows any modder to make his or her own TestFlight Modules that plug into the system. You can make your own Failure and Reliability modules, very easily, often in less than 100 lines of code.

 

Q: Why should I use TestFlight?

Well that is entirely up to you. I won't force you to use it. I wrote TestFlight firstly for myself, and simply decided to share it with the community. TestFlight can provide emergent gameplay and, like KCT or Life Support Mods, you will find it can drastically change the way your games unfold.

 

Q: My parts fail all the time! Even the one that are supposed to be reliable.

Understand that a very core part of TestFlight deals with probability and probability can be an interesting subject. A part may have an extremely low failure rate and thus be extremely unlikely to fail, ever, and yet it could still fail 2 seconds into flight. Just because something is extremely unlikely to happen doesn't mean it won't happen. The flip side of this is also true. You could fly engines with horrible reliability and they never fail! It happens.

 

---

INSTALL

Download the core TestFlight plugin from one of the links above, and simply extract the TestFlight folder into your KSP\GameData directory. Installation is just like most other mods.

Download one TestFlight Config Pack from one of the links above, and simply extract the TestFlight folder into your KSP/GameData directory. A ConfigPack is required or else you will have the plugin, but no parts will be configured to use it. However please ensure you install only one Config Pack or else unexpected things can go wrong.

OR

Install using CKAN. Please note that I can provide no support for problems with CKAN. If you should encounter issues or bugs with CKAN please see their release thread

• Please note that as of TestFlight v1.3, the mod is distributed in pieces containing the Core Plugin and Config Packs. You need the core plugin and one config pack. 

 

---

SUPPORT

Issue Tracking is done through GitHub.  If you have a bug feel free to post here and discuss it, but ultimately nothing will get fixed unless an issue exists on GitHub.

Read this post on how to gather proper logs for debugging.

In game, open the TestFlight settings and enable Debugging so that the logs will contain extra information to help me troubleshoot the issue.

 

Support requests without proper logs with TF debugging turned on may be ignored, as they are often impossible to deal with. Without logs there is no way to know what is going wrong.

 

---

Special thanks

NathanKell, and the gang in #ro for research help and support

TheVoid for early testing with RealismOverhaul

NonWonderDog for maths

anxcon for help maintaining and continuing development

 

---

LICENSE

This work is shared under CC BY-NC-SA 4.0 license.

 

Edited May 10, 2017 by Agathorn

[diomedea]

wait, an add-on about test flying? Absolutely can't miss it. Test flying things in KSP is one of my major activities .

Thanks a lot for it.

[Hattivat]

Time to try it, I guess, thanks for making this.

[Agathorn]

wait, an add-on about test flying? Absolutely can't miss it. Test flying things in KSP is one of my major activities .

Thanks a lot for it.

With shades like that, how can it not be?

- - - Updated - - -

Time to try it, I guess, thanks for making this.

Your enthusiasm overwhelms me! Remind me to razz you about it next time I see you in IRC

[NathanKell]

Great to see this in Releases!

[Jumpyyoza]

This looks like a REALLY cool mod! Insta-download!

[Hattivat]

Your enthusiasm overwhelms me! Remind me to razz you about it next time I see you in IRC

It was 2:42 AM in my timezone, so that was all the enthusiasm I could muster

[Agathorn]

Great to see this in Releases!

Thanks! It was a long hard road to release, but we're here now.

- - - Updated - - -

This looks like a REALLY cool mod! Insta-download!

Thanks, I hope it live up to your expectations

[JeffreyCor]

Unfortunately the current configs has the same deficiency as another failure mod, having to have each part specifically listed. A "catch all" for part class which individual overrides along the line of KeepFit to give immediate support for every part of a type in any mod and then different settings when desired for individual parts would give a much wider out of the box support.

[Agathorn]

Unfortunately the current configs has the same deficiency as another failure mod, having to have each part specifically listed. A "catch all" for part class which individual overrides along the line of KeepFit to give immediate support for every part of a type in any mod and then different settings when desired for individual parts would give a much wider out of the box support.

Certainly, and I encourage anyone who wants to pick this up for other configurations than RealismOverhaul to start that way. However for RealismOverhaul the focus is of course on the Realism, and every engine has different failure rates. A catch-all would not do service to RO.

I also think its important to have tech progression. I don't know what that progression is in Stock, but for example you can make it so that the some of the flight data from the LVT-30 is transferred to the LVT-45 when you first fly it. I need to do up a wiki page on how this works, but essentially the tech transfer system allows you to set it up so that certain parts are considered an upgrade path and a percentage of flight data can pass from one to the next.

I could certainly provide quick basic configs for Stock, and JeffreyCor you helped a lot on that in the early testing of TestFlight so thank you for that, but I just feel that providing simple configs is more a disservice and proper ones should be provided. And I just don't know the Stock game well enough to make proper ones.

But like I said if you or anyone else wants to do so, I will be glad to help you out in any way I can and provide a link to your configs here if you desire.

[diomedea]

Of course not everybody uses only the engines from RO. Even when I do use RO, I still have the stock engines (improved in realism because of all the add-ons dealing with them in RO), and still can use them.

So, a bit surprised to not find any stock engine yet configured. Now, trying to figure how to build a config for those myself.

The wiki is a nice way to show how, but at the moment I still can't find enough info to figure what to write (e.g., what the meaning of values with keys in TestFlightReliability module). Not a prob about the basic terms, I am pretty used to MTBF, Failure rates, MTTR, and all what makes the statistical aspects of reliability. Just the specifics of TestFlight modules so to start. Thanks.

[Agathorn]

Of course not everybody uses only the engines from RO. Even when I do use RO, I still have the stock engines (improved in realism because of all the add-ons dealing with them in RO), and still can use them.

So, a bit surprised to not find any stock engine yet configured. Now, trying to figure how to build a config for those myself.

The wiki is a nice way to show how, but at the moment I still can't find enough info to figure what to write (e.g., what the meaning of values with keys in TestFlightReliability module). Not a prob about the basic terms, I am pretty used to MTBF, Failure rates, MTTR, and all what makes the statistical aspects of reliability. Just the specifics of TestFlight modules so to start. Thanks.

Yes you are right I really need to improve the documentation. Let me take a stab at it here though.

Now that said, may I ask what you mean by you are playing RO but not using RO engines? The RO mod itself includes the configs for those engines, so are you removing them and replacing them with something else? Or did you mean to say you are only using the Stock engines as configured by RO into real engines? In the latter case the included TestFlight configs cover several of the Stock RO engines. The LR-89 and LR-105 engines use Stock engines as does the WAC-Corporal/Aerobee line.

First off, understand that TestFlight works as an aggregate of a bunch of modules on a part. Each module you add, provides additional functionality for that part in the system. At a bear minimum you will need two modules, but really at least four if you want it to be able to have any failure modes.

TestFlightCore

Required. You need this on every part. Doesn't need any properties for a basic setup. If you are applying to an engine that is defined by a ModuleEngineConfigs configuration block, then you will want to add the same configuration property as the original engine definition.

// Bare minimum
MODULE
{
    name = TestFlightCore
}

// If attaching to a ModuleEngineConfigs engine
MODULE
{
    name = TestFlightCore
    configuration = LR-89-5
}

FlightDataRecorder

Required. You also need this on every part. It is what actually records the flight data. You can either use the base one, or one of the two derived ones. The base on "FlightDataRecorder" will record data at all times during flight. "FlightDataRecorder_Engine" is intended for engines and only records data while the engine is actually ignited and running. "FlightDataRecorder_Resources" is intended for tanks and only records data while there are resources in the tank.

This module also takes the configuration property if needed, as well as flightDataMultiplier and flightDataEngineerModifier. The first defines the rate at which data is recorded, the second is a modifier (0 to 1) per level of an engineer if one is aboard. FlightData_Resources additionally has a emptyThreshold parameter that defines at what level or below the tank is considered empty.

// Engine example
MODULE
{
    name = FlightDataRecorder_Engine
    flightDataMultiplier = 10
    flightDataEngineerModifier = 0.25
}

TestFlightReliability

This module is responsible for both determining the reliability of a part, and for checking for failures. This one is a bit more confusing. You can have more than one of these on a part if desired, but only one can be the base "TestFlightReliability". In addition to configuration again if required (EVERY module has the configuration property), you need to add one or more RELIABILITY_BODY nodes to the base TestFlightReliability module. At the very least you need one for the "default" scope. This will apply to every scope unless overridden by another RELIABILTY_BODY node that defines a specific scope. Each RELIABILTY_BODY node defines two properties. scope and reliabilityCurve. The curve defines a standard KSP FloatCurve where the key is the amount of flight data and the value is the failure rate at that amount of flight data.

	MODULE
	{
		name = TestFlightReliability
		RELIABILITY_BODY
		{
			scope = default
			reliabilityCurve
			{
				key = 0 0.0127
				key = 10000 0.0075
			}
		}
		configuration = WAC-Corporal
	}

So that is a basic example that defines just the default scope with a curve that says "At 0 flight data the failure rate is 0.0127 and at 10,000 flight data the failure rate drops to 0.0075". Its a FloatCurve though so you can make it as complicated as you desire. Most of my setups currently use 4 keys to give a sharper decline in failure rate at first then level out after.

There is a derived module "TestFlightReliability_EngineCycle" which is designed to modify the current failure rate over time based on the engine cycle. Basically giving a bathtub curve with higher failure rate at first ignition, then lowering to normal values for a rated time then slowly increasing again.

TestFlightFailure

The most used module, there are several derived versions of this each defining a specific failure mode. Just add whichever ones you want. This is where the majority of your config properties are set. There are a bunch of basic properties to define every failure, as well as repairs, and then each individual failure type may have some specialized ones.

failureType = "mechanical" or "software"

severity = "minor", "failure", or "major"

weight = 2 or 4 or 8 or 16 or 32 -- Defines a relative weight for the failure. When the system rolls to pick a random failure, this weight determines its relative weight amongst all failures and must always be one of these values

failureTitle = short string to show to the player to indicate the failure

duFail = amount of flight data that should be granted when this failure occurs

duRepair = amount of flight data to be granted when the failure is repaired

oneShot = true or false, generally false. If oneShot is true the failure happens, the bad things happen, but the part is NOT placed into a failed state

The last three are optional. Additionally you can define an optional REPAIR node that defines the requirements for repair. If no REPAIR node is given then the failure can't be repaired.

Here is an example

	MODULE
	{
		name = TestFlightFailure_ShutdownEngine
		failureTitle = Engine Shutdown
		duFail = 100.0
		failureType = software
		duRepair = 50.0
		severity = failure
		configuration = WAC-Corporal
		weight = 16
		REPAIR
		{
			repairChance = 75
			canBeRepairedOnSplashed = True
			canBeRepairedByRemote = True
			canBeRepairedInFlight = True
			dataScale = 1
			dataSize = 1
		}
	}

The following failure modules are available, and i've indicated any additional properties in ()

TestFlightFailure_ShutdownEngine

TestFlightFailure_ResourceLeak (resourceToLeak = "random" or a name of a resource, initialAmount = amount to leak on first tick right away, perSecondAmount = amount per second to leak)

TestFlightFailure_ReducedMaxThrust (thrustReduction = multiplier, 0 to 1, amount to reduce maximum thrust by)

TestFlightFailure_LockGimbal

TestFlightFailure_IgnitionFail (restoreIgnitionCharge = true or false, of true and EngineIgnitor mod is used it will restore the used up charge)

TestFlightFailure_Explode

Ok that's a start. Please ask any followup questions you may have, or if you have any problems getting it to work. I will work on expanding the Wiki but TestFlight is a surprisingly complex beast with a very large scope to document.

[Wercho]

This seems really cool. I like that failures are reduced through use of a part. I don't play RO, so I'll wait for more stock support / general configs for use with mods, but I like the way this is going. A couple of questions:

Does this work with procedural parts? I know Dang It doesn't (yet) because PP tanks don't have a RESOURCE module in the base config, or something like that.

Does the resourceleak failure work on electric charge, or mod added resources? I presume yes.

Any plans to add other failure modes for other parts, such as solar panels, etc.

Anyway, really cool stuff.

[Agathorn]

This seems really cool. I like that failures are reduced through use of a part. I don't play RO, so I'll wait for more stock support / general configs for use with mods, but I like the way this is going. A couple of questions:

Does this work with procedural parts? I know Dang It doesn't (yet) because PP tanks don't have a RESOURCE module in the base config, or something like that.

Does the resourceleak failure work on electric charge, or mod added resources? I presume yes.

Any plans to add other failure modes for other parts, such as solar panels, etc.

Anyway, really cool stuff.

1. Yes it works with procedural parts, though it would depend on the failure modules you wanted to apply. That said I have not coded in any SPECIFIC handling of pParts and I plan to do so, so that for example you could set things differently based on the size of the part. I just haven't gotten to that yet.

2. Yes it should work on anything that uses resources in the normal way.

3. Definitely. This is a base to build upon, and I plan to add a lot to it over time.

[diomedea]

Agathorn, many thanks for your detailed explanation.

Of course it will take a bit of time to experiment, I can't be sure yet to have got it all right. But sure will come asking again in case.

One thing I would know already about the repair mode (e.g. CanBeRepairedInFlight), those modes just mean a button wil appear to let the part be repaired upon clicking? I ask because would like to see the possibility that EVA is required to repair some parts.

About the engines, I mean I'm not finding the stock engines configured, even if changed in RO. Not yet clear if that is because of a bad install. I did a couple tests building a vessel with one of those reconfigured engines, and in flight mode, TestFlight seems unable to find it (it gives a message on the MSD "TestFlight is not currently tracking any vessels", and I infer it is because no engine was recognized. Unclear if I should in some way make TestFlight look at the engine while in the Editor, I can't find an option for that.

[Agathorn]

Agathorn, many thanks for your detailed explanation.

Of course it will take a bit of time to experiment, I can't be sure yet to have got it all right. But sure will come asking again in case.

One thing I would know already about the repair mode (e.g. CanBeRepairedInFlight), those modes just mean a button wil appear to let the part be repaired upon clicking? I ask because would like to see the possibility that EVA is required to repair some parts.

There is an option you can specify, requiresEVA. However at this time while you can set it, it is ignored because I haven't figured out the code for it yet

About the engines, I mean I'm not finding the stock engines configured, even if changed in RO. Not yet clear if that is because of a bad install. I did a couple tests building a vessel with one of those reconfigured engines, and in flight mode, TestFlight seems unable to find it (it gives a message on the MSD "TestFlight is not currently tracking any vessels", and I infer it is because no engine was recognized. Unclear if I should in some way make TestFlight look at the engine while in the Editor, I can't find an option for that.

Can I ask which engine(s)? If TestFlight isn't attaching then it means that the config name in TF isn't matching what is in RO. They should be correct based on a clean RO install but I might have a mistake somewhere.

[diomedea]

There is an option you can specify, requiresEVA. However at this time while you can set it, it is ignored because I haven't figured out the code for it yet

Thanks. Looking forward to that.

Can I ask which engine(s)? If TestFlight isn't attaching then it means that the config name in TF isn't matching what is in RO. They should be correct based on a clean RO install but I might have a mistake somewhere.

Tried the P&W RL-10, Rocketdyne H-1, Rocketdyne LR-105. Possible other engines too, have not found any getting tracked by TestFlight yet.

I'm not running the full list of RO recommended add-ons currently, just a minimum subset to check this. Got a pic of one test here, maybe useful. Nothing in the output_log to suggest a problem.

EDIT: did a test with stock parts (not RO-modified) after having copied these config files from a dev version of TestFlight: "Squad_Engines.cfg" and "Squad_FuelTanks.cfg". Launched a rocket, and both tank and engine installed were recognised. Therefore confirmed TestFlight works, just a problem either with config or my install of RO to make parts not recognized.

Edited February 9, 2015 by diomedea
new info

[Agathorn]

Thanks. Looking forward to that.

Tried the P&W RL-10, Rocketdyne H-1, Rocketdyne LR-105. Possible other engines too, have not found any getting tracked by TestFlight yet.

I'm not running the full list of RO recommended add-ons currently, just a minimum subset to check this. Got a pic of one test here, maybe useful. Nothing in the output_log to suggest a problem.

Ok actually none of those are in TestFlight yet sorry. With so incredibly many RO engines, I needed a plan so what I decided to do was work on the engines from earliest to latest in the RP-0 tech tree. I am doing the RL-10 right now so that will be in the next update. Looking at my list the only engine I guess that you should have is the LR-89. The Aerobee Sustainer as well but I think that is configured by RP-0 not RO so you might not have that one.

The LR-105 should also be configured, but its possible I messed up the config on that one. I'll double check it. The LR-89 and LR-105 are a bit confusing on my end because RP-0 and RO both use them with DIFFERENT Stock parts

[Agathorn]

So my apologies here. I didn't realize really that most of the engines I initially supported come from other part packs than Stock in RO. I am working very hard to expand the amount of engines supported by TestFlight and the next release should add 5 or so more plus derivatives, and I will keep pushing to get more and more parts in here as quickly as I can.

[FennexFox]

Will it cause any problem if I install this mod on ongoing save?

Edited February 9, 2015 by FennexFox

[diomedea]

.... I am working very hard to expand the amount of engines supported by TestFlight and the next release should add 5 or so more plus derivatives, and I will keep pushing to get more and more parts in here as quickly as I can.

Much understandable. Really too many the engines to deal with (and then other parts too).

But I'm happy to already see the add-on working, to get acquainted with it, and with the prospect of credible progress in the reliability of parts.

[Agathorn]

Will it cause any problem if I install this mod on ongoing save?

The main issue you would have is that any craft you switched to for the first time should get initialized with your current level of flight data for its parts, which if you just installed this and immediately switched to a craft, would be 0. What you would need to try doing for an existing save would be install, then do NOT switch to any active craft but instead start flight testing the parts you have already used on your existing craft. Then once you have those parts to where you ant them, switching to your already existing active craft should initialize them with that data. This happens the first time TestFlight sees a vessel.

All of that said, I have never tested adding this to an existing save, so I'm not 100% sure on the side effects. I strongly suggest using TestFlight for the first time in a new game.

[Agathorn]

Just a quick note to say that TestFlight is now available through CKAN.

Also I have updated the Parts Compatibility in the OP to indicate what part packs the supported parts come from.

[Sampa]

I'll wait until someone comes out with a stock config for this before downloading...I AM interested, though!

[Agathorn]

TestFlight v1.1.0.0

Change Log

• Changed AJ10 engine config names to line up with RP-0
  
• NEW ENGINE: XLR11 (FASA Pack) --> XLR99
  
• NEW ENGINE: LR-87-3 (FASA and AIES Packs) --> LR-87-5 --> LR-87-7 --> LR-87-9 --> LR-87-11 --> LR-87-11A
  
• NEW ENGINE: RL10A-1 (Squd, KW, and FASA Packs) -> RL10A-3-1 --> RL10A-3-3 --> RL10A-3-3A --> RL-10A-4 --> RL-10A-4-1/2 --> RL10B-2 --> RL10C-1
  
• FIX spelling error in settings window
  
• FIX #47 Parts that are destroyed or staged will now remain in the MSD for about 15 seconds giving you time to see their status
  
• FIX Incorrect LR-89 engine reference
  
• NEW Initial support for Procedural Tanks, more to come on this!
  

Download from GitHub: https://github.com/jwvanderbeck/TestFlight/releases/tag/1.1.0.0

Download From KerbalStuff: https://kerbalstuff.com/mod/572/TestFlight