TestLiteVsTestFlight

TestFlight? TestLite? Which, why, how?

(A blatant propaganda piece by the author of TestLite.)

NOTE: This guide was written prior to Test Flight v2.0 which was a major rewrite addressing a lot of the performance issues and other bugs raised.

Part failures in Realism Overhaul

RO (and RP-1) limit the scope of part reliability and failure to one thing: engines. Unlike stock TestFlight configs, which can make fuel tanks leak or antennas fail to deploy, RO only deals in engines either failing to ignite or in some way misbehaving during a burn.

There are two choices of failure mod currently supported by the RO configs: TestFlight and TestLite.

TestFlight

TestFlight by Agathorn is the 'original' failure mod, supporting a dizzying array of highly configurable failure types, part data recorders, etc. However, for that breadth of scope it does pay a price in performance, and also in complexity: writing configs for 'TF' is daunting enough that most people rely on (quite large) 'libraries' of ModuleManager patchwork to expand shorter and simpler configs (such as RO's own TESTFLIGHT nodes) into the requisite mass of modules.

The complexity also seems to have been too much for the developer: TF has a number of known or suspected bugs (not good for a Random Number God whose propriety needs to be above question).

TestLite

TestLite by soundnfury is the new kid on the block. Slim and simplified to deal only with RO's needs (it only deals with engines, and then only from RealFuels — stock is not supported), it is built around a clear mathematical model that uses the CDF to determine failure times, and the derivative PDF only for display purposes. This means that failure behaviour is not affected by such irrelevant factors as frame-rate, but also rules out using rather more relevant factors (namely dynamic pressure) that are not known at launch time (though they could still be used for ignition failures, they currently aren't). The time (i.e. burn duration) the engine will last before each possible failure strikes is actually rolled when the vessel spawns on the launchpad!

'TL' accepts the same TESTFLIGHT config nodes, having its own version of the MM patch to expand these out into something resembling a subset of the TF config language, for ease of transition from TF to TL.

Gameplay Differences

du Stacking

In TF, if multiple engines of the same config are used on the same launch, the data (du) from each are added together, whether they are in parallel (clustering à la Saturn I) or in series (e.g. a two-stage Aerobee). Each engine just earns some du and then throws them into the pot.

For TL this was decided to be unrealistic; instead, each engine records its starting du (at launch), then adds its own earned data onto that. The resulting du is the maximum reached by any engine. Thus if a cluster of eight engines all run without failure and collect 1,000du, you only get 1,000du (not 8,000du) added to the baseline for the next launch.

R & D

In TF there was an extra system of "R&D teams" you could hire to work on an engine-config, to turn funds into data (du). This interacted somewhat buggily with tech transfer, and tended to remove the 'test flight' part of TestFlight (most players R&D-ed every engine to the 2,500du limit, then put it straight into service with real payloads).

TL replaces this mechanic with two new per-part toggleables, Extra Telemetry and Extra Preflight, each of which increases the engine's cost by 100%. Extra Telemetry causes the engine to return double the data from both burn time and failures, while Extra Preflight knocks 25% off the failure rates for that one specific engine.

Extra Telemetry is meant to be used when flying a stage with a boilerplate payload (i.e. a genuine test flight), in order to raise the reliability of future launches (presumably with operational payloads). When clustering engines, typically only one engine in the cluster should be instrumented (because of TL's different stacking rules).

Extra Preflight is intended for those situations where you have a high-value payload, maybe even an interplanetary probe headed for an unslippable transfer window, and you just don't have the time to test-fly the engine enough to get its du up (or maybe the engine is so unreliable even with a full 10,000du that you need to throw more money at the problem). That one launch will be less likely to fail, but it doesn't do anything for the next one. It also doesn't do anything for any cluster partners; you will want to turn it on on all engines in the cluster.

Tech Transfer

TF's tech transfer system worked on the 'throw some du into the pot' method, which meant that you needed to prod the system (typically by hiring and immediately firing an R&D team) to trigger it, and as long as you were still under the 2,500du R&D limit you could transfer the same data multiple times, as the system did not keep track of what transfers had already been done. This also means that tech transfers can happen indirectly (i.e. data transferred from engine Mk I to Mk II can then feed the transfer to Mk III even if Mk III doesn't mention Mk I in its techTransfer config), which leads to trouble when the configs also do multi-generation transfers directly.

TL changes this to store only untransferred du in the save file; the transfer happens at the time the du is read (either in the VAB to calculate failure probabilities for display, or on the launchpad to roll the failure times). This avoids all the bugs in the TF system, and also means that the 'own' and 'total' (i.e. with transfer) du values can be displayed separately in the VAB. Meanwhile, only the untransferred du in the 'source' part is used for calculating the amount to be transferred, meaning that only direct transfers can happen.

One weirdness from TF that was kept is that the 'generations' in a techTransfer config string are written 'backwards' (i.e. newest generation first). This was kept for config compatibility, even though quite a lot of existing configs' writers didn't read the TF docs and put the oldest engine first.

GUI

TF had its own GUI including a toolbar button, a Master Status Display and a Heads Up Display. Reliabilities were always shown as MTBF (Mean Time Before Failure), and ignition failure rates were not visible at all.

In TL it was found that everything could be easily fit into the engine's PAW (right-click menu), so all extraneous GUI code was summarily removed. Ignition failure is always shown as a %, while in the VAB so is the full-burn failure rate (i.e. the probability of a failure (other than ignition) before the Rated Burn Time).

Ignition failures (and prelaunch)

In TF, an ignition failure (or a premature shutdown) always meant that the engine was dead; if it had more remaining ignitions, it would lose them. To work around this, an option was added to disable ignition failures while attached to launch clamps.

Ignition failures in TL do not kill the engine, which when combined with the ability to restart any engine while attached to launch clamps means that the disable-prelaunch-failures option is no longer needed (though it's still there if you want it). Premature shutdown failures come in two varieties, transient and permanent; a transient shutdown only stops the engine, it doesn't break it — so if you have ignitions left you can restart it. A permanent shutdown is, as the name implies, permanent, and leaves the engine dead. (There's even a 1 in 3 chance that the part will explode!)

Deterministic mode

An entirely new feature in TestLite is the option for determinism. When 'det mode' is enabled (through the difficulty settings), engines will never fail before their rated burn time, but on reaching that time (actually plus 5 seconds, because of the infant-mortality period) they will immediately fail. So you can't get unlucky and have an early failure, but you also can't get lucky and stretch a stage beyond spec.

Some users have asked for a best-of-both-worlds mode where failure is zero up to rated burn time and probabilistic after that. This will not be added; it has the same effect as just setting all reliabilities to 100% in the config files. Det mode is already easier than rolling the dice, it doesn't need making even easier by removing what little trade-off there is.