MASFlightComputer - MOARdV/AvionicsSystems GitHub Wiki

The MASFlightComputer is the core of Avionics Systems. All MAS-enabled props use the MASFlightComputer to process data, and it provides IVA creators a number of configuration options. IVA authors are required to include MASFlightComputer in the part config for the IVA's they create. Typically, this is done by using a ModuleManager node (see the examples in MOARdV/FlightSystems). User-configurable fields are provided below, along with their defaults. Optional override fields are listed as well.

MODULE
{
  name = MASFlightComputer

  gLimit = (a ridiculously large number)
  baseDisruptionChance = 0.0
  requiresPower = false
  rate = 0.0
  powerOnVariable = ""
  startupScript = ""

  maxRot = 80.0
  minPitch = -80.0
  maxPitch = 45.0

  PERSISTENT_VARIABLES
  {
    MAS_IMP_Mode_Select = 1
  }

  RPM_COLOROVERRIDE
  {
    COLORDEFINITION
    {
      // 'white' label unlit color
      name = ASET_SWITCHER_NAME_ZEROCOLOR
      color =  213, 213, 213, 255
    }
  }

  MAS_ACTION_GROUP
  {
    name = EVA Floodlight
    id = 10

    ACTION
    {
      name = Light
      part = bluedog_Apollo_Block2_DockingLight
      module = ModuleLight
      action = toggle
    }
    // Additional ACTION if needed
  }
  // Additional MAS_ACTION_GROUP if needed
}
  • gLimit - The maximum number of gees that MASFlightComputer can sustain before there is a risk of power disruption. See below for more information on this feature.
  • baseDisruptionChance - A number between 0 (never) and 1 (always) that controls the likelihood each FixedUpdate of g forces in excess of the gLimit causing a power disruption. See below for more information on this feature.
  • requiresPower - Indicates whether the craft running out of ElectricCharge (or whatever the power resource is in the MAS config file) can disrupt instruments. Setting this to true can cause instrumentation to black out if batteries are depleted.
  • rate - Indicates the minimum power draw in EC/s that the MASFlightComputer will require every second. Ignored if requiresPower is false.
  • powerOnVariable - An optional variable that is evaluated to control power disruption. See below for more information on this feature.
  • startupScript - An optional function that is run once when the MASFlightComputer initializes. This function is executed prior to loading and configuring props.
  • maxRot - An optional variable that controls how far the IVA camera may pan (to either direction), in degrees.
  • minPitch - An optional variable that controls how far up the IVA camera may pitch, in degrees.
  • maxPitch - An optional variable that controls how far down the IVA camera may pitch, in degrees.

PERSISTENT_VARIABLES

This is an optional node that may be used to pre-configure some persistent variables in the pod. Each persistent variable is listed on its own line, and it is assigned its initial value (either a number or a string). In the above example, the pod pre-configures the persistent variable MAS_IMP_Mode_Select to 1. If no persistent variables need configured, this node may be omitted.

  PERSISTENT_VARIABLES
  {
    MAS_IMP_Mode_Select = 1
  }

RPM_COLOROVERRIDE

This is an optional node that may be used to override or define named color definitions. Each override uses the standardized COLORDEFINITION node, as shown. If a specific override color was not previously defined, it is added to the local color definition table.

  RPM_COLOROVERRIDE
  {
    COLORDEFINITION
    {
      // 'white' label unlit color
      name = ASET_SWITCHER_NAME_ZEROCOLOR
      color =  213, 213, 213, 255
    }
  }

MAS_ACTION_GROUP

MAS Action Groups provide a way to create customized IVA experiences tuned to a particular set of parts. These special action groups are not identical to the stock KSP action groups, although props will interact with them using the same way (eg, fc.GetActionGroup(10)).

A MAS Action Group identifies one or more parts (by name) and the module on those parts that will be controlled. If more than one part with a given name is found on the vessel, all of those parts will be controlled. If a given part has more than one instance of a module (eg, more than one ModuleAnimateGeneric on a part), all of them will be controlled.

A MAS Action Group consists of an id, which must be 10 or larger, and one or more ACTION nodes (explained below). When multiple ACTION nodes are used, only the first ACTION is used to determine the state of the MAS Action Group. For instance, in the example below, even if there were other actions in the group, only the first ModuleLight would be checked to decide if the action group is on or off.

Supported Modules

The following KSP modules can be used in an ACTION node:

ModuleAnimateGeneric: When the animation is in its 'off' state, or it is moving towards its 'off' state, MAS will report its state as '0'. When the animation is 'on' or it is transitioning to 'on', MAS reports '1'.

ModuleDecouple: Returns 1 if the decoupler has decoupled, 0 otherwise. CAUTION: ModuleDecouple takes place instantly when it is fired. It should be the last action listed in a MAS AG, especially if any of the other actions affect parts that are removed by the decoupler.

