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

Agathorn · June 3, 2016

As @Phineas Freak states, that is a bad example because it is just one piece in the massive cog that is RO. It is very clever MM script that takes data we put in other places and builds the findl TF configs for the engines.

You could, as stated, install RO, run it, then look at the final MM cache but while that is easy it is probably a real pain for someone who doesn't want to run RO in the first place

The documentation you link to ti is mostly up to date, but might be missing some of the newer features. It is a solid base though. That said, it makes mention of the yaml syntax which you may or may not want to do with. The yaml config is an intermediate config that is used to build the final configs in the project. It allowed me to more easily have multiple parts with the same configs without having to duplicate them. But to use the yaml you need to update the yaml file then run the processor to turn them into cfg files, which again you probably don't want to mess with.

Instead you can just write the configs straight up and use those. The wiki documentation covers the various properties available on the modules, what they do, and what the modules do. It doesn't cover any pure MM information though so you really need to know what you are doing with configs in general before diving in.

Also the RO configs are further confused by the fact that in RO a single engine PART can have multiple configurations, allowing the player to swap between sub models of an engine in runtime. TestFlight has to work with this, so the configs are more complicated in that you will see multiple entries for the same TF module sometimes, one for each config.

That said, here is a an example of an ENGINE config. Different parts will be different given what modules they have on them. The `configuration` property in each of these can usually be ignored in Stock.

		MODULE
		{
			name = TestFlightInterop
		}
		MODULE
		{
			name = TestFlightCore
			title = LR105-NA-3
			configuration = engineConfig = LR105-NA-3:LR105-NA-3
			maxData = 10000
			techTransferMax = 2000
			techTransfer = 
		}
		MODULE
		{
			name = FlightDataRecorder_Engine
			configuration = LR105-NA-3
			flightDataEngineerModifier = 0.4
			flightDataMultiplier = 1.93939393939394
		}
		MODULE
		{
			name = TestFlightReliability
			configuration = LR105-NA-3
			reliabilityCurve
			{
				key = 0 0.000303030303030303
				key = 2250 0.000150757575757576 -1.34261974584556E-08 -1.34261974584556E-08
				key = 10000 0.0001 0 0
			}
		}
		MODULE
		{
			name = TestFlightReliability_EngineCycle
			configuration = LR105-NA-3
			ratedBurnTime = 330
			engineConfig = LR105-NA-3
			cycle
			{
				key = 0.00 10.00
				key = 5.00 1.00 -0.8 0
				key = 335 1 0 0
				key = 500 100 0 0
			}
		}
		MODULE
		{
			name = TestFlightFailure_ShutdownEngine
			configuration = LR105-NA-3
			duFail = 100
			weight = 32
			failureType = software
			failureTitle = Engine Shutdown
			duRepair = 50
			severity = major
			REPAIR
			{
				canBeRepairedInFlight = True
				dataSize = 1
				dataScale = 1
				repairChance = 75
				canBeRepairedOnSplashed = True
				canBeRepairedByRemote = True
			}
		}
		MODULE
		{
			name = TestFlightFailure_IgnitionFail
			configuration = LR105-NA-3
			restoreIgnitionCharge = False
			duFail = 300
			oneShot = True
			failureType = mechanical
			failureTitle = Failed to ignite
			additionalFailureChance = 0.2
			ignorePressureOnPad = True
			severity = major
			pressureCurve
			{
				key = 0 1 0 0
				key = 5000 1 0 0
				key = 15000 0.85 -2.25E-05 -2.25E-05
				key = 30000 0.4
				key = 50000 0.15 0 0
			}
			baseIgnitionChance
			{
				key = 0 0.89
				key = 2250 0.95 5.29032258064516E-06 5.29032258064516E-06
				key = 10000 0.97 0 0
			}
		}
		MODULE
		{
			name = TestFlightFailure_ReducedMaxThrust
			oneShot = True
			configuration = LR105-NA-3
			duFail = 100
			weight = 8
			failureType = mechanical
			failureTitle = Loss of Thrust
			duRepair = 250
			severity = minor
			REPAIR
			{
				canBeRepairedInFlight = False
				canBeRepairedOnSplashed = False
				canBeRepairedByRemote = False
				repairChance = 75
			}
		}
		MODULE
		{
			name = TestFlightFailure_EnginePerformanceLoss
			oneShot = True
			configuration = LR105-NA-3
			duFail = 100
			weight = 16
			failureType = mechanical
			failureTitle = Performance Loss
			duRepair = 250
			severity = minor
			ispMultiplier = 0.5
			ispMultiplierJitter = 0.1
			REPAIR
			{
				canBeRepairedInFlight = False
				canBeRepairedOnSplashed = False
				canBeRepairedByRemote = False
				repairChance = 75
			}
		}
		MODULE
		{
			name = TestFlightFailure_Explode
			configuration = LR105-NA-3
			failureTitle = Explosion!
			duFail = 400
			weight = 2
			failureType = mechanical
			severity = major
		}

