CHECKLIST BEST PRACTICES

This section aims at outlining the minimum requirements for your aircraft checklists to be in compliance with general standard used by the aircraft that are part of Microsoft Flight Simulator 2024 by default. The checklist system is a powerful tool with many features to use, and as such the minimum quality level attempts to use as much of these features as possible - Of course, if enough developing time is dedicated to implementing the checklist, it will be possible to go beyond the requirements described below.

 

The supported features can be divided into the following three categories: text, evaluation, and visual helpers. Additionally, you have an extra set of categories for those of you that wish to use a custom EFB application for the checklist (since the default EFB Aircraft Application does not support these features): automated evaluations and automated actions. We'll cover each of these in turn and explain what is expected from you when creating your checklists using these features.

 

The following chart should help you to understand better how checklists should be developed:

 

Research Procedures

Before implementing the checklist in the simulation, you should take time to do some research about the aircraft and how to operate it. Gathering documents is an essential step of design work and the checklist creation is no exception. Usually the Pilot Operating Handbook (POH) will contain a lot of information about the aircraft, and one or more specific sections dedicated to procedures - it is in these sections that the checklists can be found. The checklists in the POH are usually designated by "NORMAL PROCEDURES" and "EMERGENCY PROCEDURES", with the former roughly being the checklist used when the aircraft is working as expected and the latter being the one used when one or several systems have failed.

 

Note too, that there may be other sources of information available to you for the aircraft that may highlight things that are typically expected in the pre-flight procedures but not specifically documented in the POH. Things like articles, photos and videos can be found that may contain this additional information and context.

 

One way we recommend for extracting the real aircraft procedures from the POH and simplifying them into a working checklist schematic is to register every checklist step of the real aircraft into a spreadsheet. In the spreadsheet, the whole procedure can be divided into different flight phases - which will become checklist pages in the simulation - and given a logical order. It's at this point that you can also decide the level of detail that will trigger whether any specific checkpoint should be displayed or not.

 

 

Prepare Base XML

This step is where you would create the base XML files that you need, and link to any existing checklist libraries. In general, we recommend that you have at least two XML files for the base files:

• The first is a specific library that will include checkpoints implemented in terms of texts and highlights. This would be called simply <Aircraft>CheckpointLibrary.xml or something similar.
• The second is the checklist file itself. It defines the structure of the checklist and its different level - steps > pages > blocks > checkpoints - and it will call checkpoints from the above mentioned library and from the DefaultCheckpointsLibrary.xml (which is a file that is provided in the simulation for all aircraft to use, as explained here: Default Checkpoint Library). This file is usually called something like <Aircraft>Checklist.xml. Beside the overall structure of the checklist, the only implementation we suggest to configure directly in this checklist file is that of the cameras. As a matter of fact, a checkpoint can be used in different pages and, depending on the page, cameras can be recommended or not. For instance, usually cameras are mostly detrimental to the experience during a dynamic phase of flight. That is why we recommend the implementation of cameras directly in the checkpoints inside the checklist pages, only where they are relevant.

NOTE: although the call to checkpoints for the DefaultCheckpointsLibrary.xml is still possible, we almost do not use it any longer in our production pipe.

 

These files must go in a folder named Checklist within the aircraft source files, however where exactly this folder goes will depend on the setup of the aircraft. For example, in a non-modular legacy aircraft setup:

 

Or in a Microsoft Flight Simulator 2024 modular aircraft:

 

 

Implement Checkpoints

The normal process for this is to add the checkpoint into the aircraft library file as far as texts are concerned (subject, expectation, clue) and then call it in the checklist. The Creating A Checklist page goes into this in more detail.

 

Implement visual helpers

This is part of the iteration cycle, and is where you would add in the required highlights and set up any required cameras. The recommended process for this is to add the highlights in the checkpoint inside the aircraft library file to have highlights in every call to the checkpoint wherever it is in the checklist structure. However, it is recommended to have the camera set in the checkpoint in the checklist file directly as, from one call to the checkpoint to the other, it is not always relevant to have a camera. The Creating A Checklist page goes into this in more detail.

 

Implement Extras

This is an optional part of the iteration cycle, and is where you would add automated evaluations and automated actions to relevant checkpoints (which is not supported by the native EFB aircraft application and will require a custom checklist app to be visible). The Creating A Checklist page goes into this in more detail.

 

Test

This is the final part of the iteration cycle, and is where you simply build the aircraft in the simulation and test that the checklist actually functions as designed and responds to user input correctly. Once you have finished testing and everything is correct, you would then go back to the start of the iteration cycle and add in further checkpoints to your checklist.

 

 

Requirements for text

The following lists the recommended requirements for all text that is to be used within the checklist:

 

• Checkpoints must have a subject and an expectation. A clue is not mandatory and must only be present if it helps the user in completing the checkpoints by giving more information or context than the subject-expectation pair alone.

  

• Text should be localized to work correctly with the different languages supported by the simulator. See the section on Localization for more information.

 

