Catalog of Bound Variable Names¶

This is the list of special reserved keyword variable names that kOS will interpret to mean something special. If they are used as normal variable names by your kOS script program they may not work. Understanding them and their meaning is crucial to creating effective kOS scripts.

NAMED VESSELS AND BODIES¶

SHIP:

Variable name: SHIP
Gettable: yes
Settable: no
Type: Vessel
Description: Whichever vessel happens to be the one containing the CPU part that is running this Kerboscript code at the moment. This is the CPU Vessel.

TARGET:

Variable Name: TARGET
Gettable: yes
Settable: yes
Type: Vessel or Body or Part
Description: Whichever Orbitable object happens to be the one selected as the current KSP target. If a docking port is selected as the target, it will be the corresponding part. If set to a string, it will assume the string is the name of a vessel being targeted and set it to a vessel by that name. For best results set it to Body(“some name”) or Vessel(“some name”) explicitly. This will throw an exception if called from a vessel other than the active vessel, as limitations in how KSP sets the target vessel limit the implementation to working with only the active vessel.

HASTARGET:

Variable Name: TARGET
Gettable: yes
Settable: no
Type: boolean
Description: Will return true if the ship has a target selected. This will always return false when not on the active vessel, due to limitations in how KSP sets the target vessel.

Alias shortcuts for SHIP fields¶

The following are all alias shortcuts for accessing the fields of the SHIP vessel. To see their definition, please consult the Vessel page, as they are all just instances of the standard vessel suffixes.

Variable	Same as
HEADING	Same as SHIP:HEADING
PROGRADE	Same as SHIP:PROGRADE
RETROGRADE	Same as SHIP:RETROGRADE
FACING	Same as SHIP:FACING
MAXTHRUST	Same as SHIP:MAXTHRUST
VELOCITY	Same as SHIP:VELOCITY
GEOPOSITION	Same as SHIP:GEOPOSITION
LATITUDE	Same as SHIP:LATITUDE
LONGITUDE	Same as SHIP:LONGITUDE
UP	Same as SHIP:UP
NORTH	Same as SHIP:NORTH
BODY	Same as SHIP:BODY
ANGULARMOMENTUM	Same as SHIP:ANGULARMOMENTUM
ANGULARVEL	Same as SHIP:ANGULARVEL
ANGULARVELOCITY	Same as SHIP:ANGULARVEL
MASS	Same as SHIP:MASS
VERTICALSPEED	Same as SHIP:VERTICALSPEED
GROUNDSPEED	Same as SHIP:GROUNDSPEED
SURFACESPEED	This has been obsoleted as of kOS 0.18.0. Replace it with GROUNDSPEED.
AIRSPEED	Same as SHIP:AIRSPEED
ALTITUDE	Same as SHIP:ALTITUDE
APOAPSIS	Same as SHIP:APOAPSIS
PERIAPSIS	Same as SHIP:PERIAPSIS
SENSORS	Same as SHIP:SENSORS
SRFPROGRADE	Same as SHIP:SRFPROGRADE
SRFRETROGRADE	Same as SHIP:SRFRETROGRADE
OBT	Same as SHIP:OBT
STATUS	Same as SHIP:STATUS
SHIPNAME	Same as SHIP:NAME

Constants (pi, e, etc)¶

Get-only.

The variable constant provides a way to access a few basic math and physics constants, such as Pi, Euler’s number, and so on.

Example:

print "Kerbin's circumference: " + (2*constant:pi*Kerbin:radius) + "meters.".

The full list is here: constants page.

Terminal¶

Get-only. terminal returns a terminal structure describing the attributes of the current terminal screen associated with the CPU this script is running on.

Core¶

Get-only. core returns a core structure referring to the CPU you are running on.

Archive¶

Get-only. archive returns a Volume structure referring to the archive. You can read more about what archive is on the File & volumes page.

Stage¶

Get-only. stage returns a stage structure used to count resources in the current stage. Not to be confused with the COMMAND stage which triggers the next stage.

NextNode¶

See the NEXTNODE documentation.

HasNode¶

See the HASNODE documentation.

AllNodes¶

See the ALLNODES documentation.