Now to quickly address the batteries. Why did they fail? The stock configs I did have no special configs for batteries IIRC. Most likely they are simply getting picked up as "tanks" that hold electrical charge. Further mode I think those configs were written before I added the ability for parts to have super low failure rates more conducive to missions that last for years. I'm not sure if it documented on the wiki but on the TestFlightCore module you can add a property `failureRateModifier` which is a multiplier against the base failure rate of the part. It defaults to 1, and thus no change. But if you set it to something smaller than 1, like 0.5 for example, then the effective base failure rate of the part will be half what the config states it is, and you can go even lower if needed.

Edited June 3, 2016 by Agathorn

CoriW · June 3, 2016

@Agathorn

Awesome, thank you for the clarification on the configs as well as the example you've provided. This will definitely help me with re-writing the stock configs to something more usable.

As for the batteries your assumption is absolutely correct, TestFlight appears to treat them just the same as fuel tanks. During my flights I've noticed that not only will batteries fail in an explosion, but they can also be afflicted with "leaking" as well. Aside from that, I've found that everything fails very quickly even when I had reached full data units on various parts. The "failureRateModifier" will come in extremely useful when it comes to putting together some configs that don't result in this rapid failure of everything during longer term missions.

There was one other thing I noticed as well when I was playing with TestFlight yesterday. After having a particularly catastrophic failure on my vessel, I decided to load the last quicksave and upon doing so I found that the various minor failures that were listed in the TestFlight window before I had made the quicksave seemed to be missing from the display, while the effects from the failures (Leaks and such) were still present on the vessel. Is this a known issue with TestFlight and quicksaving/quickloading?

Agathorn · June 3, 2016

See also these posts, though bear i mind they are older:

Quote

There was one other thing I noticed as well when I was playing with TestFlight yesterday. After having a particularly catastrophic failure on my vessel, I decided to load the last quicksave and upon doing so I found that the various minor failures that were listed in the TestFlight window before I had made the quicksave seemed to be missing from the display, while the effects from the failures (Leaks and such) were still present on the vessel. Is this a known issue with TestFlight and quicksaving/quickloading?

Not a known issue, but certainly shouldn't be happening. Just to be clear, the minor failures existed when you saved? So restoring back to that save should bring the failures back, but they ASO should appear in the window. I added that relatively recently though and i'm not sure it got well tested, so might be a bug.

Any chance you could provide this save file?

CoriW · June 3, 2016

4 minutes ago, Agathorn said:

See also these posts, though bear i mind they are older:

Not a known issue, but certainly shouldn't be happening. Just to be clear, the minor failures existed when you saved? So restoring back to that save should bring the failures back, but they ASO should appear in the window. I added that relatively recently though and i'm not sure it got well tested, so might be a bug.

Any chance you could provide this save file?

Yes, the minor failures (leaks) existed when I quicksaved and upon reloading that quicksave the TestFlight window no longer showed the failures, though the effects from the failures were still present.