• Each checkpoint must have a level of detail associated with it. Here are the general guidelines that were used to create the aircraft available by default in the simulation:

  • Standard: all checkpoints that are absolutely necessary to have an aircraft in the proper flight configuration for a given phase are shown to the user. An additional criteria is that a standard checkpoint must relate to an action that has a consequence on the system (so, no dummy interactions only included for immersion) or to check of a parameter that is really simulated in-world.

  • Advanced: includes additional checkpoints that are not absolutely necessary to have the aircraft in the proper flight configuration, such as setting some auxiliary systems, entering a flight plan in the avionics of GA aircraft, etc... You can also include checkpoints related to actions that have no influence on the simulation but are still interactive (dummy interactions for immersion).

  • Expert: includes extra checkpoints that relates more to role-play actions purely for immersive purposes. For example, making signs to an outside crew member, making an announcement to passengers, etc... You can also include checkpoints related to elements that do not appear in your model, systems or avionics, but that would be in a "real world" checklist.

 

 

Requirements for visual helpers

The following lists the recommended requirements for the creation and implementation of visual helpers in the checklist:

 

• All checkpoints must make use of highlights and cameras (except for the situation outlined here).

 

• All controls, gauges, or screens that need to be operated (or monitored) for a checkpoint to be validated need to be highlighted to guide the user.

 

• The minimal expected highlights per object type are as follows:
  • For gauges, a highlight is expected on the gauge frame.
  • For switches/buttons, a highlight is expected on the switches/buttons.
  • For stick/yoke, a highlight is expected on the whole stick.
  • For rudder pedals :
    • a highlight is expected on the whole set of pedals if the checkpoint asks to use the rudder.
    • a highlight is expected on the brake part if the checkpoint asks to use the brakes and if brakes have a dedicated part.
  • For screens :
    • if the checkpoint requires monitoring a precise element of the screen, a highlight is expected around this element.
    • if the checkpoint requires monitoring the whole screen (e.g. "Engine gauges: Check"), the frame of the screen can be highlighted.
  • Highlights can be made conditional

 

• The camera must move to focus on the cockpit part where actions are required:
  • If the checkpoint requires actions on different part of the cockpit, the camera movement should be directed to the most useful part of the cockpit for this checkpoint.
  • Camera movement can be set aside for checklist pages dealing with a flight phase (e.g. Take Off, Landing, Cruise, etc). The rationale is to avoid changing the user's view, while they are in a dynamic piloting phase, and risking that they lose orientation and control. A highlight is then considered sufficient to guide them.

 

 

Suggestions for Evaluation

The following lists the suggested requirements for all checkpoint evaluations that are to be done within the checklist for those of you that wish to go the extra mile and use a custom EFB application (since this is not supported by the native EFB Aircraft Application):

 

• Checkpoints should be "auto-evaluated" as much as possible. Auto evaluation means that when the checkpoint is being evaluated, the player only has to perform the required action to validate the checkpoint. On the contrary, manual validation means that to complete the checkpoint the player has to manually click the "Tick Item" button to validate the checkpoint.

 

• In some cases, auto-evaluation is not applicable (e.g. when the expectation of the checkpoint is "as desired" or "as required"). In these cases, manual validation is acceptable.NOTE: Checkpoints that do not include a test automatically expect manual validation.

 

• Evaluation tests must be able to validate when conditions are met, even when the conditions are met in an unexpected way. Basically, a checkpoint cannot be "failed". For example, let's consider the following checkpoint: "Touchdown: Three-point":
  • This checkpoint expects a three-point touchdown meaning, all three wheels (in a conventional landing gear design) must touch the ground at the same time.
  • However, checking that all the wheels touched the ground at the same time could be problematic if the player does not manage a three point landing. Indeed this would lead to the checklist being blocked with the checkpoint not validating.
  • Therefore such a test should be implemented by just checking that all wheels are on ground. This will allow for the checkpoint to validate even in the case of a failed three-point touchdown.

 

 

Suggestions for Auto complete

The following lists the suggestions requirements for all checkpoint to auto-complete, for those of you that wish to go the extra mile and use a custom EFB application (since this is not supported by the native EFB Aircraft Application):

 

• Checkpoints must have auto-complete capability. The auto-complete feature - also called the copilot action - allows the player to "wait" for the copilot to complete the checkpoint by performing the required action(s).

 

• For some checkpoints, auto-complete will not be applicable:
  • if the checkpoint is manually validated as presented above then no auto-complete is necessary as the "Auto-complete item" button will be replaced by a "Tick item" button.
  • if the checkpoint is auto-evaluated but completion does not require actions in the cockpit or cannot be done using these (e.g. some speed checks, temperature checks) then the action to implement should be "WaitUntilTestValueValidated".

 

• Copilot actions must be reliable as their inability to validate would lead the player to being blocked in the checklist process and having to force validate the checkpoint or reset the page.