Skip to content

Commit 14b45b2

Browse files
committed
Update docs for config maps; docusaurus version bump
1 parent 0c35fef commit 14b45b2

File tree

4 files changed

+2001
-2114
lines changed

4 files changed

+2001
-2114
lines changed

.gitignore

Lines changed: 2 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -19,4 +19,5 @@ npm-debug.log*
1919
yarn-debug.log*
2020
yarn-error.log*
2121

22-
/.idea
22+
.idea
23+
*.iml

docs/acars/configmaps.md

Lines changed: 177 additions & 151 deletions
Original file line numberDiff line numberDiff line change
@@ -5,182 +5,208 @@ title: Config Maps
55

66
Since developers often use custom offsets or datarefs, and not the defaults, having configmaps allows you to map an aircraft feature (landing lights, etc) to a "feature", which tells ACARS where to read the data for those features. They're stored in the `configmaps` directory.
77

8-
The configmaps are downloaded by the client on startup from the [configmaps repository](https://github.com/phpvms/configmaps), so updates can be more easily pushed out.
9-
10-
:::note
11-
Config maps are now only for FSX/P3D or X-Plane. A lot of developers use the default offsets or datarefs, so it may not be required to change anything
12-
:::
13-
148
If you create a configmap for an aircraft, please let me know, I can include it in ACARS to be distributed out. That would be much appreciated! **Always create a new file**, otherwise the defaults that are included with the distribution will be overwritten by an updates.
159

1610
## Anatomy of a ConfigMap
1711

18-
A config map is an XML file which looks like this:
19-
20-
```xml title="configmaps/FlightFactorA320.xml (truncated)"
21-
<?xml version="1.0" encoding="utf-8" ?>
22-
<Rules>
23-
<Rule Simulator="X-Plane" TitleContains="FlightFactor A320">
24-
<!-- ... -->
25-
<LandingLights>
26-
<Key Type="Int" Key="a320/Overhead/LightLandL" Value="1|2"/>
27-
<Key Type="Int" Key="a320/Overhead/LightLandR" Value="1|2"/>
28-
</LandingLights>
29-
<!-- ... -->
30-
</Rule>
31-
</Rules>
32-
```
12+
A config map is a Javascript file which looks like this:
13+
14+
```javascript title="aircraft/_default_xplane.js (truncated)"
15+
export default class DefaultXPlane {
16+
meta = {
17+
name: 'xplane default',
18+
enabled: true,
19+
priority: 1,
20+
sim: 'xplane',
21+
}
22+
23+
features = {
24+
beaconLights: { 'sim/cockpit2/switches/beacon_on': 'bool' },
25+
// ...
26+
}
27+
28+
match(title, icao, config_path) {
29+
return true
30+
}
31+
32+
beaconLights(value) {
33+
return value === true
34+
}
3335

34-
A rule defines:
36+
/// ...
37+
}
38+
```
3539

36-
1. Who the rule is for
37-
- The simulator it's for (either `X-Plane` or `FSX/Prepar3d`)
38-
- The aircraft title contains. This is how it's filtered. It must be broad but also specific to make sure it "catches" the right plane type.
39-
- Each word is looked for and it's AND'd. In the example above, "FlightFactor" and "A320" must be present
40+
The configuration is a class which has a few different components.
41+
42+
1. `meta`, which gives some general information about the configuration:
43+
- `name` - a name for this script
44+
- `sim` - The simulator it's for (either `xplane`, `fsuipc` or `msfs`)
45+
- `enabled`
46+
- `priority` - from 1 (lowest) to 10 (highest). If there are multiple rules which match this,
47+
then which one takes priority. All the built-in rules are at a priority 1
48+
2. `features`
49+
- MSFS - the lookups you enter are LVars
50+
- X-Plane - the looks ups are via datarefs
51+
- FSUIPC - the lookups are offsets
52+
3. `match()`
53+
- A method (`match()`) which passes some information about the starting aircraft
54+
- For MSFS, it's the aircraft ICAO
4055
- For FSX/P3d, the value looked at is the aircraft title field, offset `0x3D00`
4156
- For X-Plane, the value looked at is `sim/aircraft/view/acf_descrip`
42-
1. The feature (see below)
57+
- This method can be used to determine if this rule should match
58+
4. Methods for the different features (see below)
4359
- The maps - a group of datarefs or offsets which constitute that feature being "on" or "enabled"
4460

4561
In the above example, for the FlightFactor A320, the landing lights are controlled by two datarefs, both of which the values need to be 1 or 2 for the landing lights to be considered "on".
4662

4763
## Features
4864

49-
The base rules and rule types are available. This list may be expanded in the future.
50-
51-
- BeaconLights
52-
- LandingLights
53-
- NavigationLights
54-
- StrobeLights
55-
- TaxiLight
56-
- WingLight
57-
58-
### Mapping data to a feature
59-
60-
Each `Key` consists a `Type`, `Key` and a `Value`. These are all "AND" together, so every value in the feature must evaluate to true.
61-
62-
```xml title=Example Rule
63-
<Key Type="Int" Key="a320/Overhead/LightLandL" Value="1|2"/>
65+
Features are stored in a dictionary of dictionaries:
66+
67+
```javascript
68+
features = {
69+
beaconLights: {
70+
'sim/cockpit2/switches/beacon_on': 'bool'
71+
},
72+
landingLights: {
73+
'sim/cockpit2/switches/landing_lights_on': 'bool'
74+
},
75+
logoLights: {
76+
'sim/cockpit2/switches/logo_lights_on': 'bool'
77+
},
78+
navigationLights: {
79+
'sim/cockpit2/switches/navigation_lights_on': 'bool'
80+
},
81+
strobeLights: {
82+
'sim/cockpit2/switches/strobe_lights_on': 'bool'
83+
},
84+
taxiLights: {
85+
'sim/cockpit2/switches/taxi_light_on': 'bool'
86+
},
87+
wingLights: {
88+
'sim/cockpit2/switches/wing_lights_on': 'bool'
89+
},
90+
flaps: {
91+
0: 'UP',
92+
1: '0',
93+
2: 'DIAL TO',
94+
3: '11',
95+
4: '15',
96+
5: '28',
97+
6: '40',
98+
},
99+
}
64100
```
65101

66-
1. `Type`, which can be:
67-
- `Bool` - a `Value` is not required, the sim returns a `1` or `0` for this value
68-
- `Byte`
69-
- `Number`/`Double`/`Float`
70-
- `Int`
71-
- `Short`
72-
- `Mask` - Find a value in a bit mask
73-
- `String` - look for exactly matches
74-
- `IntArray`/`FloatArray` - (X-Plane) - where the DataRef returns an array of integers or floats
75-
- `LVar` - Look for an LVar value (**Microsoft Flight Simulator only**)
76-
2. `Key` - This is where ACARS will look to get the value.
77-
- `FS9/FSX/Prepar3d` - This is an FSUIPC offset. LVars aren't supported, though you can use LINDA and FSUIPC to map an LVAR to a custom offset, and read it here. This information is up to the aircraft developer to provide.
78-
- **NOTE** You can use "FSUIPC" and it will detect it for the Prepar3d/FS9/FSX family
79-
- `X-Plane`/`xplane` - This is the dataref value
80-
- `Microsoft Flight`/`MSFS` - The name of the LVar to use
81-
3. Value specifier, must be one of:
82-
- `Value` - this is what value to look for, in the case of a non-boolean type. You can use the OR operator (`|`) to separate multiple values
83-
- `ValueGt`/`ValueGte` - Value greater than or greater than equal to, respectively
84-
- `ValueLt`/`ValueLte` - Value less than or less than or equal to, respectively
85-
- `ValueBtwn` - Value between; this must include two values like `0|1`, and will include the first value up to the first
86-
4. `Index` (required for `IntArray` and `FloatArray`)
87-
- If using the above types, which index of the array to look for the value in (starts from 0)
88-
89-
:::note
90-
A note for X-Plane: the `sim/cockpit/electrical` datarefs are usually not great to use - X-Plane emulates the electrical system, so the values may toggle between 0 and 1, for example, when the strobe light is blinking, the electrical will toggle between 0 and 1. These would show up as the strobe being on. You generally want to check any switches (see Debugging below)
91-
:::
92-
93-
### Ignoring Features
94-
95-
To ignore a feature in the rules (for example, if a feature doesn't work properly), add `Ignore="True"` to the feature:
96-
97-
```xml
98-
<LandingLights Ignore="True">
102+
The different features available are:
103+
104+
- beaconLights
105+
- landingLights
106+
- logoLights
107+
- navigationLights
108+
- strobeLights
109+
- taxiLights
110+
- wingLights
111+
- flaps
112+
113+
The different features contain how to look up the value, and the type. You can have multiple variables to be
114+
read and looked at for a feature. Each feature then corresponds to a method which is called to return if
115+
that feature is on or off. That method will have the equivalent number of arguments for each data reference
116+
117+
Example:
118+
119+
```javascript
120+
export default class Example {
121+
features = {
122+
beaconLights: {
123+
'sample/dataref/1': 'bool',
124+
'sample/dataref/2': 'bool',
125+
}
126+
}
127+
128+
beaconLights(dataref_1, dataref_2) {
129+
if (dataref_1 && dataref_2) {
130+
return true;
131+
}
132+
133+
return false;
134+
}
135+
}
99136
```
100137

101-
This will then ignore any landing light rules for that specific aircraft. You can also ignore a specific value, like if a switch has a 3 positions - 0 for off, 1 for on, and 3 for auto, you can ignore a rule with the value of 3:
138+
### Ignoring Features
102139

103-
```xml
104-
<LandingLights IgnoreIf="3">
105-
<Key Type="Int" Key="a320/Overhead/LightLandL" Value="1|2"/>
106-
<Key Type="Int" Key="a320/Overhead/LightLandR" Value="1|2"/>
107-
</LandingLights>
140+
To ignore a feature in the rules (for example, if a feature doesn't work properly), set the feature to false:
141+
142+
```javascript
143+
export default class Example {
144+
features = {
145+
beaconLights: {
146+
'sample/dataref/1': 'bool',
147+
'sample/dataref/2': 'bool',
148+
},
149+
landingLights: false
150+
}
151+
}
108152
```
109-
In this case, all of the `Key` values must match `3` in order for it to be ignored in any landing lights rules. In this next example, it's reading from an array of integers that's returned by the sim, looking at the 2nd index, and ignoring the value if it's a 3:
110153

111-
```xml
112-
<StrobeLights IgnoreIf="3">
113-
<Key Type="IntArray" Index="1" Key="some/integer/array" Value="1|2"/>
114-
</LandingLights>
154+
### Mixed priorities
155+
156+
If there are two scripts which match a particular aircraft, and a feature is omitted, it will use the lower priority
157+
one in place. For example:
158+
159+
```javascript
160+
export default class Example {
161+
meta = {
162+
// ...
163+
priority: 1
164+
}
165+
166+
features = {
167+
beaconLights: {
168+
'sample/dataref/1': 'bool',
169+
'sample/dataref/2': 'bool',
170+
},
171+
landingLights: {
172+
'sample/landing/light/1': 'bool',
173+
'sample/landing/light/2': 'bool',
174+
},
175+
}
176+
}
177+
178+
export default class ExampleOverride {
179+
meta = {
180+
// ...
181+
priority: 10
182+
}
183+
184+
features = {
185+
landingLights: {
186+
'override/landing/light/1': 'bool',
187+
'override/landing/light/2': 'bool',
188+
},
189+
}
190+
}
115191
```
116192

117-
### Flaps
193+
In this case, the lookups used for the rules will be:
118194

119-
You can also add the flaps naming to specific aircraft which might have different values. The flaps have an numeric index value that's reported and then a corresponding flap name:
120-
121-
```xml
122-
<Rule Simulator="X-Plane" TitleContains="Some Aircraft Name">
123-
<Flaps>
124-
<Flap Index="0" Text="Up" />
125-
<Flap Index="1" Text="CONF 1+1" />
126-
<Flap Index="2" Text="CONF 2" />
127-
<Flap Index="3" Text="CONF 3" />
128-
<Flap Index="4" Text="CONF FULL" />
129-
</Flaps>
130-
</Rule>
131-
```
132-
133-
Then these flaps settings will be used over the generic aircraft ICAO flaps namings. You can also ignore a flap state if it's a "no-op" state:
134-
135-
```xml
136-
<Rule Simulator="X-Plane" TitleContains="Some Aircraft Name">
137-
<Flaps>
138-
<Flap Index="0" Text="Up" />
139-
<Flap Index="1" Text="" Ignore="True" />
140-
<Flap Index="2" Text="CONF 2" />
141-
<Flap Index="3" Text="CONF 3" />
142-
<Flap Index="4" Text="CONF FULL" />
143-
</Flaps>
144-
</Rule>
145-
```
195+
- beaconLights - `sample/dataref/1|2`
196+
- landingLights - `override/landing/light/1|2`
146197

147-
### Examples
148-
149-
In this example, both of the datarefs, in this last, the left and right landing lights, must have a value of `1` or `2` in order for the landing lights to be considered "on". This aircraft config also has differing flap names.
150-
151-
```xml
152-
<Rule Simulator="X-Plane" TitleContains="Some Aircraft Name">
153-
<LandingLights>
154-
<Key Type="Int" Key="a320/Overhead/LightLandL" Value="1|2"/>
155-
<Key Type="Int" Key="a320/Overhead/LightLandR" Value="1|2"/>
156-
</LandingLights>
157-
<Flaps>
158-
<Flap Index="0" Text="Up" />
159-
<Flap Index="1" Text="CONF 1+1" />
160-
<Flap Index="2" Text="CONF 2" />
161-
<Flap Index="3" Text="CONF 3" />
162-
<Flap Index="4" Text="CONF FULL" />
163-
</Flaps>
164-
</Rule>
165-
```
166198

167-
In this example for FSUIPC, the offsets use a bitmask to consider the beacon lights being on:
199+
### Flaps
168200

169-
```xml
170-
<Rule Simulator="Prepar3d" TitleContains="Some Aircraft Name">
171-
<BeaconLights>
172-
<Key Type="Mask" Key="0x0D0C" Value="2"/>
173-
</BeaconLights>
174-
</Rule>
201+
You can also add the flaps naming to specific aircraft which might have different value. The `flaps()` method is
202+
passed an index.
203+
204+
```javascript
205+
export default class Example {
206+
flaps(index) {
207+
if (index == 0) {
208+
return "UP"
209+
}
210+
}
211+
}
175212
```
176-
177-
For the remaining features, the X-Plane defaults will be used.
178-
179-
## Creating a config map
180-
181-
To create a config map, you can copy one of the existing files and modify it.
182-
183-
- The file must be in the `configmaps/` directory
184-
- Name the file as specific as possible
185-
- Don't edit existing ones, they'll get overwritten
186-

0 commit comments

Comments
 (0)