diff --git a/docs/Button.md b/docs/Button.md index 081a6f32..bce04166 100644 --- a/docs/Button.md +++ b/docs/Button.md @@ -86,32 +86,36 @@ In case of a Button with multiple values, each value has a separate `initial-val The `type` attribute of a button determine [[Button Activation|how the button will behave]], what it will do when pressed, turned or slid. -# Button Representation +## Set-Dataref -(In the picture above, this refer to the pink part of the definition.) +A button definition can have a `set-dataref` attribute that points at a Dataref name. -The representation of a Button determine [[Button Representation|what and how the button will display]] on the deck device. This depends on the capabilities of the button on the deck: LED, image, coloured led button, sound... +If present, Cockpitdecks will set the value of that dataref to the value of the button. -The representation of a button is determined by *the presence of a special attribute in the definition of the button*. +Here is example of use. If a button has a activation type of `updown` with let us say 3 stops, the value of the button can be 0, 1, or 2. Each time the user presses the button the value of the button cycles between those three values. -For example, if a button definition contains an attribute named `annunciator`, the button representation will be an [[Annunciator]]. A button can only define one representation in its definition. Otherwise, a warning is reported and the button is ignored. +``` +type: updown +stops: 3 +set-dataref: toliss/NDmodeFO +``` -# Notes for Button Designers +If there is a `set-dataref` attribute, the current value of the dataref (`toliss/NDmodeFO`) in the simulator will be set to the value of the button: 0, 1, or 2. -## Button Instantiation +For some activations, the `set-dataref` attribute is a mandatory attribute. -When a button is created, internal meta data are set first. Second, the Activation is installed and initialised. Third, the Representation is installed and initialized, as it may already use some activation information for rendering. Finally, the button is initialised. It will be rendered when the page that contains it is loaded on a deck. +For some other activations that expects a command to be performed upon activation, the `set-dataref` attribute (or instruction) can be an *alternative* to the command. In other words, the commands that gets executed is very precisely the `set-dataref` instruction. -## Button Validity +# Button Representation -Each button has a validity function that ensures that all necessary attributes are provided in its definition. If the activation of the button is not valid, its activation function will never be triggered, because of missing or misconfigurated parameters. If its representation is not valid, it will not be rendered on the deck. +(In the picture above, this refer to the pink part of the definition.) -If a button is not valid, a small red triangle appears in the lower right corner of the key icon if the button is capable of representing it. A small blue triangle appears in the lower right corner of the key icon if Cockpitdecks suspect the button is a placeholder. +The representation of a Button determine [[Button Representation|what and how the button will display]] on the deck device. This depends on the capabilities of the button on the deck: LED, image, coloured led button, sound... -## Button Description and Inspection +The representation of a button is determined by *the presence of a special attribute in the definition of the button*. That attribute will determine how the button will be represented. -Each button has an `describe()` method that prints in plain English what the button does and what it renders on the deck. +For example, if a button definition contains an attribute named `annunciator`, the button representation will be an [[Annunciator]]. A button can only define one representation in its definition. Otherwise, a warning is reported and the button is ignored. -Each button has an `inspect(what: str)` method that exposes internal values and state. The inspect method takes one parameter `what` that determines what is displayed when invoked. +Attributes related to the representation of the button are indented under the attributes that names the representation. This is done on purpose to clearly separate attributes dedicated to what the button does (activation), and how it provides feedback to the user (representation). -These methods can be invoked from the [[Button Activations for Developers#Inspect|Inspect]] button activation. +A Page of 32 buttons 4 rows of 8 buttons) can quickly become quite large and difficult to read. Fortunately, recall that a Page can include other Pages to structure the creation of a layout. For example, it might be advisable to create a « main » page with global settings, and include four sub-pages, one for each row on the deck. diff --git a/docs/Button/Button Activation.md b/docs/Button/Button Activation.md index 5d306879..330634f2 100644 --- a/docs/Button/Button Activation.md +++ b/docs/Button/Button Activation.md @@ -314,11 +314,14 @@ Same as Encoder activation. # EncoderLongPush +A combination of pushing and turning. + ## Attributes -| Attribute | Definition | -| ---------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `commands` | An EncoderLongPush has 4 commands:

1. First command gets executed when encoder is turned clockwise
2. Second command gets executed when encoder is turned counterclockwise
3. Third command gets executed when encoder is turned clockwise *and pushed*
4. Fourth command gets executed when encoder is turned counterclockwise *and pushed* | +| Attribute | Definition | +| ---------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `commands` | An EncoderLongPush has 4 commands:

1. First command gets executed when encoder is turned clockwise
2. Second command gets executed when encoder is turned counterclockwise
3. Third command gets executed when encoder is first pushed, then turned clockwise
4. Fourth command gets executed when encoder is first pushed, then turned counterclockwise | +| | | ## State Values diff --git a/docs/Button/Button Attribute Default Values.md b/docs/Button/Button Attribute Default Values.md index c92d7e13..33c655df 100644 --- a/docs/Button/Button Attribute Default Values.md +++ b/docs/Button/Button Attribute Default Values.md @@ -19,7 +19,7 @@ This hierarchy is very important. As an example, let us find the value of the `label-color`. -First, the button will perform a direct lookup in its attribute. If it finds a `label-color` in its attribute, it will use it. If it does not find it, it will as its `default-label-color`. The button will then ask its parent entity for the `default-label-color`. +First, the button will perform a direct lookup in its attribute. If it finds a `label-color` in its attribute, it will use it. If it does not find it, it will ask for its `default-label-color`. The button will ask its *parent entity* for the `default-label-color`. So the Page will search for a `default-label-color` in its attributes. If it finds it, it will use it. If it does not find it, it ask its parent entity. @@ -27,15 +27,19 @@ The Deck will search for a `default-label-color` in its attributes. If it finds Finally, the Cockpit will return a `default-label-color`. If there is no value for the `default-label-color`, Cockpitdecks will issue an error. It simply means that there is no default value for that attribute and that a value *must* be supplied by the user in the definition of the button. -# Day / Night (or light / dark) Theme +# Theme -Cockpitdecks attempts to provide a day and a night *theme*. The attribute `cockpit` can be set to `day` (or `light`) or `night`(or `dark`). +Cockpitdecks introduced the concept of color schemes or *Themes*. A theme is an additional parameter (string) that is added to the attribute name being looked up. Let us see in a practical example. + +## Day or Night Theme + +Cockpitdecks attempts to provide a day and a night *theme*. The attribute `cockpit` can be set to `day` (or `light`) or `night`(or `dark`) to specify which theme to use. ```yaml cockpit-theme: dark ``` -The effect is that in `night` (or `dark`) theme, default values prefixed with `dark-` will be favored. If no default value prefixed with `dark-` is found, the regular default value is fetched. +The effect is that in `night` (or `dark`) theme, default values *prefixed* with `dark-` will be favored. If no default value prefixed with `dark-` is found, the regular default value is fetched. ## Example for label color @@ -62,11 +66,11 @@ Sometimes, configuration values can be specified at different level for a given ## Cockpitdecks (Application), Cockpits -At the highest level, a Cockpit will start with a set of default values provided in its code. +At the highest level, a Cockpit will start with a set of default values provided in its internal code. -It will then loads additional parameters in a global resource configuration file. That file is the same for ALL aircrafts. The config.yaml file is located in the home directory of Cockpitdecks software, in the *resources* folder. +It will then loads additional parameters in a global resource configuration file. That file is the same for ALL aircrafts. The config.yaml file is located in the home directory of Cockpitdecks software, in the *resources* folder. It cannot be changed. -Next, Cockpitdecks will look for an aircraft specific configuration file, in the deckconfig folder of that aircraft. It will load the config.yaml file of that aircraft, and default values loaded from there will apply to that aircraft only. +Next, Cockpitdecks will look for an aircraft specific configuration file, in the deckconfig folder of that aircraft. It will load the config.yaml file of that aircraft, and default values loaded from there will apply to that aircraft only. That configuration file can be used for cockpit designer to specify their requirements and preferences. ## Decks and Layouts diff --git a/docs/Button/Button Representations/Basic.md b/docs/Button/Button Representations/Basic.md index 567c7929..986997fa 100644 --- a/docs/Button/Button Representations/Basic.md +++ b/docs/Button/Button Representations/Basic.md @@ -14,6 +14,8 @@ An image file is loaded on the deck key if it is capable of displaying images. ## Attributes +### frame + ```yaml icon: isi frame: @@ -128,7 +130,7 @@ None The selection of the text block must be performed by a **formula** and not a dataref. -When a formula is present in the attributes of a button, it is always favored over a list of datarefs, even if the list contains only one dataref. (If there a button uses multiple datarefs and there is no formula, the value that is returned for that button is a diectionary of all dataref values.) +When a formula is present in the attributes of a button, it is always favored over a list of datarefs, even if the list contains only one dataref. (If there a button uses multiple datarefs and there is no formula, the value that is returned for that button is a dictionary of all dataref values.) # Multi-Buttons @@ -136,7 +138,7 @@ See [[Multi-Buttons and Mosaic]]. # LED -`led: led +`led: led` Turns a single LED light On or Off depending on the button's value. diff --git a/docs/Button/Button Representations/Deck Specific.md b/docs/Button/Button Representations/Deck Specific.md index 2d20a948..410d4166 100644 --- a/docs/Button/Button Representations/Deck Specific.md +++ b/docs/Button/Button Representations/Deck Specific.md @@ -1,6 +1,7 @@ # ColoredLed ColoredLed buttons are color capable led behind a transparent or mask button. + They are either on or off, with a RGB color. ``` @@ -66,7 +67,7 @@ Larger screens can be used in two different ways: - As a whole, unique, larger display surface, - As a set of adjacent buttons covering the entire surface. -In the later case, the specificity of the display is not apparent, and resulting buttons are treated as regular keys with iconic image display (with different sizes sometimes.) +In the later case, the specificity of the display is not apparent, and resulting buttons are treated as regular keys with iconic image display (with different sizes sometimes.) This is called a [[Multi-Buttons and Mosaic|Mosaic]]. When considered as a single larger display, it is difficult to remain generic since each display will have special size, location, and behavior. Cockpitdecks buttons assigned to those specific display are therefore also very specific. diff --git a/docs/Button/Button Representations/Multi-Buttons and Mosaic.md b/docs/Button/Button Representations/Multi-Buttons and Mosaic.md index c80b792f..5e232429 100644 --- a/docs/Button/Button Representations/Multi-Buttons and Mosaic.md +++ b/docs/Button/Button Representations/Multi-Buttons and Mosaic.md @@ -79,7 +79,7 @@ Here is an example of definition of a mosaic for the LoupedeckLive left screen. One Deck Type can define one or more mosaic for its large LCD displays. For example, a 800x100 pixel large LCD can propose a Mosaic of 4 x 200x100 pixels. -If a user prefers an alternate Mosaic of 8 x 100x100 pixels, it is necessary to create another Deck Type, with another name, where the alternate mosaic is expressed, but this can be done. +If a user prefers an alternate Mosaic of 8 x 100x100 pixels, it is necessary to create another Deck Type, with another name, where the alternate mosaic is expressed. The same device, whether physical or "virtual" (through a Web Deck), can be declined in several Deck Types to offer a modular representation to Cockpitdecks. @@ -99,7 +99,7 @@ The same device, whether physical or "virtual" (through a Web Deck), can be decl The activation (`type`) must be `mosaic`. This activation transforms the swipe event into push events. -The representation must be `mosaic`. THe representation collects the representation of each tile and compose the final image that is sent for display. +The representation must be `mosaic`. The representation collects the representation of each tile and compose the final image that is sent for display. ## Tiles diff --git a/docs/Button/Button Value.md b/docs/Button/Button Value.md index 0ff2ac1d..700f0fc0 100644 --- a/docs/Button/Button Value.md +++ b/docs/Button/Button Value.md @@ -1,16 +1,16 @@ A button builds its representation from its *value*. The *value* of the button is computed from one or more *dataref* values returned by X-Plane and/or from some *internal state variable* values. -A Button can have 0, 1, or more than one value in the special case of [[Annunciator|annunciators]] or LargeButtons (A LargeButton can have two or more buttons represented inside.). Each annunciator part or each button inside a LargeButton has either 0, or 1 value. +A Button can have 0, 1, or more than one value in the special case of [[Annunciator|annunciators]] or Mosaic (A Mosaic can have two or more buttons represented inside.). Each annunciator part or each button inside a Mosaic has either 0, or 1 value. Each value of a button is either None (no value) or a numeric value (which is most of the time a floating point number). If a button has several values, its value is either a list of values or a dictionary of all individual values, each individual value being None or a number. -Activations and Representations of the button knows how to manage the different values contained in the annunciator or LargeButtons. +Activations and Representations of the button knows how to manage the different values contained in the annunciator or Mosaic. # X-Plane Datarefs A *dataref* is the name of a value used by the X-Plane simulator. -The value can be a string, integer, or float value, either a single value or an array of (same type of) values. A dataref has a name to access it. Names are organized in a folder-like structure (namespace using `/` separator). Some datarefs are read-only, some other can be written and modified. +The value can be a string, integer, or float value, either a single value or an array of (same type of) values. A dataref has a name to access it. Names are organized in a folder-like structure (namespace using `/` separator). Some datarefs are read-only, some other can be written and modified. Names that start with `sim/` are reserved for the simulator internal use. #### Examples @@ -20,11 +20,11 @@ The value can be a string, integer, or float value, either a single value or an There are thousands of datarefs in a running instance of X-Plane. Datarefs drive almost everything in the simulator. -A dataref is always monitored. Its value is fetched from the simulator at regular interval (typically every second). When a dataref's value has changed, all buttons that depend on that dataref are notified to update their appearance. +When used by a button in Cockpitdecks, the value of a dataref is monitored. Its value is fetched from the simulator at regular interval (typically every second). When a dataref's value has changed, all buttons that depend on that dataref are notified of the change to, for example, update their appearance. -To explore datarefs, there is a handy X-Plane plugin called [DataRefTool](https://datareftool.com). There are also a few web pages that collect, report, and present them so that they can be searched. +To explore datarefs available in the simulator, there is a handy X-Plane plugin called [DataRefTool](https://datareftool.com). There are also a few web pages that collect, report, and present them so that they can be searched. The plugin allow not only for inspection of datarefs, but also for inspection and discovery of *commands*, strings that can be submitted to the simulator to perform some action. -For simplicity, Cockpitdecks assumes all individual dataref values are floating point numbers or strings (in which case it actually is a list of floating point values representing the ASCII code number of each character in the string.) +For simplicity, Cockpitdecks assumes all individual dataref values are floating point numbers or strings. The reason for this is that as today, X-Plane UDP only returns floating point numeric values for requested datarefs. @@ -89,7 +89,7 @@ Internal datarefs can be used as inter-button communication, to set a value in o # Button «Internal State» Attributes -When a button cannot fetch its representation from X-Plane, it is possible to use some Cockpitdecks internal variables made available through the button *state*. Each button maintain its state, a few internal variables’that can be accessed in formula. +When a button cannot fetch its representation from X-Plane, it is possible to use some Cockpitdecks internal variables made available through the button *state*. Each button maintain its state, a few internal variables that can be accessed in formula. Some state variables are generic, and available for almost every buttons, like for instance the number of time a button was activated. Other state variables are activation specific and listed in the [[Button Activation]] page under the activation being used, like for example, the number of times a encoder was turned clockwise. @@ -100,7 +100,7 @@ Numeric internal values are accessible as `${state:variable-name}` in formula. ``` ## Activation Attributes and Activation Value - + Most state attributes of a button come from the activation. Each activation has a specific set of state attributes. Among these state attributes, there is a more particular attribute, called the *activation value*, which is the most sensible value produced by the activation. ## Class Instance Attributes @@ -233,6 +233,7 @@ formula: ${state:activation_count} 2 % ## Activation Value If a button does not reference a dataref, and has no formula, the activation value can be used if it is available. + ## Multiple Button Values In case a button has multiple values, each value comes from a part of the button. Each part of the button is independent of other parts of the same button. Each part maintains its single value. diff --git a/docs/Cockpit.md b/docs/Cockpit.md index df0f5ccb..b0f6f396 100644 --- a/docs/Cockpit.md +++ b/docs/Cockpit.md @@ -44,12 +44,12 @@ The overall structure of the files and sub-folders inside the `deckconfig` folde The `deckconfig` folder contains the following files and sub-folders: -| Name | Description | -| ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| config.yaml | Main configuration file | -| secreat.yaml | Serial numbers of decks used by Cockpitdecks | -| resources | Resource files used by this configuration. Resources are icons, fonts, images, etc. | -| layout(s) | A Layout is a folder that contains what is displayed on a deck. There can be as many Layout Folder as necessary for this aircraft. All remaining folders in the `deckconfig`folder are layout folders. | +| Name | Description | +| ------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| config.yaml | Main configuration file | +| secreat.yaml | Serial numbers of decks used by Cockpitdecks | +| resources | Resource files used by this configuration. Resources are icons, fonts, images, etc. | +| layout(s) | A Layout is a folder that contains what is displayed on a deck. There can be as many Layout Folder as necessary for this aircraft. All remaining folders in the `deckconfig`folder are layout folders. There usually is one Layout folder per deck. | # `config.yaml` File @@ -84,7 +84,9 @@ The parameters apply to all decks for the given aircraft. Each individual deck w | `cockpit-texture` | Name of a image file (JPEG or PNG) that will be used as the (default) background of icons.