ModuleEngines: Returns 1 if the engine is on, 0 if it is off.

ModuleLight: If the light is on, MAS reports 1. If it is off, MAS reports 0.

ModuleRCS: If the RCS module is disabled, MAS reports 0. If it is enabled, MAS reports 1.

In addition, a MAS AG action can contain any module and function from any mod. The module must be listed as 'ModuleName.Method', eg ModuleBdbLesController.DoJettison. There are restrictions to using a generic feature in an AG. The state will always be reported as 'false'. The function (such as 'DoJettison' in this example) must take no parameters. 'on' and 'off' are always treated as 'toggle'.

  MAS_ACTION_GROUP
  {
    name = EVA Floodlight
    id = 10

    ACTION
    {
      name = Light
      part = bluedog_Apollo_Block2_DockingLight
      module = ModuleLight
      action = toggle
    }
    ...
  }

There are two fields in a MAS_ACTION_GROUP:

  • name: Optional. Defaults to "anonymous". A name for the action group in case of configuration errors.
  • id: Required. Any integer value of 10 or larger (it is a 31 bit value, so the upper limit is in excess of 2000000000). AG numbers do not need to be sequential. Duplicate id numbers are ignored - only the first MAS AG sharing the same id will be created.

There are four fields in an ACTION:

  • name: Optional. Defaults to "anonymous". A name for the action in case of configuration errors.
  • part: Required. Identifies the part that this action affects.
  • module: Required. Identifies the module on 'part' that will be affected, as previously described.
  • action: Required. One of toggle, on, or off. The behavior of each is described below.

A toggle action will toggle an action when fc.ToggleActionGroup(id) is called. It will switch on an action if fc.SetActionGroup(id, true) is called and the action is currently 'off'. It will switch off an action in fc.SetActionGroup(id, false) is called and the action is currently 'on'.

An 'on' action will turn on an action if it is off and either fc.ToggleActionGroup(id) or fc.SetActionGroup(id, true) is called. The 'off' action will turn off an action if it is on and either fc.ToggleActionGroup(id) or fc.SetActionGroup(id, false) is called.

Note that the 'action' field is applied per-ACTION, as is the determination whether the action is on or off. It is possible to mix different 'action' settings in a single MAS AG.

IVA Camera Overrides

By default, the IVA camera allows the player to pan 80 degrees to either side, 80 degrees up, and 45 degrees down. MAS can override these values in an IVA by adding these values to the MASFlightComputer config. Care must be taken when using values significantly different than the defaults, however. If the player switches from a MAS IVA to a non-MAS IVA within the same vessel, the default IVA settings are not restored. However, switching from a MAS IVA to the external flight view, and then selecting the non-MAS IVA from the crew portraits will reset the IVA cameras to their defaults.

Power Disruption

As mentioned above, the MASFlightComputer can be affected by high g-loads and/or lack of power. This capability allows for a more immersive experience during IVA flight.

There are two components to using power disruption:

The IVA creator can control the capability in general using the MASFlightComputer configuration options. For example, I've been using gLimit = 5, baseDisruptionChance = 0.20, and requiresPower = true.

requiresPower is a simple boolean - if it is true, and the craft's power is very close to zero (< 0.0001), all configured instruments will be disabled.

gLimit and baseDisruptionChance configure intermittent disruption effects. When the pod is subjected to a g-load equal to gLimit, there is a baseDisruptionChance chance each FixedUpdate that a given instrument is disabled. As the g-load increases, the disruption chance increases with the square root of the difference between the g-load and gLimit. That is, if gLimit is 5, and the pod is under a 9g load, the disruption chance is (sqrt(9-5) = ) 2 times baseDisruptionChance.

powerOnVariable is an optional MAS variable that may provide a per-IVA power control without having to duplicate props to add extra conditions. For instance, an IVA's lamps and gauges may require a master power circuit to be switched on. This behavior may be emulated by using powerOnVariable = fc.GetPersistentAsNumber("Cockpit_Master_Power"), with a circuit breaker prop configured to toggle "Cockpit_Master_Power".

The powerOnVariable is evaluated in Boolean mode. If the result of the variable is 0 or less, it will disrupt power. If the result is any positive value, it will not disrupt power.

The second component of this feature is the use of fc.Conditioned() for controlling variables. Any variable that should be affected by power disruption (such as lights, electrically-controlled gauges, etc) should have their condition variable wrapped in fc.Conditioned(). For example, a lamp that indicates landing gear are deployed would use fc.Conditioned(fc.GetGear()) instead of simply fc.GetGear().

By using fc.Conditioned(), only those props that are affected by electrical disruption will change - for instance, it would look weird if the throttle controls on a craft started jumping around because of g-loads, or they snapped to the off position if the batteries were dead.