# Checklist Examples This section presents a couple of examples of how to correctly format Checklist and Checklist Library [`*.xml`](../../../../devmode/editors/project-editor/file-formats/xml-files/) files. You can find more information about the different XML elements used in these examples from the following page: - [Checklist.xml Properties](checklist-xml-properties/) ### Simple Checklist The example below shows a minimal checklist with a single checkpoint: ``` xml ``` The above checkpoint will: - enable highlighting of an instrument using a visual helper. - validate it in **Automatic** mode as soon as the user meets the requirement. In this case the SimVar "`BRAKE PARKING POSITION`" must be TRUE (1) for the requirements to be fulfilled. - automatically be executed in Copilot mode - and *only* in this mode - if the `testValue` is FALSE (0), i.e: if the parking brake is not set. This action will only be performed once. The action sends the event of `EventID` "PARKING\_BRAKES", which will activate the parking brake of the aircraft. This checkpoint will still wait until the `testValue` is TRUE (1) before being automatically validated, i.e: setting an unrelated action will cause the Copilot mode to wait until the user resolves the issue by themselves. ### Checkpoint Libraries A checkpoint library is a file that contain one or more checkpoints that can be shared across various aircraft. Below is a minimal example of a library file containing two checkpoints - `Parking_Brake_Set` and `Brakes_Released` - that we'll then reference in the actual checklist file: ``` xml ``` This library file can then be accessed in the checklist file using the `` element, and the checkpoint **ID** (defined using the `` element in the library file) is used to select the required checkpoints - `Parking_Brake_Set` and `Brakes_Released` - from it: ``` xml ``` ### Automatic Action (Copilot) Example In this example, the two **WaitUntilTestValueValidated** `` elements are what is most important. Without them, in Copilot mode, both Tests would be automatically skipped because they would have no Copilot Action, and they would have a `TestValue` "True" for the Sequence. This in turn means the sequence action with `Condition="TestValueFalse"` attribute would not trigger: ``` xml ``` ### Advanced Checkpoint Example Here we have a more complex example of two checkpoints that share *variables* (created in the `` element using the **StoreVar** attribute) and these variables are also being used to ensure that only one of two sequences will actually be executed. A more thorough explanation of the example is given at the end: ``` xml True True True True True ``` So, how does this last example work? The user is supposed to set the magneto to "Both", then wait some time for the {{< glossterm >}}rpm{{< /glossterm >}} to stabilize, then measure the current RPM. He then does the same for "Left" and "Right", in any order. The RPM for "Left" or "Right" should be no less than 150 RPM below the RPM for "Both". The RPM for "Left" and "Right" should not be further apart than 50 RPM. Here, the first checkpoint starts by initializing variables to 0, to avoid possible side-effects. Then, the first test measures the RPM for the "Both" setting. The following *un-ordered* sequence is composed of two *ordered* sequences, each set up so that only one actually needs to be properly executed, one for "Left" and the other for "Right". The sequence waits 1.5 seconds in the correct settings, and measures the RPM. The difference of RPM between "Both" and "Left/Right" is computed, and if small enough, the corresponding RPM is stored in the appropriate variable. The other "Right/Left" variable will keep a value of 0. In the second checkpoint, only one of the first two ordered sub-sequences is actually executed, and the other is skipped, based on which variable among "Left" and "Right" is set, and which still contains 0. The correct sequence will set the corresponding "Left/Right" settings, and measure the RPM. Finally, the last test verifies that the two "Left" and "Right" variables are close enough. ### Modular Aircraft Checklist Examples This example - based on the XCub aircraft - is an illustration of how checklists can be created to take advantage of the [Modular SimObject](../../modular-simobjects/) architecture. The structure of the XCub package is as follows: - In the *common* checklist folder there is the library file with all the checkpoints for all the variants, along with a a checklist file with pages, blocks, and calls to checkpoints that are common to all variants. - In the relevant *attachment* folders you can find a checklist folder that contains pages, blocks, and calls to checkpoints that are specific to each attachment and these files also contain *merging operations*. - In each of the *preset* folders, there is a checklist folder with a checklist XML file containing automerge options. If necessary, there could also be calls to checkpoints that are specific to the preset and as well as *merging operations* (but that's not required in this example). {{< callout context="caution" title="IMPORTANT!" icon="outline/alert-triangle" >}} All checklist files (in the common, attachments, and presets folders) **must have an identical name to be merged correctly**. {{< /callout >}} #### Syntax Let's look at a single page found in the checklist XML in the *common* folder. This is the page "Empennage" included in the step PREFLIGHT\_GATE: ``` xml ``` We need to include a checkpoint related to the **ventral fin** which is only present with the floats attachments. For this we need to add a new checkpoint into the relevant attachment checklist files. In these files we need to create Steps and Pages (and - if relevant - Blocks) with the same `SubjectTT` as shown above so that the new checkpoint will be added into the correct page (and Block) of the final checklist. For example: ``` xml ``` This will add the new checkpoint to the Empennage page, however it will add it to the *bottom* of the page, as the last element. To move it where it should be - in this example it should be before the checkpoint “TIE\_DOWN\_REMOVE” - we use the `` element within the page: ``` xml ``` The actual XML will now look something like this: ``` xml ``` This same process can be performed for blocks and pages, as illustrated by the following examples: ``` xml ``` It is possible to add several elements inside a `` element, thus moving several elements at once. The elements being moved will maintain the order that they have been defined in within the move element and will all be moved as a stack before the specified target element. {{< callout context="note" title="NOTE" icon="outline/bulb" >}} It is possible to move elements **without** adding them if they are available in the common checklist. For example, if the checkpoints are identical between two presets, but their listed **order** is different, you can use <MoveEntry> to rearrange the order. {{< /callout >}} With the same logic as adding new elements, it is also possible to *remove* elements coming from the *common* checklist which are not relevant for the current *preset*. Let's look again at an example from the XCub, where we want to remove the checkpoint `XCUB_TAILWHEEL_AND_SPRINGS_CHECK_CONDITION`, which is irrelevant for the amphibious version. For this we'll use the `` element: ``` xml ``` You can use both the *move* and *remove* elements together to create dynamic checklists, for example: ``` xml ``` Finally, to ensure that the merging operations are performed as expected, each checklist file used in a preset has to have the [`AutoMerge` (Attribute)](../../modular-simobject-xml-properties/#AutoMerge) set to "False" in the `` element, for example: ``` xml ``` If `AutoMerge` is *not* set to "False", any new elements defined in the *attachments* and *preset* checklists will be **added** to the *common* checklist, and the moving / removing operations will not be performed. #### Using Indices In some cases, an additional identification parameter for an element you want to move or remove will be required. For example, if one or more elements are located in the same location *and* have the same base identifier (ie: the "ReferenceId" for checkpoints, or "SubjectTT" for blocks and pages), but you want to move or remove only *one* of them, you will need to supply an `index` value. In the example below, we add into the same page two new blocks that have the same `SubjectTT`. We then want to move them to their proper respective location. To differentiate between the two blocks, we give them two different `index` parameters, so we can now use two separate `` to relocate them independently: NOTE: This also works with ``. ``` xml ```