Proposal: Handling Procedural Tanks

Brief

This proposal looks at one method for handling procedural tanks in TestFlight without needing to make core changes to the plugin, or require excessive amounts of config modules which cause performance issues in KSP and ModuleManagaer

Details

The underlying concept here is to provide a configurable system that works not by specifying modules based on interops, but rather specifies information on how to handle changes to the parts.

By default a procedural tank is recorded by TestFlight as a single part, regardless of any changes made to the part such as length, diameter, tank type, or shape. A config would essentially specify what the penalty is (in terms of du) for each type of change to a tank, and record a new part based on the physical properties of the tank.

The configuration for this system would essentially indicate how much of a data unit penalty a new part should incur from certain changes. A change in diameter might cost 10% per 0.1m changes for example.

Example

{
    interop = length
    stepSize = 0.1
    stepPenalty = 0.1
}

For example, let us assume that the player makes and flies their very first tank in a sounding rocket with a 0.3m diameter and a 1m length. For simplicity we will ignore other physical properties in this example.

Once flown this tank would be recorded as a part named something like Tank_0.3d_1.0l (TestFlightPartData should be modified to allow storage of both a name and a title. Technically it can already do this but the other systems aren't as aware of it as they should be). This part would gain data from the flight. Let us assume the part gained 10,000du from several flights.

Now the player makes a new rocket. In order to get some more ∆v from the rocket, they lengthen the tank to 1.5m. The changes to this tank need to be taken into account. Due to changes, retooling, etc this new tank size isn't going to be as tested as the one before it. It should have less data units, and therefore less reliability.

First off, the new tank would get recorded as a different part. Any change to a procedural tank would cause it to be recorded as a new part based on its physical properties. This tank would become Tank_0.3d_1.5l

Next the current data units for the part would start at what the previous tank had, but then be modified based on the changes. The example config above indicates that changes in length should be penalized based on increments in size of 0.1m. For each 0.1m change, the new part's data would be penalized 10%. This new tank is 0.5m longer, thus would suffer a 50% penalty to data resulting in a new part with 5,000du.

This system should be bi-directional, so that data gained on one tank will be applied back (with the same penalties) to a similar previously flown tank if that tank is flown again.