Unfortunately I don't have the save file on hand, and I had also removed TestFlight from my install yesterday before I decided to re-write the configs.. Now that I'm thinking about it as well, I'm using a heavily modded install (currently running 96 mods/plugins) so I'm unsure if this could be a conflict of some sort. I suppose what I could do though is start up an unmodded game with just TestFlight installed and see if I can replicate the problem, then I'll get back to you. Actually I'll do that right now so I should have the results within the next half hour or so.

razark · June 3, 2016

7 hours ago, CoriW said:

I'm willing to take a shot at re-doing the stock configs...

I'd just like to say thank you for your efforts into this. I've considered looking into it myself, but I just haven't found the time to really dig into the understanding of the details needed.

CoriW · June 3, 2016

@Agathorn

Alright so in my rush I accidentally grabbed the beta build when testing on stock KSP with just TestFlight installed, but based on my testing I think it's safe to assume that this is also occuring on the current release build as that's what I was using on my main install when I experienced this issue as well. So I'm providing my test save below, there is one ship in orbit with a whole lot of batteries on it.. When you load it up, timewarp for a bit until you see some batteries leaking, then quicksave and quickload and what you'll find is that suddenly the leaking batteries are no longer appearing in the TestFlight window.

As a bit of a side note, while testing I found that this would also happen by simply switching away from the vessel (back to the space center) and then back to the vessel.

Edit: Almost forgot the link https://dl.dropboxusercontent.com/u/74725194/KSP/TEST.rar

Edited June 3, 2016 by CoriW

Deimos Rast · June 9, 2016

So I've been watching and waiting for a change in the thread title or OP to indicate this works in 1.1.2 for a while now. I decided to check the github page to see if there was any activity and...updates for days, all for 1.1.2, going back months. Maybe update the OP/title, because there is currently no mention that this works in 1.1.2 at all. :huh:

Edited June 9, 2016 by Deimos Rast

CoriW · June 11, 2016

@Agathorn

Hey so I've been pretty busy lately and haven't had the chance to look at the configs until now. Just had a few questions that I'm unsure about.

1) What is the deepSpaceThreshold property for the TestFlightCore module?

2) How exactly do the keys in the TestFlightReliability reliabilityCurve effect failure rate?

3) In the TestFlightFailure_IgnitionFail module, how do the keys in the pressureCurve work?

4) I've noticed in several of the keys in your example, there are 2 numbers, where as in other keys there are 4? What is the difference and where do you get the second two numbers from?

EDIT: I've just noticed that I forgot to check the posts you've linked.. I'm removing questions from this post as I find the answers to them.

EDIT: The one part I'm having the most trouble with, is how do I translate the numbers entered into the reliabilityCurve into a time duration. If the reliability is 0.00015, what would that make the MTBF?

EDIT: I've found a very useful post that explains #4 very well..

EDIT: New question, in the TestFlightFailure_ReducedMaxThrust module; If thrustReduction is not specified is the percentage of thrust reduction randomized? I'm just asking because I notice this property mentioned in the documentation, but in the engine config example you've provided above I don't see that property specified.

Edited June 11, 2016 by CoriW

Agathorn · June 11, 2016

19 hours ago, CoriW said:

@Agathorn

Hey so I've been pretty busy lately and haven't had the chance to look at the configs until now. Just had a few questions that I'm unsure about.

1) What is the deepSpaceThreshold property for the TestFlightCore module?

2) How exactly do the keys in the TestFlightReliability reliabilityCurve effect failure rate?

3) In the TestFlightFailure_IgnitionFail module, how do the keys in the pressureCurve work?

4) I've noticed in several of the keys in your example, there are 2 numbers, where as in other keys there are 4? What is the difference and where do you get the second two numbers from?

EDIT: I've just noticed that I forgot to check the posts you've linked.. I'm removing questions from this post as I find the answers to them.

