Advanced configuration - RoystonS/BetterBravoLights GitHub Wiki

The vast majority of people using Better Bravo Lights (BBL) will not need the information in this page. It simply serves as an addendum to the basic Configuration page, providing details of more advanced features and behaviour. It'll make little sense if you haven't read the basic page first.

Advanced configuration

This section of the documentation describes more rarely-used settings and goes into more technical detail about some pieces of behaviour:

As well as setting the configuration for lights (see the list of Light Names above), some other configuration settings can be made:

MasterEnable

This feature is new in BBL v0.7.0 and makes it easy to turn off all Bravo lights until a particular state has been reached - such as the master electrical bus or battery switch being on - by specifying a condition which should be added to all lights.

For example, if we want all of lights to turn on only once the main flight controls panel is on, we could write this rather repetitive configuration:

[Aircraft.Something]
MasterWarning = A:CIRCUIT GENERAL PANEL ON, bool == 1 AND L:Generic_Master_Warning_Active == 1
ParkingBrake = A:CIRCUIT GENERAL PANEL ON, bool == 1 AND A:BRAKE PARKING POSITION, bool == 1
Door = A:CIRCUIT GENERAL PANEL ON, bool == 1 AND (A:CANOPY OPEN, percent > 0 OR A:EXIT OPEN:0, percent > 0)

Using MasterEnable this becomes the much simpler and clearer:

[Aircraft.Something]
MasterEnable = A:CIRCUIT GENERAL PANEL ON, bool == 1

MasterWarning = L:Generic_Master_Warning_Active == 1
ParkingBrake = A:BRAKE PARKING POSITION, bool == 1
Door = A:CANOPY OPEN, percent > 0 OR A:EXIT OPEN:0, percent > 0

MasterEnable works by automatically adding its expression (using an AND) into every other light expression. When viewing light configurations in the debugger, expressions will show that ANDed MasterEnable configuration explicitly in the expressions it displays.

Invert

This setting takes a comma-separated list of light names and arranges for their logic to be inverted.

For example, if you wanted to operate your Bravo throttle in a dark room, and light each auto-pilot button UNLESS it was activated, you would write:

Invert = HDG, NAV, APR, REV, ALT, VS, IAS, AUTOPILOT

It is possible to apply this setting for individual aircraft, but it makes most sense in the [Default] section.

Note that when viewing inverted lights in the debugger, their expressions will be shown with an extra NOT prefix for the expression: this is how the inverting logic works.

The interaction between MasterEnable and Invert is such that Inverting behaviour only takes effect after the MasterEnable condition has been passed. That is, for a configuration of:

MasterEnable = EXPRESSION1
Invert = HDG

HDG = EXPRESSION2

the final expression used for the HDG light will be EXPRESSION1 AND (NOT (EXPRESSION2))

Overriding

In general, expressions later on in a config file override expressions earlier on in that file.

So, the effect of writing:

[Aircraft.Aircraft1, Aircraft.Aircraft2]
Light1 = A:SOME VARIABLE, bool == 1
Light2 = A:OTHER VARIABLE, bool == 1

[Aircraft.Aircraft1]
Light1 = L:ANOTHER VARIABLE == 1

would be the same as writing:

[Aircraft.Aircraft1]
Light1 = L:ANOTHER VARIABLE == 1
Light2 = A:OTHER VARIABLE, bool == 1

[Aircraft.Aircraft2]
Light2 = A:OTHER VARIABLE, bool == 1

Expressions in the user's Config.ini file also override those in the built-in configuration file.

BBL will follow this order when trying to find the configuration for a light, and will stop at the first configuration it finds:

  1. Specific aircraft section in user Config.ini.
  2. Specific aircraft section in built-in configuration.
  3. 'Default' section in user Config.ini.
  4. 'Default' section in built-in configuration.
  5. OFF

Having located the configuration for a light, BBL will then search for an optional Invert value in the same way, and then an optional MasterEnable value in the same way, and merge all that together into a single expression.

Error handling

If expression mentions an A: variable or L: variable that does not (yet) exist, that part of the expression will be considered to be 'in error', as will anything that depends on it. (It can't simply treat the value as 0 as that would be misleading.)

For example, if L:VAR1 exists but L:VAR2 does not:

  • the expression L:VAR1 + L:VAR2 will itself be considered an error
  • the expression L:VAR1 OR L:VAR2 will evaluate to true if L:VAR1 is true whether L:VAR2 is true or false or erroring (due to the short-circuiting OR operator)
  • the expression L:VAR1 AND L:VAR2 will evaluate to false if L:VAR1 is false whether L:VAR2 is true or false or erroring (due to the short-circuiting AND operator)

In summary:

  • any arithmetic expression (e.g. L:VAR1 + 4) involving an error will evaluate to an error
  • any comparison expression (e.g. L:VAR1 == 9) involving an error will evaluate to an error
  • any logical operator (e.g. L:VAR1 == 9 OR L:VAR2 > 42) involving an error will evaluate to an error unless the other side of the operator is able to determine the result by itself

If the overall expression for a light evaluates to an error, the light will be turned OFF.

The short-circuiting OR operator is particularly useful for generating configurations which are resilient to missing variables. For instance the configuration Vacuum = L:VAR1 == 1 OR L:VAR2 == 1 OR L:VAR3 == 1 will light up the VACUUM light if any of L:VAR1, L:VAR2, L:VAR3 exist and have the value 1.

Can I make the gear lights amber coloured?

Technically, yes, but please read the information in this page first!