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 AND
ed 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 Invert
ing 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:
- Specific aircraft section in user
Config.ini
. - Specific aircraft section in built-in configuration.
- 'Default' section in user
Config.ini
. - 'Default' section in built-in configuration.
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 totrue
ifL:VAR1
istrue
whetherL:VAR2
istrue
orfalse
or erroring (due to the short-circuitingOR
operator) - the expression
L:VAR1 AND L:VAR2
will evaluate tofalse
ifL:VAR1
isfalse
whetherL:VAR2
istrue
orfalse
or erroring (due to the short-circuitingAND
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!