EDIT: The one part I'm having the most trouble with, is how do I translate the numbers entered into the reliabilityCurve into a time duration. If the reliability is 0.00015, what would that make the MTBF?

EDIT: I've found a very useful post that explains #4 very well..

EDIT: New question, in the TestFlightFailure_ReducedMaxThrust module; If thrustReduction is not specified is the percentage of thrust reduction randomized? I'm just asking because I notice this property mentioned in the documentation, but in the engine config example you've provided above I don't see that property specified.

1. Not used anymore

2. The values indicate the base failure rate for a given amount of data units. The key is the amount of data, the value is the base failure rate at that point

3. key is the pressure, value is the modifier applied against ignition chance as a multiplier

MTBF is 1/BFR if I recall correctly. But bear in mind that MTBF is more of a derived number provided to present something to an end user that looks good and makes sense to them.

As for your last question about ReducedMaxThrust, the default is a 50% reduction if not specified.

CoriW · June 11, 2016

1 hour ago, Agathorn said:

3. key is the pressure, value is the modifier applied against ignition chance as a multiplier

MTBF is 1/BFR if I recall correctly. But bear in mind that MTBF is more of a derived number provided to present something to an end user that looks good and makes sense to them.

1) For the pressureCurve keys, what unit exactly is "pressure" measured in? I'd assume it's not barometric pressure, as the numbers in your example seem much too high for that to be the case.. Is it altitude? Also the value appears to be measured between 0 and 1, how exactly is that modifier applied against ignition chance?

2) So if the reliability was at 0.0005 then 1/0.0005 = 2000, what unit would that be? Seconds, Minutes, Hours?

Edited June 11, 2016 by CoriW

Agathorn · June 11, 2016

1) Pretty sure it is pascals which is what KSP uses. As for the value, it can be whatever it is just a multiplier against the base ignition chance. So 1 would be no change, 0.5 would make it half as likely to ignite than normal, 2 would make it twice as likely to ignite.

2) Seconds

CoriW · June 11, 2016

@Agathorn

Ah alright, thank you.

Also a question that's a bit less related to the configs and more related to rockets in general... I'm not sure how well you'll be able to answer, but since you've created this mod I'm hoping that you'll have some general ideas on the subject.

1) Do SRB's tend to fail more or less often than Liquid Fuel Engines?

2) Would a larger SRB be more or less stable than a smaller SRB? (Stable in terms of failure rate)

3) Would a larger Liquid Fuel Engine be more or less stable than a smaller Liquid Fuel Engine?

Actually on second thought I do also have another question about the configs.

4) Do you think it would be possible to make some sort of engine config that could blanket, for example, all of an engine type? (say SRB's for example) Using calculations in the config based on stats of the engine in order to determine things such as the reliabilityCurve, EngineCycle, IgnitionFail pressureCurve, etc? The reason I'm asking is because if it would be possible, then not only would these configs work with stock engines, but also modded engines as well. I got to thinking about this because I've noticed just how many engines there are in the base game, let alone the several mods I have that add new engines. (Basically don't feel like having to do entire new configs for every mod I install that adds news engines.)

EDIT: Oh also, how do the techTransfer and techTransferMax properties work?

EDIT: Could I propose a change to TestFlightFailure_ResourseLeak? I've been working on these configs for about 2 days now and the one thing I keep finding myself coming back to is the fuel tank config... The problem I see with how it is currently implemented, is that any fuel tank is basically guaranteed to start leaking eventually no matter what the reliability is and even if it's just out in space where I would imagine very little if any degradation would happen to the tank.

My proposal is to make TestFlightFailure_ResourceLeak into something that checks a pressureCurve and temperatureCurve and applies a modifier to the failure chance instead of the current generic MTBF system. This would prevent the issue of a tank that's been just floating in space from randomly springing a leak for no apparent reason.

