YAML Configuration Syntax

NOTE this page describes the YAML configuration file format only, and not how TestFlight configs in general. For information on the latter, please see https://github.com/jwvanderbeck/TestFlight/wiki/How-To:-Make-TestFlight-Part-Configs

TestFlight uses a pre-processor that I wrote in order to create ModuleManager configs. This process takes a YAML file with TestFlight config data in it, and compiles it into proper ModuleManager config syntax at release time.

This means that if you would like to contribute to the TestFlight configurations, then you need to create or modify the YAML configs. This document will attempt to explain how that config works and how it is laid out. If you have any questions, please post in the TestFlight thread or send me a message.

This system means that the skill level for contribution is a bit higher, but has several advantages:

• Often times the exact same config needs to applied to multiple parts. The YAML system lets you define the config once, and then apply it to multiple parts without copy and pasting
• Similarly, often the same pieces of a config are consistent and this system allows those parts to be re-used.
• Configs are built automatically using continuous integration, which means that when a contributor submits a pull request, we can know that the submitted config is at least technically correct and compiles properly.

YAML Format

YAML is a standard format for storing data in a configuration file that is both easily read and modified by a human being, as well as being easily parsed and processed by a computer program. The content of the file is of course specific to TestFlight, but the overall structure and format of the file is standard YAML and you should be familiar with the file format if you wish to contribute. If you aren't, then I recommend this overview.

Structure

At first glance the existing YAML files will seem rather complicated, but they are structured in such a way as to minimize duplication and maximize re-use of sections of configs. The file is broken into two major sections. The configs and the parts that the configs attach to. This means you can setup and fully define the config in one section, then apply it to multiple parts in the second section.

PartConfigs

This section is where the actual TestFlight configs are defined. Each PartModule is an array entry. The property names are identical to what they would be in the MM file.

    -   name: 'FlightDataRecorder_Engine'
        configuration: 'WAC-Corporal'
        flightDataMultiplier: 10
        flightDataEngineerModifier: 0.25

For properties that are FloatCurves, each key in the curve is an array entry with no key, just the value.

reliabilityCurve:
    - '0 0.024'
    - '1000 0.0144'
    - '4000 0.0072'
    - '10000 0.0048'

Parts

Once you have defined all the configs, they need to actually be applied to one or more parts before they actually do anything. In the Parts section is where you do this. The use of the word "part" here is unfortunately confusing and ambiguous compared to KSP Parts. I apologize for this. It made sense when it was just me doing these.

Basically think if a part as a real world thing. Not a KSP part. A part in KSP is essentially a 3d model with properties on it, but due to mod packs and what not you could have multiple KPS parts that all represent the same real world part. An engine, say a OMS, might be represented by multiple KSP parts, but in TestFlight it is one conceptual piece, an OMS engine, and has one configuration that is the same on all the KSP parts.

Therefore when defining the parts in this section, there is one block of keys for each real world conceptual part. part isn't used in the actual configs, but gives it a descriptive name for organizational purposes. patterns is an array, with each key defining a standard ModuleManager pattern that represents the KSP part(s) that the config should be attached to and lastly configs is an array where each key is the config (previously defined in PartConfigs) that should be applied.

-   part: 'LR-89-NA-3'
    patterns:
    - '@PART[RO-LR-89]:AFTER[RealismOverhaul]'
    - '@PART[FASAMercuryAtlasEngBooster]:AFTER[RealismOverhaul]'
    configs:
    - *LR-89-NA-3