Resource Types¶

Any time there is a resource on the ship it can be queried. The resources are the values that appear when you click on the upper-right corner of the screen in the KSP window.

LIQUIDFUEL
OXIDIZER
ELECTRICCHARGE
MONOPROPELLANT
INTAKEAIR
SOLIDFUEL

All of the above resources can be queried using either the prefix SHIP or STAGE, depending on whether you are trying to query how much is left in the current stage or the entire ship:

How much liquid fuel is left in the entire ship:

PRINT "There is " + SHIP:LIQUIDFUEL + " liquid fuel on the ship.".

How much liquid fuel is left in just the current stage:

PRINT "There is " + STAGE:LIQUIDFUEL + " liquid fuel in this stage.".

How much liquid fuel is left in the target vessel:

PRINT "There is " + TARGET:LIQUIDFUEL + " liquid fuel in the target ship.".

Any other resources that you have added using other mods should be query-able this way, provided that you spell the term exactly as it appears in the resources window.

You can also get a list of all resources, either in SHIP: or STAGE: with the :RESOURCES suffix.

ALT ALIAS¶

The special variable ALT gives you access to a few altitude predictions:

ALT:APOAPSIS

ALT:PERIAPSIS

ALT:RADAR

Further details are found on the ALT page .

ETA ALIAS¶

The special variable ETA gives you access to a few time predictions:

ETA:APOAPSIS

ETA:PERIAPSIS

ETA:NEXTNODE

ETA:TRANSITION

Further details are found on the ETA page.

ENCOUNTER¶

The orbit patch describing the next encounter with a body the current vessel will enter. If there is no such encounter coming, it will return the special string “None”. If there is an encounter coming, it will return an object of type Orbit. (i.e. to obtain the name of the planet the encounter is with, you can do: print ENCOUNTER:BODY:NAME., for example.).

BOOLEAN TOGGLE FLAGS:¶

These are special Boolean variables that interact with ship systems. They can be True or False, and can be set or toggled using the ON, OFF, and TOGGLE commands. Many of these are for stock action groups, while others are specific to kOS.

Flight Control¶

There are bound variables used in controlling the flight of a ship, which can be found at the following links:

If you want to let kOS do a lot of the work of aligning to a desired heading for you, use Cooked Control.