Actually for that matter, I think that engine failures should follow a similar principle as well.. Have things fail due to certain conditions, not because of some arbitrary time factor. I mean, if the tank or engine is inside of an atmosphere, then it makes sense for there to be some kind of degradation over time and that could be defined using a pressureCurve and temperatureCurve as well. Aside from degradation, tank failures could be made more frequent while the engines on a ship are firing, potentially using a floatCurve to define a higher momentary failure rate during high G-Force load.

Back to the subject of engine failures, currently there is TestFlightFailure_IgnitionFail which I believe works very well as it takes into account a base reliability in the baseIgnitionChance and then also takes into consideration the external environment in the form of the pressureCurve, though one thing I may suggest here as well is also introducing a temperatureCurve as well. As for the other types of engine failures, such as ShutdownEngine, EnginePerformanceLoss, ReducedMaxThrust, etc, I feel that these should only be induced by certain conditions as well. Maybe you could still have a generic MTBF that would increase the failure chance over time, but only allow failures to occur during the actual operation of the engine.

Edited June 12, 2016 by CoriW

Aelfhe1m · June 12, 2016

My output log is being spammed with the following message pattern:

Spoiler


(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 64)

UIMasterController: ShowUI
 
(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 64)

6/12/2016 6:36:15 PM,TestFlightCore,Setting HideUI = True
 
(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 64)

6/12/2016 6:36:15 PM,TestFlightCore,Setting HideUI = True
 
(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 64)

6/12/2016 6:36:15 PM,TestFlightCore,Setting HideUI = True
 
(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 64)

6/12/2016 6:36:15 PM,TestFlightCore,Setting HideUI = True
 
(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 64)

UIMasterController: HideUI
 
(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 64)

6/12/2016 6:36:16 PM,TestFlightCore,Setting HideUI = False
 
(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 64)

6/12/2016 6:36:16 PM,TestFlightCore,Setting HideUI = False
 
(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 64)

6/12/2016 6:36:16 PM,TestFlightCore,Setting HideUI = False
 
(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 64)

6/12/2016 6:36:16 PM,TestFlightCore,Setting HideUI = False
 
(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 64)

UIMasterController: ShowUI
 
(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 64)

6/12/2016 6:36:22 PM,TestFlightCore,Setting HideUI = True

It only starts after a vessel is launched and it's not really a huge problem since it's only a dozen or so messages every few seconds but it adds up over a play session into multi-gigabyte log files.

Agathorn · July 2, 2016

On 6/12/2016 at 11:39 AM, Aelfhe1m said:

My output log is being spammed with the following message pattern:

Reveal hidden contents



(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 64)

UIMasterController: ShowUI
 
(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 64)

6/12/2016 6:36:15 PM,TestFlightCore,Setting HideUI = True
 
(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 64)

6/12/2016 6:36:15 PM,TestFlightCore,Setting HideUI = True
 
(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 64)

6/12/2016 6:36:15 PM,TestFlightCore,Setting HideUI = True
 
(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 64)

6/12/2016 6:36:15 PM,TestFlightCore,Setting HideUI = True
 
(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 64)

UIMasterController: HideUI
 
(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 64)

6/12/2016 6:36:16 PM,TestFlightCore,Setting HideUI = False
 
(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 64)

6/12/2016 6:36:16 PM,TestFlightCore,Setting HideUI = False
 
(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 64)

6/12/2016 6:36:16 PM,TestFlightCore,Setting HideUI = False
 
(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 64)

6/12/2016 6:36:16 PM,TestFlightCore,Setting HideUI = False
 
(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 64)

UIMasterController: ShowUI
 
(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 64)

6/12/2016 6:36:22 PM,TestFlightCore,Setting HideUI = True

It only starts after a vessel is launched and it's not really a huge problem since it's only a dozen or so messages every few seconds but it adds up over a play session into multi-gigabyte log files.

This should be fixed in the latest beta and thus should be fixed in the final release of 1.7

Agathorn · July 5, 2016

TestFlight 1.7.0.0

Changes

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

Gordon Dry · July 9, 2016

Why didn't you change the topic for 1.7.0.1 ?

gruneisen · July 12, 2016

