Defining Components

The components array defines the hardware on one spacecraft.

Component shape

{
  "class": "Transmitter",
  "name": "Transmitter",
  "mesh": "None",
  "enabled": true,
  "position": [0, 0, 0],
  "rotation": [0, 0, 0],
  "scale": 1.0,
  "data": {
    "Mass": 1.0
  },
  "models": []
}

Field	Purpose
class	Selects the component implementation
name	Operator-facing command and event target
mesh	Optional visual asset
enabled	Initial simulation state
position	Local position in meters
rotation	Local rotation in degrees
scale	Visual scale
data	Class-specific properties
models	Optional supported simulation or error models

Mass is the common data field. Other keys depend on the class. Unknown classes or unsupported properties produce warnings or are skipped.

Basic operating components

"components": [
  {
    "class": "Solar Panel",
    "name": "Solar Panel",
    "data": {
      "Area": 0.3,
      "Efficiency": 0.4,
      "Mass": 10.0
    }
  },
  {
    "class": "Battery",
    "name": "Battery",
    "data": {
      "Nominal Capacity": 80.0,
      "Charge Fraction": 0.5,
      "Mass": 5.0
    }
  },
  {
    "class": "Computer",
    "name": "Computer",
    "data": {
      "Mass": 2.0
    }
  },
  {
    "class": "Reaction Wheels",
    "name": "Reaction Wheels",
    "data": {
      "Mass": 1.5
    }
  },
  {
    "class": "Receiver",
    "name": "Receiver",
    "data": {
      "Antenna Gain": 3.0,
      "Mass": 2.0
    }
  },
  {
    "class": "Transmitter",
    "name": "Transmitter",
    "data": {
      "Mass": 1.0
    }
  },
  {
    "class": "Storage",
    "name": "Storage",
    "data": {
      "Mass": 4.0
    }
  }
]

Payload, propulsion, and docking examples

Beyond the basic stack, these are the data blocks for the classes most scenarios add. Every key is optional and falls back to a class default; Mass is always worth setting.

A camera, with its field-of-view envelope:

{
  "class": "Optical Camera",
  "name": "Main Camera",
  "position": [0.0, -0.36, -0.16],
  "rotation": [90.0, 0.0, 0.0],
  "data": {
    "Sample Rate": 10.0,
    "Field Of View": 10.0,
    "Min Field Of View": 1.0,
    "Max Field Of View": 15.0,
    "Resolution": [1024, 1024],
    "Mass": 3.0
  }
}

A transmitter, where Bit Rate controls downlink throughput:

{
  "class": "Transmitter",
  "name": "Transmitter",
  "data": { "Antenna Gain": 3.0, "Bit Rate": 20000.0, "Mass": 1.0 }
}

A thruster, where Dispersed Factor models a failed-off nozzle at runtime:

{
  "class": "Cold Gas Thruster",
  "name": "Thruster +Z",
  "position": [0.0, 0.0, -0.5],
  "data": { "Max Thrust": 1.0, "Specific Impulse": 250.0, "Mass": 1.5 }
}

A fuel tank and valve. A supply tank must set Amount; a receiving tank must set a positive Desired Ingoing Flow Rate:

{
  "class": "Fuel Source",
  "name": "Main Tank",
  "data": { "Capacity": 50.0, "Amount": 45.0, "Maximum Outgoing Flow Rate": 2.0, "Mass": 8.0 }
},
{
  "class": "Fuel Valve",
  "name": "Main Valve",
  "data": { "Commanded Percent Open": 1.0, "Max Flow Rate": 2.0, "Mass": 0.5 }
}

A docking adapter, needed on both the chaser and the target:

{
  "class": "Docking Adapter",
  "name": "Docking Adapter",
  "position": [0.0, 0.36, -0.015],
  "rotation": [-90.0, 0.0, 0.0],
  "data": { "Capture Distance": 0.05, "Capture Angle": 20.0, "Separation Force": 100.0, "Mass": 5.0 }
}

NOTE

Some data keys are deliberately author-ignored because the controller or team config owns them: a Receiver and Transmitter take their Frequency from teams[].frequency, and runtime state such as a switch being open or a fuse being blown is read through get_configuration, not authored here.

Supported component families

Common scenario classes include:

• power: Solar Panel, Battery, Power Switch, Power Fuse, Power Diode, Power Sink, Power Current Limiter, Power Voltage Regulator, and Power Interconnect
• computing and attitude: Computer or Guidance Computer, Reaction Wheels, and External Force Torque
• propulsion: Thruster, Thruster Array, Ion Thruster, Fuel Source, Fuel Valve, Fuel Pump, and Fuel Interconnect
• communications: Receiver, Transmitter, and Jammer
• data and payloads: Storage, Camera, Charge Coupled Device, Heatmap Camera, RADAR, and Laser Range Finder
• sensors: GPS Sensor, EM Sensor, Magnetometer, and Gyroscope
• interaction: Docking Adapter and Physical Text

Use these component guides for behavior and assumptions:

• Solar Panel
• Battery
• Guidance Computer
• Reaction Wheels
• Receiver
• Transmitter
• Storage
• GPS Sensor
• Magnetometer
• Gyroscope
• EM Sensor
• RADAR
• Laser Range Finder
• Docking Adapter

Attaching a model

{
  "class": "Solar Panel",
  "name": "Solar Panel",
  "data": {
    "Mass": 10.0
  },
  "models": [
    {
      "class": "Solar Panel Degradation Error Model",
      "enabled": true,
      "data": {
        "Degradation Rate": 10.0
      }
    }
  ]
}

The model must be supported by its parent component. An event can later change its exposed properties.

Authoring rules

• keep names unique within a spacecraft
• use class names from Studio or an existing working scenario
• use the documented units
• avoid adding an error model to an unsupported component
• test each specialized component before adding the next

Next, wire power and fuel when the mission needs explicit networks.