If you want your script to manipulate the controls directly (as in “set yaw axis halfway left for a few seconds (using the ‘A’ key)”, then use Raw Control.

If you want to be able to READ what the player is attempting to do while your script is running, and perhaps respond to it, then use Reading the Pilot’s Control settings (i.e reading what the manual input is attempting) (By default your script will override manual piloting attempts, but you can read what the pilot’s controls are set at and make your autopilot take them under advisement - sort of like how a fly-by-wire plane works.)

Controls that must be used with LOCK¶

THROTTLE            // Lock to a decimal value between 0 and 1.
STEERING            // Lock to a direction, either a Vector or a Direction.
WHEELTHROTTLE       // Separate throttle for wheels
WHEELSTEERING       // Separate steering system for wheels

Time¶

MISSIONTIME¶

You can obtain the number of seconds it has been since the current CPU vessel has been launched with the bound global variable MISSIONTIME. In real space programs this is referred to usually as “MET” - Mission Elapsed Time, and it’s what’s being measured when you hear that familiar voice saying “T minus 10 seconds…” Point “T” is the zero point of the mission elapsed time, and everything before that is a negative number and everything after it is a positive number. kOS is only capable of returning the “T+” times, not the “T-” times, because it doesn’t read your mind to know ahead of time when you plan to launch.

Time Structure¶

Time is the simulated amount of time that passed since the beginning of the game’s universe epoch. (A brand new campaign that just started begins at TIME zero.)

TIME is a useful system variable for calculating the passage of time between taking physical measurements (i.e. to calculate how fast a phenomenon is changing in a loop). It returns the KSP simulated time, rather than the actual realtime sitting in the chair playing the game. If everything is running smoothly on a fast computer, one second of simulated time will match one second of real time, but if anything is causing the game to stutter or lag a bit, then the simulated time will be a bit slower than the real time. For any script program trying to calculate physical properties of the KSP universe, the time that matters is the simulated time, which is what TIME returns.

It’s important to be aware of the frozen update nature of the kOS computer when reading TIME.

System Variables¶

This section is about variables that describe the things that are slightly outside the simulated universe of the game and are more about the game’s user interface or the kOS mod itself. They represent things that slightly “break the fourth wall” and let your script access something entirely outside the in-character experience.

PRINT VERSION.            // Returns operating system version number. e.g. 0.1.2.3
PRINT VERSION:MAJOR.      // Returns major version number. e.g. 0 if version is 0.1.2.3
PRINT VERSION:MINOR.      // Returns minor version number. e.g. 1 if version is 0.1.2.3
PRINT VERSION:PATCH.      // Returns patch version number. e.g. 2 if version is 0.1.2.3
PRINT VERSION:BUILD.      // Returns build version number. e.g. 3 if version is 0.1.2.3
PRINT SESSIONTIME.        // Returns amount of time, in seconds, from vessel load.

NOTE the following important difference:

SESSIONTIME is the time since the last time this vessel was loaded from on-rails into full physics.

TIME is the time since the entire saved game campaign started, in the kerbal universe’s time. i.e. TIME = 0 means a brand new campaign was just started.

HOMECONNECTION

KUNIVERSE¶

Kuniverse is a structure that contains many settings that break the fourth wall a little bit and control the game simulation directly. The eventual goal is probably to move many of the variables you see listed below into kuniverse.

Config¶

CONFIG is a special variable name that refers to the configuration settings for the kOS mod, and can be used to set or get various options.

CONFIG has its own page for further details.

WARP and WARPMODE¶

Time warp can be controlled with the variables WARP and WARPMODE. See WARP

MAPVIEW¶

A boolean that is both gettable and settable.

If you query MAPVIEW, it’s true if on the map screen, and false if on the flight view screen. If you SET MAPVIEW, you can cause the game to switch between mapview and flight view or visa versa.

LOADDISTANCE¶

LOADDISTANCE sets the distance from the active vessel at which vessels get removed from the full physics engine and put on-rails, or visa versa. Note that as of KSP 1.0 the stock game supports multiple different load distance settings for different situations such that the value changes depending on where you are. But kOS does not support this at the moment so in kOS if you set the LOADDISTANCE, you are setting it to the same value universally for all situations.

PROFILERESULT()¶

If you have the runtime statistics configuration option Config:STAT set to True, then in addition to the summary statistics after the program run, you can also see a detailed report of the “profiling” result of your most recent program run, by calling the built-in function ProfileResult(). “Profiling” is a programmer’s term that means gathering data about how long the program is spending doing each piece of the program. If you are trying to figure out whether your program spent more milliseconds printing numbers to the screen, or more milliseconds calculating a complex formula, or more milliseconds activating actions on a PartModule, and so on, then this feature may help. The ProfileResult() was meant mainly for kOS developers trying to internally determine which parts of the system could use the most optomizing. However, as long as it was implemented for that purpose, it may as well be made available to all the users of kOS as well.

To use:

SET CONFIG:STAT TO TRUE.
RUN MYPROGRAM.
PRINT PROFILERESULT().
// <or>
LOG PROFILERESULT() TO SOMEFIELNAME.csv.

The function ProfileResult() returns a string containing a formatted dump of your whole program, broken down into the more low-level instructions that make it up, with data values describing how long was spent in total on each instruction, how many times that instruction was executed, and the average time spent on a single execution of that instruction (by dividing the total time by the count of how many executions it had).

The format of ProfileResult() is designed to be suitable for importing into a spreadsheet program if you like, because it is formatted as a “comma separated values” file, or CSV for short.

SOLARPRIMEVECTOR¶

Gives the Prime Meridian Vector for the Solar System itself, in current Ship-Raw XYZ coordinates.

Both the Orbit:LONGITUDEOFASCENDINGNODE orbit suffix and the Body:ROTATIONANGLE body suffix are expressed in terms of degree offsets from this Prime Meridian Reference Vector.

What is the Solar Prime Reference Vector?¶

The solar prime vector is an arbitrary vector in space used to measure some orbital parameters that are supposed to remain fixed to space regardless of how the planets underneath the orbit rotate, or where the Sun is. In a sense it can be thought of as the celestial “prime meridian” of the entire solar system, rather than the “prime meridian” of any one particular rotating planet or moon.

In a hypothetical Earthling’s solar system our Kerbal scientists have hypothesized may exist in a galaxy far away, Earthbound astronomers use a reference they called the First Point of Aries, for this purpose.

For Kerbals, it refers to a more arbitrary line in space, pointing at a fixed point in the firmament, also known as the “skybox”.

OPCODESLEFT¶

This returns the amount of IPU (instructions per update) that are left in this physics tick. For example, if this gives you the value 20, you can run 20 more instructions within this physics update before the game will let the rest of the game run and advance time. After this amount of instructions, other CPUs will run their instructions, and the game will do the rest of its work, and then TIME:SECONDS will increase and you’ll get another physics update in which to run more of the program.

Another way to think of this is “For the next OPCODESLEFT instructions, the universe is still physically frozen, giving frozen values for time, position, velocity, etc. After that it will be the next physics tick and those things will have moved ahead to the next physics tick.”

OPCODESLEFT can be used to try to make sure you run a block of code in one physics tick. This is useful when working with vectors or when interacting with shared message queues.

To use:

// Will always wait the first time, becomes more accurate the second time.
GLOBAL OPCODESNEEDED TO 1000.
IF OPCODESLEFT < OPCODESNEEDED
  WAIT 0.
LOCAL STARTIPU TO OPCODESLEFT.
LOCAL STARTTIME TO TIME:SECONDS.

// your code here, make sure to keep the instruction count lower than your CONFIG:IPU

IF STARTTIME = TIME:SECONDS {
  SET OPCODESNEEDED TO STARTIPU - OPCODESLEFT.
} ELSE {
  PRINT "Code is taking too long to execute. Please make the code shorter or raise the IPU.".
}

Addons¶

Get-only. addons is a special variable used to access various extensions to kOS that are designed to support the features introduced by some other mods. More info can be found on the addons page.

Colors¶

There are several bound variables associated with hardcoded colors such as WHITE, BLACK, RED, etc. See the linked page for the full list.

Variable Name	Can Read	Can Set	Source	What it manages
`SAS`	yes	yes	stock	SAS action group
`RCS`	yes	yes	stock	RCS thrusters action group
`GEAR`	yes	yes	stock	Landing gear action group
`LIGHTS`	yes	yes	stock	Lights action group
`BRAKES`	yes	yes	stock	Brakes action group
`ABORT`	yes	yes	stock	Abort action group
`LEGS`	yes	yes	kOS	The extended state of all landing legs
`CHUTES`	yes	yes	kOS	The armed state of all parachutes
`CHUTESSAFE`	yes	yes	kOS	The armed state of all “safe” parachutes
`PANELS`	yes	yes	kOS	The state of retractable solar panels
`RADIATORS`	yes	yes	kOS	The deployed state of radiators
`LADDERS`	yes	yes	kOS	The extended state of ladders
`BAYS`	yes	yes	kOS	The opened state of payload/service bays
`INTAKES`	yes	yes	kOS	The opened state of all intakes
`DEPLOYDRILLS`	yes	yes	kOS	The deployment state of all drills
`DRILLS`	yes	yes	kOS	The running state of all drills
`FUELCELLS`	yes	yes	kOS	The running state of all fuel cells
`ISRU`	yes	yes	kOS	The running state of all resource converters
`AG1`	yes	yes	stock	Action Group 1.
`AG2`	yes	yes	stock	Action Group 2.
`AG3`	yes	yes	stock	Action Group 3.
`AG4`	yes	yes	stock	Action Group 4.
`AG5`	yes	yes	stock	Action Group 5.
`AG6`	yes	yes	stock	Action Group 6.
`AG7`	yes	yes	stock	Action Group 7.
`AG8`	yes	yes	stock	Action Group 8.
`AG9`	yes	yes	stock	Action Group 9.
`AG10`	yes	yes	stock	Action Group 10.
AGn	yes	yes	AGX	ActionGroupsExtended action groups