I'd like to make a suggestion to remove the 'performance loss' failure mode from solid rocket motors. There's really no way this can happen in reality - they're either going to blow up, or just...blow up.

The failure modes associated solid motors are usually a propellant grain structural failure, a propellant and case / liner disbond, or a case structural failure. Part of the reason solid motors are desirable is that they are mechanically simple with few failure modes and have high ignition reliability. Anyway - just a thought I've had. I'd be curious to see what you all think.

Also, on a different subject, is there a way to change to key which activates the test flight information window in the VAB? I use a laptop running Ubuntu and don't usually use a mouse. I've remapped a key to do it, but it wreaks havoc with the 10 key pad to do so.

Thanks and cheers!

Edited July 12, 2016 by gruneisen
reek vs. wreak? Too much Game of Thrones for me...

Phineas Freak · July 12, 2016

17 minutes ago, gruneisen said:

they're either going to blow up, or just...blow up.

Or have a nozzle burn - through (difficult but possible) and suffer a major loss of performance regarding Isp and thrust.

gruneisen · July 12, 2016

31 minutes ago, Phineas Freak said:

Or have a nozzle burn - through (difficult but possible) and suffer a major loss of performance regarding Isp and thrust.

Hey Phineas -

Nozzle erosion is certainly an issue and I considered this as I was writing my first post...you could suffer a thrust loss as a result, but it would be minor at best. You have to think that the thickness of the nozzle at the throat isn't all that great, so you don't have a very large change in diameter resulting from erosion. If you burnt all the way through the throat (or through a case joint in terms of segmented motors [such as what happened to Challenger... ]), you again wouldn't see a huge decrease in thrust - more so ISP since you're venting mass to the atmosphere and thereby loosing the expansion cone of the nozzle. There just really isn't anything that can appreciably decrease the thrust of a solid rocket motor unexpectedly and not end in out and out catastrophe.

Joshua42 · July 17, 2016

So somehow I've managed to turn off test flight in my rp0 1.1.2 career and I can't find a single post about how to turn it back on. It's installed and the configs are there and correct. Any ideas?

autumnalequinox · July 19, 2016

I'm curious as to how you assign research teams. I click the R&D on an engine and a window pops up in the VAB that just has the engine name but no other GUI besides "lock window" toggle. I'm playing in RP-0 is there something I must unlock first? Also at the Space Center the R&D window is blank.

Nevermind: The window now shows "part data meets or exceeds.." so I'm guessing I've flown it so much it can't be improved anymore.

Final Edit: Actually I just got a new set of engines through the Research and they have not yet been tested. The R&D button in the VAB just brings up a blank screen.

Edited July 19, 2016 by autumnalequinox

Sir_Fanch · July 30, 2016

Anyone have a decent alternative to KCT for running simulations without TestFlight failing parts? Love the mod, but I'm playing a no revert game, and kinda need to know how a rocket will perform if everything goes right, simulating a launch 5 times because the same engine failed get's tedious and rather time consuming given most of the time it's an engine I've not flown and so the failure rate is through the roof while simulating. Or is there a way to manually temporarily disable part failures?

Phineas Freak · July 31, 2016

@Sir_Fanch as far as i know there is no other way around but to a) disable TF temporarily or b) have a secondary save for testing (with TF disabled).

Ideally, there should be a TF API where KCT can hook up and disable TF when a simulation is underway.

Sir_Fanch · August 1, 2016

@Phineas Freak Yeh I figured as much, I remember reading somewhere that KCT was removing simulations also so I thought I'd check just in case. Generally it isn't too huge of a deal, but if I'm testing a design that uses engine clusters the chances of one of them failing is pretty high, generally the flight isn't ruined from a single engine failure, but my testing of launch profiles and rocket performance definitely is . Anyways, thanks for the info, you're a great help as always mate .

blu3wolf · August 1, 2016

Mebbe talk to LGG about KRASH implementation with TF?

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

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Changes

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Join the conversation