The `cockpit-texture` file will be searched at different places depending on where it is specified.

The `cockpit-texture` file can be specified at the Cockpit, Deck, Page, or Button level.

Cockpit-level default textures will be seached in the following folders (in that order):

- `resources`
- `resources/icons`

If the AIRCRAFT is specified, Cockpit-level textures and all other levels textures will be searched in the following folders:

- `AIRCRAFT/resource`
- `AIRCRAFT/icons`

If no texture is found, a uniform `cockpit-color` icon is used. | | `default-wallpaper-logo` | Name of image file, located in the `resource` folder, to be loaded when the deck is not used. | | `default-*` | Name of default values of several parameters, defined at the aircraft-level. These values will be used for all missing values. They can be raffined at Layout and Page level if necessary.

If no aircraft-level global parameter values are not provided, Cockpitdecks will use its own internal default values. | -| **decks** | A list of [[Deck]] structure, one per deck. Yaml allow for other attributes in the file. They are ignored by Cockpitdecks. You may include other attributes like aircraft name, ICAO code, descriptions, notes, even change log of your file. | +| **decks** | A list of [[Deck]] structure, one per deck. | + +Yaml allow for other attributes in the file. They are ignored by Cockpitdecks. You may include other attributes like aircraft name, ICAO code, descriptions, notes, even change log of your file. # `secret.yaml` File diff --git a/docs/Extending/Button Activations for Developers.md b/docs/Extending/Button Activations for Developers.md index 67a5b79e..801ccfa1 100644 --- a/docs/Extending/Button Activations for Developers.md +++ b/docs/Extending/Button Activations for Developers.md @@ -58,3 +58,23 @@ what: desc ``` When button index 4 is pressed, it will display what each button does (description) in plain English on the output or debugging screen or file. + +# Notes for Button Designers + +## Button Instantiation + +When a button is created, internal meta data are set first. Second, the Activation is installed and initialised. Third, the Representation is installed and initialized, as it may already use some activation information for rendering. Finally, the button is initialised. It will be rendered when the page that contains it is loaded on a deck. + +## Button Validity + +Each button has a validity function that ensures that all necessary attributes are provided in its definition. If the activation of the button is not valid, its activation function will never be triggered, because of missing or misconfigurated parameters. If its representation is not valid, it will not be rendered on the deck. + +If a button is not valid, a small red triangle appears in the lower right corner of the key icon if the button is capable of representing it. A small blue triangle appears in the lower right corner of the key icon if Cockpitdecks suspect the button is a placeholder. + +## Button Description and Inspection + +Each button has an `describe()` method that prints in plain English what the button does and what it renders on the deck. + +Each button has an `inspect(what: str)` method that exposes internal values and state. The inspect method takes one parameter `what` that determines what is displayed when invoked. + +These methods can be invoked from the [[Button Activations for Developers#Inspect|Inspect]] button activation. diff --git a/docs/Extending/Web Decks.md b/docs/Extending/Web Decks.md index 6f150f43..ed9513a6 100644 --- a/docs/Extending/Web Decks.md +++ b/docs/Extending/Web Decks.md @@ -3,6 +3,9 @@ In addition to real physical decks, Cockpitdecks offers *Web Decks* rendered in ![[virtualdecks.jpg]] This is very handy to design layout for deck a developer does not necessary owns. +Web decks can be (almost) any physical deck represented in Cockpitdecks (most popular brands and models are actually provided with Cockpitdecks), or any next deck model of your fantasy. As an example and proof of concept, Cockpitdecks comes with a fully operational overhead panel for Toliss A321 neo aircraft. Yes, you read it right, you can have Toliss A321 overhead panel on a touch screen or tablet. + +# Web Deck Declaration and Use Virtual decks need to be declared at two places: diff --git a/docs/Installation and Usage.md b/docs/Installation and Usage.md index 39b16f01..c510ff9e 100644 --- a/docs/Installation and Usage.md +++ b/docs/Installation and Usage.md @@ -30,7 +30,7 @@ As a practical example, X-Plane recently opened access to internal data through It is good practice to maintain the software you use to the latest, production version. Cockpitdecks is no exception to this advise. -In particular, the X-Plane Cockpitdecks Helper plugin uses and requires the latest version of [XPPython3](https://xppython3.readthedocs.io/en/latest/index.html) plugin to work. This plugin itself requires X-Plane 12 and recent version of X-Plane SDK. Again, the Cockpitdecks Helper plugin is strictly not required to run Cockpitdecks but some features will not work. +In particular, the X-Plane Cockpitdecks Helper plugin uses and requires the latest version of [XPPython3](https://xppython3.readthedocs.io/en/latest/index.html) plugin to work. This plugin itself requires X-Plane 12 and recent version of X-Plane SDK. Cockpitdecks Helper plugin is strictly not required to run Cockpitdecks but some features will not work without it. ### Enable X-Plane UDP @@ -46,23 +46,9 @@ In particular, the X-Plane Cockpitdecks Helper plugin uses and requires the late Create a new python environment and activate it. In that environment, issue the pip install command: ```sh -pip install git+https://github.com/devleaks/cockpitdecks.git +pip install 'cockpitdecks[weather,streamdeck] @ git+https://github.com/devleaks/cockpitdecks.git' ``` -### Install Additional Optional Python Packages - -If you would like to use Weather or METAR buttons, add the following packages: - -``` -pip install avwx-engine scipy suntime timezonefinder metar tabulate -``` - -> [!NOTE] All In One -> You can specify all options or additional packages like so: -> ``` -> pip install 'cockpitdecks[weather,streamdeck] @ git+https://github.com/devleaks/cockpitdecks.git' -> ``` - Valid installable extras (between the `[` `]`, comma separated, no space) are: | Extra | Content | @@ -136,7 +122,7 @@ Cockpitdecks `deckconfig` folder must be placed in the folder of the X-Plane air First, you have to completely stop (quit completely) original manufacturer deck configuration applications. They take exclusive access to the device and that prevents Cockpitdecks from finding and using them. -## Adjust `config.Yaml` +## Adjust `config.yaml` Cockpitdecks uses a single configuration file to define a few elements that cannot easily be guessed. Cockpitdecks provides a configuration file that is suitable for single computer installation. You must, however, adjust at least the X-Plane folder path. @@ -152,7 +138,7 @@ In addition, there is a operation system environment variable `COCKPITDECKS_PATH If you do not want to modify the Cockpitdecks-provided `config.yaml` file, you always can supply one on the command line with the `—-config` flag. -The set of global parameters provided in the `config.yaml` file is called the Cockpitdecks *environment*, since it provides all « external » information to Cockpitdecks. +The set of global parameters provided in the `config.yaml` file is called the Cockpitdecks *environment*, since it provides all « external » information to Cockpitdecks (external, relative to Cockpitdecks). Cockpitdecks provides two templates configuration files for local and remote use. diff --git a/docs/index.md b/docs/index.md index e8ad4eff..44a0218f 100644 --- a/docs/index.md +++ b/docs/index.md @@ -1,6 +1,6 @@ # Welcome to Cockpitdecks -Cockpitdecks is an application, a set of python scripts to use external physical decks connected to a computer with X-Plane flight simulator. +Cockpitdecks is an application, a set of python scripts created to use external physical decks connected to a computer with X-Plane flight simulator. External decks include the following make and models: @@ -8,7 +8,7 @@ External decks include the following make and models: - Loupedeck LoupedeckLive - Berhinger X-Touch Mini -There also are Web Decks, a simulator of any of the above deck in a web page! Web Decks were first developed as a tool to speed up deck page creation, but Web Decks turned out to be fast and available everywhere, in particular on tablets. Yes, you read it, you can now have any of the above deck, for free, on a tablet, to use with X-Plane flight simulator. +There also are Web Decks, a simulator of any of the above deck in a web page, in the context of this application. Web Decks were first developed as a tool to speed up deck page creation, but Web Decks turned out to be fast and available everywhere, in particular on tablets. Yes, you read it, you can now have any of the above deck, for free, on a tablet, to use with X-Plane flight simulator. Cockpitdecks can run on the same computer as X-Plane, or a remote computer, network-connected to X-Plane.