TOPIC main
Welcome to Companion!
This command is Companion's on-board help service. If you would like to make a hard copy of this information, it can be found in the `manual` file inside your controller's system memory.
Basic commands:
"safeword", "verbosity", "send", "reboot", "halt", "off", "profile", "shutdown", "bootstyle", "reset", "about", "open", "preload", "sound", "remark", "trigger", "do",
"color", "tutorial", "sentinel"*, "sxdwm", "relay", "persona", "vox", "charge", "coil", "scheme", "volume", "audience", "optics", "hover", "unleash", "range", "leash",
"follow", "navigate", "device", "setup console", "power", "zap", "help", "commands", "unlock", "lock", "lust"**, "haptic"** "task", "module", "conf", "on", "boot",
"warp", "jump", "file", "persist", "react", "chain".
* requires security enhancements ([http://support.nanite-systems.com/?id=285 ATOS/E]).
** requires emotion simulator ([http://support.nanite-systems.com/?id=2034 TESI]).
Commands supplied by common first-party devices:
"kinematics", "handle" (or "handles" or "horns"), "sign", "mood", "icon", "matrix"
Administrator commands:
"keychain", "name", "authority", "access", "rlv", "restraint", "xanadu", "domain", "guests", "policy", "aux", "beacon", "gender", "pin", "bolts", "autolock", "drainprotect", "chorus".
General-interest topics: "subsystems", "users", "software", "updating", "bangs", "personas", "development", "data", "bugs".
If you need help with a command not listed here, try typing `<command>` or `<command> help` to check for embedded documentation.
For a basic introduction to the system, see "help introduction". If you are operating yourself, put an `@` sign before all commands, e.g.: `@help introduction`
Looking for troubleshooting advice? Check out the online [http://support.nanite-systems.com/?id=174 Frequently Asked Questions] site.
TOPIC introduction
Companion is the operating system included in your main controller. It is responsible for powering the robot, directing power flow, and giving the robot instructions on how to behave.
It can also trigger behavior spontaneously, and interact with a wide range of devices and equipment using various protocols.
In general, the word 'unit' is used to refer to the robot as a whole, although it may also be used in phrases like 'main controller unit' and 'chassis specification unit' to refer to specific components.
The rest of the robot's body is referred to as the 'chassis.' Most humanoid robots also have a brain-like computer core in the head, called the 'cortex.'
The syntax used in this manual is as follows:
"command" indicates text that can be typed as a command, and has an entry in the manual.
`text` indicates other text that can be typed or may appear as output.
`one|two` indicates alternatives; either `one` or `two` can be used.
<variable> indicates a mandatory variable.
[parameter] indicates an optional (literal) parameter.
[<variable>] indicates an optional variable.
As mentioned on the starting page, a robot can run commands to control itself by prefixing them with `@`, for example `@about`.
If you are controlling a robot through a remote control device, then the `@` is not necessary.
Other introduction pages: "help personas", "help software", "help updating", "help subsystems", "help users", "help development", "help data", "help bangs", and "help batching".
TOPIC bugs
To report a software defect, please use the [http://develop.nanite-systems.com/report_issue online issue report form].
You will be required to include your username in the report.
Ideal bug reports are concise, specific, and reproducible. Many common issues can be resolved through the [http://support.nanite-systems.com/?id=174&mode=hierarchy FAQ page].
TOPIC personas
Personas are the primary tool for configuring your unit's behavior. They affect its speech patterns, the way its voice sounds, and can replace some attachments through #RLV folder loading. They can also be configured to trigger actions on initialization, through persona scripts.
To see what #RLV folder your current persona uses, type "persona". The folder is listed as the current overlay path.
When the unit's mind is turned off (see "help subsystems"), it is restricted to saying a handful of preset messages. These are activated using commands that start with `.` such as `.hi` and `.bye`. To see the currently available dot commands, type `.info`.
Preset messages are changed by personas, and can be used even when the mind is enabled. This makes responses more efficient, as well as more consistent. To use dot commands remotely, see "relay".
Personas consist of two files, a `p_` file and an optional `px_` file:
- The `p_` file tells the controller which #RLV folder to use, what sounds to use, and what preset messages to apply.
- The `px_` file contains a sequence of actions to perform when the persona is activated. See [http://support.nanite-systems.com/?id=231 the online Arabesque documentation] for details.
Like most other data, these reside in the user memory area of the controller. See "help data" for more information.
TOPIC data
The package manager (see "help software") can be used to automatically manage data files. However, it is possible to manually manipulate them. Unlock the bolts on your controller (as explained in "help bolts") to enable editing, and then edit the appropriate linked part for your controller type:
- DAX/2: part 18
- DAX/2m: part 12
- SXD: part 68
- NS-112 (Aide): part 4
- NS-476 (Aegis): part 23
- NS-115 (Scout): part 7
- NS-409 (Nightfall): part 22
- DAX/3: part 19
- DAX/3m: part 5
If using Firestorm, you can cycle through the linked parts (once 'Edit linked' is enabled) using ctrl-comma and ctrl-period. For controller types not listed here, look for the link with the description `program`, or containing the script `_arabesque`.
More information is available [http://support.nanite-systems.com/?id=234 in the online manual].
TOPIC software
The application software on your controller is customizable. To install, update, or remove software, use the manage > software menu. Installation and updating requires the presence of a compatible Xanadu software server.
A list of support locations can be found [http://support.nanite-systems.com/?id=173 online].
TOPIC updating
Updating the system to the latest version can be accomplished in several ways:
1. If you received a (Redeliver) object with your controller, also known as a redelivery monad, wear this to automatically deliver a fresh copy of the newest system.
2. Using the console, visit a region that supports Xanadu service (e.g. Eisa, NS's home) and type:
i. `xanadu servers` (to get a list of available servers)
ii. `xanadu connect <server>` (to connect to a server offering system updates, e.g. xcentral:0)
iii. `xanadu list` (to get a list of packages both on your system and on the server)
iv. `xanadu upgrade Companion_x.x.x` (where x.x.x is the version number of the latest system release)
3. Using the menu, visit a region that supports Xanadu service (e.g. Eisa, NS's home) and select:
`manage > software > connect > (server) > update > Companion_x.x.x > upgrade`
Where (server) is the name of a server offering system updates, e.g. `xcentral:0`.
It is advisable to back up your user list before updating. Run the following command first: `keychain save`
(Remember to put `@` signs before each command if you are operating the unit locally.)
Upon successful updating, the unit will receive a notecard containing patch notes and any necessary instructions to finish the installation.
Current version numbers and exact instructions, including instructions for installing pre-releases of upcoming versions, are always available at [http://support.nanite-systems.com/?id=283 the support.ns website].
For more information about the software management system, see "help software" or "help xanadu".
TOPIC subsystems
Companion permits selective control of individual power subsystems to conserve power when certain functionality is either not needed or not desired. These can be accessed from the subsystems menu, or manipulated with the "power" command.
By default, these subsystems are:
- video (209 W): vision
- audio (75 W): hearing
- move (5 W idle): walk (159 W), jump (203 W), and touch
- rapid (5 W idle: run (203 W) and fly (605 W)
- teleport (170 W idle): jump to a new location instantly (cost varies with distance, up to 23.76 kJ)
- voice: speak quietly (10 J per letter)
- preamplifier: speak at a normal volume (10 J per letter)
- power-amplifier: shout (80 J per letter)
- mind (121 W): speak freely (see "help personas")
- receiver (22 W): receive private text messages
- transmitter (43 W): send private text messages
- GPS (58 W): determine location
- identify (32 W): recognize the names of others
W (watts) means that one 1 J (joule) of power will be expended for each second something is active.
Some subsystems stack additively; for example, shouting costs 100 J per letter in total. They also have dependencies, e.g. the unit cannot teleport while unable to move. Subsystems that are disabled because of a missing dependency draw no power.
These power costs are variable if your chassis is designed differently. A Chassis Specification Unit (CSU), such as the EXB-8505, can be used to adjust the controller's expectations of the chassis's abilities.
TOPIC users
A user is anyone who interacts with the system. Like many control systems, Companion allows you to register users and indicate that they should have special privileges when interacting with the system. Unregistered users are called guests.
There are three ranks of registered user:
- Owner (rank 2): unlimited control over the system.
- Manager (rank 1): as owner, but not able to affect owner accounts. This is similar to a "co-owner" on other systems.
- Regular user (rank 0): limited access to everyday features, but not able to configure the system. Not able to use commands marked with an asterisk (*) in the listing produced by the "commands" command.
When a guest is given access to the system (see "help guests" and "help access"), they have equivalent power to a level 0 user, and may use any menu or command that a level 0 user might.
To configure the users on your system, see "help keychain" or explore the `manage > users` menu.
Companion supports treating group members as users, as well as completely disabling access by guests, or even restricting access to just the unit's owners. See "help access" for more information.
TOPIC development
Companion is designed to be highly extensible, enabling the creation of new accessory devices, scripts, and software applications, and Nanite Systems is committed to providing open API information wherever exciting new uses of its technologies are possible.
To learn more about developing for Companion and other NS products, visit our developers' portal at http://develop.nanite-systems.com/
TOPIC bangs
Bang (!) commands, formerly known as cortex commands, are commands intended for the unit's use to enhance its expressivity. To send a bang command remotely, use the "relay" comamnd, e.g. "relay !greet".
This simulates the effect that would be achieved if the unit directly said `!greet`.
`!greet`, `!greet2`, `!love`, `!love2`, `!love3`, `!love4`, and `!bye`
Various verbal emotive expressions.
`!broken` and `!fixed`
Simulates uneven power to illumination elements. May cause sparking when used with certain peripherals or batteries.
`!working` and `!done`
Displays the ‘working’ light pattern via ornamental status light elements.
`!fan <level>`
Adjusts the fan speed. <level> can be a number from 0 to 100, or one of the preset keywords: off, idle, low, med, med, high, or max.
`!spark`
Simulates a mild electrical fault.
`!fault`
Simulates a serious electrical fault.
`!release`
Allows the unit to bypass the vocoder pipeline entirely for diagnostic purposes; see below. See also [http://support.nanite-systems.com/?id=580#The%20redirect online troubleshooting guide].
`!lamp on|off` (requires DAX/3, SXD 8.4, or other new flicker bus firmware)
Controls the intensity of illumination emitted by the controller's lighting elements.
`!repair`, `!repaired`
Starts or stops simulated repair effects.
`!light <message>`
Sends a message directly over the light bus to all devices. See "help development". To send a message to only one device, use the "device" command. (See "help device".)
TOPIC chain
`chain [-x] [-c] [-a] [-p] <command-or-pipe [| <command-or-pipe ...>>`
Chains a sequence of commands or pipe keys together. Output from one will be fed into the next.
`-x`: Run the whole chain as EXECUTE instructions. (See "batching")
`-c`: Run the whole chain as COMMAND instructions. (See "batching")
`-a`: Do not run the sequence now; instead assign it as the audience pipeline. (See "audience") Any existing audience pipeline will be removed first. Implies `-p`.
`-p`: Keep the pipeline in memory after use. Normal behavior is to destroy a `chain` pipe after a single message is sent through it.
The `-p` switch is useful for commands that generate multiple output messages in rapid succession, e.g. "about". Remove them afterward with `chain purge`, below.
`chain purge`
Remove any pipes created by `chain`, including the "audience" pipeline.
Examples
`chain -a filter lisp | remark -d`: When "audience" is enabled, all incoming chat will be filtered through the `lisp` filter, then printed locally with no prefix.
`chain -x power | filter polyglot`: Translate the current power status through the `polyglot` "filter" (defaults to en|it). Using `-x` suppresses the help tip.
`chain echo Hi hi! | b2e91c67-c32c-4c8e-9c03-9397dd25eddc`: Sends "Hi hi!" to the pipe b2e91c67-c32c-4c8e-9c03-9397dd25eddc, which is the avatar UUID for NaniteSystems Resident. If the pipe matches an avatar in the same region the message will preferentially be sent to that avatar on channel 0.
`chain -p file | filter lisp`: Crashes the kernel because "file" outputs way too much text. DON'T try this at home!
TOPIC execution
Execution environment in Companion
The Companion execution environment is minimal compared to most other operating systems. Programs are initialized with only three pieces of data: the UUID of the recipient, their full command-line, and a single bit indicating whether the command is being executed interactively (directly from terminal input) or not.
Consequently, all of these attributes serve dual purposes:
- The EXECUTE/COMMAND flag indicates how to handle program output. EXECUTE mode is used for most menu commands and sequential scripts ("do", "domain", "navigate", etc.); it omits any error or help messages mentioning the command-line and sends status change output to local chat, not the recipient, if it is reasonable to do so.
- The command-line also includes data input for nearly all commands, instead of a discrete input stream listener as in POSIX environments. For example, when "filter" is specified in an "audience" "chain", only the filter name is provided as an argument; the message will be appended.
- The recipient is only required to be the key of an avatar for security checks. Otherwise it is interpreted to be the UUID of a pipe, which will be
TOPIC filter
`filter <filter name> <message>`
Applies a vox filter to a message with its current settings. The output is suitable for piping (see "chain")
TOPIC file
`file`
Lists all files in user memory.
`file compat [on|off|toggle]`
Enables or disables 8.4 application compatibility mode (not recommended.) This was formerly known as `compat`.
`file ddt [on|off|toggle]`
Enables or disables user memory debugging (not recommended.) This was formerly known as `disk ddt`.
`file check`
Fixes certain memory card issues that impact the ability of "xanadu" to install packages correctly. Formerly `disk check`. Does not check files.
TOPIC react
`react on|off|toggle`
Enables or disables handling of reaction commands: custom definable keywords that you can set up to make the unit react to people talking in chat on channel 0.
`react keyword <keyword>`
Sets the reaction keyword. This is a string that must be at the start of every reaction or it will be ignored.
`react set <trigger>: <action>`
Adds or updates a trigger, so that typing '<keyword>, <trigger>' on channel 0 will activate `<action>`.
`react remove <trigger>`
Remove a trigger.
`react list`
List configured triggers.
EXAMPLE REACTION USAGE
With the following commands:
`react keyword robot`
`react set say hello: relay Hello!`
The unit will say 'Hello!' whenever you type 'robot, say hello' in chat. Reactions are case-insensitive.
TOPIC vox
`vox pipe on|off|toggle`
`vox release on|off|toggle`
`vox probe|status|list|clear`
`vox <filter> [<parameters>]|remove|help`
Configures the speech modulation pipeline. This can also be accessed through the cortex menu.
The majority of the vox command's functions pertain to the filter. Voice filters are lightweight programs that alter the formatting and characteristics of text.
In order to prevent filters from being applied in an illogical order, they are divided into four categories:
1. semantic (what you mean to say)
2. linguistic (how you turn that into language)
3. phonetic (the sounds you intend to produce)
4. typographic (final output by the unit's vocal speaker)
This division ensures that, for example, word replacements (semantic changes) are performed before phonetic changes like lisping, which might otherwise conflict with the word substitution process.
`probe`: clears the current filter chain and searches for installed filters. Any chat messages in the filtering pipeline will be sent afterwards.
`clear`: clears the current filter chain only. Any chat messages in the filtering pipeline will be sent afterwards.
`status`: reports which filters are currently active.
`list`: reports the filters currently installed.
`<filter>`: enables the indicated filter.
`<filter> <parameters>`: passes parameters to the indicated filter and activates it (if not already active).
`<filter> remove`: disables the indicated filter.
`<filter> help`: returns embedded documentation for the given filter, e.g. the filter's purpose and the format of supported parameters.
`pipe`: toggles the output pipe, which forwards chat to compatible RLV gag devices. This prevents typing on chat channels and should not be enabled except for use with certified compatible gags. The "send" command can still be used, however.
`release`: allows or blocks the use of the `!release` command (see "help bangs").
TOPIC shutdown
`shutdown -h|-r|-k <time>|now`
`shutdown -c`
Shuts down the system in the specified number of seconds. If <time> is 0 or "now", no warning is sent.
`-h`: power off
`-r`: reboot
`-k`: fake warning
`-c`: cancel scheduled shutdown
TOPIC volume
`volume cycle|help|set [<number>]|full|mute`
`volume mute|unmute|toggle tone|chime|voice|menu`
Volume settings.
`cycle`: Switch between whisper, speak, and shout-capable presets.
`help`: Displays this message.
`set`: Sets the chime and voice volume to `<number>`
`mute`: Sets the mute flag on the specified feature (see below)
`unmute`: Clears the mute flag on the specified feature (see below)
`toggle`: Switches the mute flag on the specified feature (see below)
Features (for use with `mute`/`unmute`/`toggle`):
`tone`: Voice sample played when text emitted
`chime`: All sound effects from the speaker other than TTS messages
`voice`: TTS messages
`menu`: menu beeps only
TOPIC compat
`compat on|off`
Enables or disables link message index translation for legacy (8.4 and earlier) applications in Companion 8.5 and later.
This is somewhat inefficient and does not fully restore compatibility, as system libraries may hibernate and be unable to answer certain requests.
See [http://develop.nanite-systems.com/?best_practices_for_8.5_application_development Best Practices for 8.5 Application Development] for more information.
TOPIC persona
`persona [<name>]`
`persona probe`
Displays the available and active personas, or activates a persona. To disable persona overlays entirely, type "persona default".
`probe`: Re-scans for available persona files.
To read more about personas in general, see "help personas".
TOPIC relay
`relay <message>`
Causes the unit to speak the specified message. This works even if the unit's mind subsystem is disabled. See "help subsystems".
TOPIC verbosity
`verbosity cycle|public|internal|none`
`public` (0): played at 10% (whisper) volume, even if speakers (voice subsystem) are muted
`internal` (1): only the unit sees the messages
`none` (2): no messages
TOPIC hover
`hover active|shutdown <level>`
Sets the hover offset to be used when the system is online or shut down. `<level>` is measured in centimeters. Type "hover" to see the current values. A reboot may be required afterward.
TOPIC setup
`setup console`
Installs the Native Console HUD into the inventory filesystem. See "help console-native" for more information.
`setup console screen`
Installs the Screen Console HUD into the inventory filesystem. See "help console-screen" for more information.
TOPIC console-native
The Native Console HUD is the current interface overlay for Companion and ATOS/CX. Introduced to Companion in version 8.6, Native utilizes the entire screen to provide an immersive experience.
To adjust the size of Native, click on the HUD icon in the bottom-right corner of the screen, and choose 'Setup.' The HUD icon resembles a circuitboard with five upward-facing prongs.
Each icon in the bottom-right corner, including the system model badge, can be clicked on to access a menu. All of the gauges and their numeric values are shown while the system model badge menu is open.
If you find Native unsuitable for your robot's field of vision, delete it from #RLV/~NS/console and run the command `setup console screen`.
Some versions of Native include LaserLine, which tracks targets and POIs in the region. This can be disabled by deleting the _laserline module from within the HUD object. You will need to reset Native afterward, using the HUD menu.
TOPIC console-screen
The Screen Console HUD is the classsic interface overlay for Companion. Introduced in version 8.1, the Console takes the form of a dock bar at the bottom of the screen, with each segment representing a device.
Some units may find that the HUD is positioned incorrectly for their displays; if this is the case, it can be adjusted by editing the `_console-config` notecard inside of the controller's system memory.
The `_console-config` file is automatically re-copied into the HUD whenever it changes, ensuring that settings persist through system updates.
TOPIC coil
`coil reset|help|status|ddt|unbind`
Charger interface control.
`reset`: resets the charger interface module and releases motor/mind locks.
`help`: this message.
`status`: reports the charger interface module's status.
`ddt`: toggle debug messages.
`unbind`: remove all RLV restraints.
TOPIC zap
`zap <serial> <amount>`
`zap <amount>`
Charges the unit specified by the indicated serial number with the specified amount of power in kilojoules.
If no serial number is specified, all units in a 10 m radius will be charged.
When ATOS security enhancements are installed, the maximum amount is fixed at 100 kJ to reduce the risk of system damage.
TOPIC power
`power status`
Reports the system's current power status, indicating the subsystem state, power draw rate, and remaining battery.
`power video|audio|move|teleport|rapid|voice|mind|preamplifier|power-amplifier|receiver|transmitter|GPS|identify`
Toggles the indicated subsystem.
`power motors|radio`
Cycles the indicated metasystem. "power motors" switches between `move` and `rapid`, `move` only, and disabling both. "power radio" switches between `transmitter` and `receiver`, `receiver` only, `transmitter` only, and disabling both.
A third metasystem, `volume`, is controlled through the "volume cycle" command.
TOPIC volume
`volume cycle`
Switches between whisper, speak, shout-capable, and muted. Shout-capable mode (100% master volume, with the voice, preamplifier and post-amplifier subsystems enabled) is the default.
`volume set <number>`
Sets the master sound volume to `<number>`%.
`volume full|mute`
Mutes or unmutes the master sound volume.
`volume <verb> <channel>`
Verbs:
`mute`: mutes the specified channel
`unmute`: unmutes the specified channel
`toggle`: toggles the specified channel
Sound effect channels:
`tone`: voice sample played when text emitted
`chime`: all sound effects from the speaker other than TTS messages
`voice`: TTS messages
`menu`: menu beeps only
TOPIC scheme
`scheme boot|menu <number>`
`scheme voice <name>`
`scheme custom boot|menu <key1> <key2>`
Configures the system sound schemes. Note that this does not affect the tone marker (the sound made when speaking); see "help personas" and "help gender" for more information.
`boot`: Sets the boot chime scheme or reports the number of boot chime schemes.
`menu`: Sets the boot chime scheme or reports the number of menu chime schemes.
`voice`: Sets the voice notification theme or reports the supported voice notification themes.
`custom`: Sets the sounds for a custom sound scheme, and switches to it.
TOPIC bootstyle
`bootstyle <number>`
Determines the amount of information reported while the unit is powering on.
`0`: detailed and slow
`1`: silent and slow
`2`: brief and slow
`3`: silent and slow (default)
`4`: detailed and fast
`5`: silent and fast
`6`: quiet and fast
`7`: silent and fast
TOPIC profile
`profile [<name>]`
Loads power profile `<name>`. If no profile is specified, lists available power profiles.
`profile save|delete <name>`
Saves or deletes the power profile `<name>`. The system may store up to 9 power profiles.
Power profiles are presets used to select which subsystems are active. See "help subsystems" for more information.
The default power profiles included with Companion are:
- `full` (all subsystems on)
- `sleep` (all subsystems off)
- `idle` (listen, identify, and IM)
- `eco` (local activity only)
- `listen` (listen, identify, and and receive IMs)
- `emergency` (focused on following orders)
TOPIC device
`device [<device> <message>]`
Sends `<message>` to `<device>` over the light bus (see "help development"). If no arguments are specified, lists the attached devices and their names.
`device <device> info`
Reports information about the device, including its name, key, and version info.
`device <device> remove`
Shuts down the device and disables its safety bolts (if engaged). It will be deleted from the device manager when actually detached. Alternatively, this can be canceled with a reboot.
`device probe`
Soft-resets the device manager by clearing the list of known devices and starting a device probe. This is a quicker procedure than a full hard reset of the device manager (e.g. `reset device`), which will perform up to seven full probes until it finds a battery.
TOPIC about
`about`
Lists the unit's identification information, along with a list of recognized users and active devices.
TOPIC follow
`follow [<username>]`
Follows `<username>`. If no user name is specified, then following is toggled, i.e. if the unit is currently following someone, it is canceled, and if the unit is currently following no one, then it will start following the person who issued the command.
See "help leash" and "help unleash" for more idiomatic synonyms.
TOPIC color
`color [<slot>] [save] <color definition>`
`color [<slot>] apply|save|reset|restore`
Controls the unit's lighting colors.
Where `<color definition>` is either `<<r> <g> <b>>` (vector format), `#<rrggbb>` (web hex format), or `<name>`
`<r>` `<g>` `<b>` values may be either floating point (0.0-1.0) or 8-bit (0-255).
`<slot>` is an optional parameter that indicates which of the four colors to overwrite. If omitted, all colors will be affected.
Valid options for slot are `a`, `b`, `c`, `d`, `primary`, `secondary`, `tertiary`, `quartenary`, or `p`, `s`, `t`, `q`. Color slot names are case-insensitive.
`apply`: forces the light bus to accept the current color(s)
`save`: store the current color(s) as the permanent color(s)
`reset`: revert current and stored value to the default (`company`)
`restore`: revert to stored color(s)
Additionally, the syntax "color [<slot>] save <color>" can be used to set and save a color simultaneously.
See [http://support.nanite-systems.com/?id=433 the online manual] for a list of supported color names.
TOPIC bolts
`bolts lock|auto|unlock|cycle`
Sets the integrity level of the safety bolt system.
`lock`: seals the bolts entirely, making removal of the controller impossible
`auto`: seals the bolts while the unit is active
`unlock`: disconnects the bolts entirely (DANGER: Do not remove controller while unit is running!)
`cycle`: switches to the next bolt-locking state
Note that the system's safety bolts automatically lock whenever the unit's console is locked (see "help lock") including when it is configured to lock automatically (see "help autolock").
A locked unit keeps its bolts locked even when the unit is powered down, to prevent component theft.
TOPIC do
`do [<script>]`
Executes a script with Arabesque. If no script name is specified, a list of available scripts is provided. Arabesque scripts reside in user memory, and are identified with the `a_` prefix. This prefix is not included in the name when using "do".
Arabesque is a small superset of the standard system commands that adds conditional statements and some variables in order to facilitate batch processing. See [http://support.nanite-systems.com/?id=231 online documentation] for more information.
See also "trigger", an alternative command for starting Arabesque scripts prefixed with `e_`.
See also "execution" for more information on how commands execute.
TOPIC remark
`remark <message>`
Sends a message directly to the unit. This is useful for ad hoc RLV commands.
TOPIC lock
`lock`
Locks the console immediately. This will lock the controller's safety bolts temporarily (see "help bolts"). Locking prevents use of local access until the PIN has been entered correctly. See also "help pin", "help autolock", and "help unlock".
TOPIC unlock
`unlock <pin>`
Unlocks the console. This may release the controller's safety bolts (see "help bolts") if they are configured to be in the unlocked state. See "help lock" for more information on console locking.
TOPIC commands
`commands`
Lists all registered commands. Asterisks in the list indicate that access level 1 (manager) or higher is required; ellipses (...) indicate the command has additional parameters.
This list is automatically regenerated on reboot, although installed software may add and remove entries at any time.
`commands prefix [default|<new prefix>]`
Changes the prefix used for local commands issued on channel 1. If `default` is specified, this will be derived from the first two characters of the unit's nominal designator, e.g. `c4` for `c4itlin`.
`commands local on|off|toggle`
Enables or disables parsing of commands input on channel 1. Commands must be prefixed properly (see above) and the accessor must have local access permissions.
Manager access or higher is required to adjust prefix and local settings.
TOPIC help
`help <topic>`
Displays documentation for the system. For an introduction, type "help" with no additional parameters.
TOPIC sxdwm
`sxdwm connect|menu <name>|disconnect|dump-dynamic-menus|reset|status`
Controls the Exhibition display manager. This is responsible for managing all of the system's menus.
TOPIC chorus
`chorus [on|off|toggle]`
Controls whether the chorus feature is enabled. Chorus allows operators and other units to anonymously relay messages through the system for dramatic effect or public announcements.
TOPIC drainprotect
`drainprotect [on|off|toggle]`
Controls whether or not remote control messages (over the unit's public and private data buses) and ACS-based chargers may drain power.
TOPIC access
`access local|remote [on|off|users|group|cycle]`
Determines which users can access the system using each modality:
`local`: console menu (touch) access, `/1 <prefix>` local command access, light bus devices, navigation nodes, and RLV relay devices.
`remote`: access through a remote control or another device that uses the command bus.
`on`: enabled for everyone; unrecognized users will be prompted if consent is enabled (see "help guests")
`off`: disabled for everyone but owners
`users`: enabled for all registered users (see "help users")
`group`: as users, but members of the unit's active group will be treated as level 0 users
`access self [on|off|toggle]`
Controls whether or not the unit can access itself. This setting takes effect immediately. The "safeword" command can be used to cancel it.
TOPIC authority
`authority <organization name>`
`authority NONE`
Sets or clears the name of the authority that has control over the unit. This information is displayed by the "about" command, as well as by certain accessories, such as the SuperBit titler.
The authority is overridden upon entry into a domain. See "help domain" for more information on domains.
TOPIC domain
`domain`
Lists information about the unit's current domain.
`domain search`
Searches for domains in the current region.
`domain join|set <name>`
Joins the domain specified if able. If the domain server does not have a role configured for the unit, then the unit will join the `candidate` role. Note that the candidate role is not always publicly accessible.
You must be in the domain's home region to join it, and have previously located it by using `domain search`.
Upon joining a domain, a synchronization will automatically be performed (see below.)
Only managers and owners may join a domain.
`domain clear|leave`
Leaves the current domain. The command will take effect immediately on the unit. The OS stores a list of domains you have left but not yet notified; you must visit the domain's home region to officially leave it.
Only managers and owners may remove a unit from a domain.
`domain sync`
Performs an immediate synchronization with the domain server. The unit must be in the same region as the server. Synchronization executes the server's policy file for the unit's role and updates its user table.
If the server is working correctly, it will push updates to the unit when they are available, and manual synchronization should not be necessary.
See [http://support.nanite-systems.com/?id=1276 documentation for the hierarchy/XNMS domain server] for more information on what domains can do and how to set one up.
TOPIC name
`name <unit name>`
`name NONE`
Sets or clears the unit's nominal designator. Must be valid [https://en.wikipedia.org/wiki/ASCII#Printable_characters ASCII]. If the unit has no name, then the system will default to displaying the serial number instead.
TOPIC keychain
`keychain [list]`
`keychain reset`
`keychain save|load|dump`
`keychain rewrite <value>`
`keychain remove|promote|demote|add|submit <user key>`
Controls the system's access control list, i.e. the list of users who are authorized to use the unit and their corresponding security clearances.
`list` (or no arguments): lists the current users and their ranks.
`reset`: clears the user list, including permanent storage, and puts the unit under self-ownership. This can be performed by the unit or by any owner, and sends a notification message to all owners.
`save`: saves the keychain to permanent memory. This can be restored with "keychain load" or by resetting the user manager (see "help reset").
`load`: loads the keychain from permanent memory, overwriting the current user list.
`dump`: reports the current saved value of the keychain in permanent memory in raw format.
`rewrite`: replaces the saved value of the keychain without reloading it. (Manufacturer use only.)
`remove`: deletes a user.
`add`: adds a user.
`promote`: raises a user's security clearance by 1 level.
`demote`: lowers a user's security clearance by 1 level.
`submit`: makes a user the unit's sole owner (level 2 clearance). The submit command can only be used by a self-owned unit with no other owners.
Level 1 (manager) access or above is required for: `save`, `load`, `dump`, `rewrite`, `add`.
Equal rank is required for: promote, demote, remove. For example, managers may promote users to manager rank, or demote managers down to user rank. Users may always remove themselves.
See "help users" for an explanation of user ranks.
The keychain command is completely disabled if the domain has locked the unit's user list. It must be left before the user list command can be used again, which can only be done by a manager or owner. See "help domain" for more information.
TOPIC autolock
`autolock on|off|toggle`
`autolock time <secs>`
When enabled, the console will automatically lock after a specified period of inactivity. The default time is 30 seconds. See "help lock". When autolock is enabled, the safety bolts are also locked while the unit is powered down.
See "help bolts" for more information on safety bolts.
TOPIC pin
`pin <pin>`
Sets the PIN used for unlocking the console. The PIN must be a series of numeric digits. It is empty by default. See "help lock".
TOPIC gender
`gender [physical|mental|voice] inanimate|female|male|neutral|<custom>`
`physical`: The pronouns used to describe the unit in actions.
`mental`: The pronouns used to describe the unit when it speaks about itself.
`voice`: The timbre to use in tone markers, i.e. the sounds that accompany speech.
Note that voice gender is separate from the voice used for system messages such as low battery warnings. See "help schemes". For many controllers and personas, the neutral voice gender is configured to produce beeping sounds instead of vocalizations.
There are four pronoun presets (`feminine`, `masculine`, `neutral` (they), and `inanimate` (it)), and custom pronouns can be specified independently for physical or mental requirements.
For custom pronouns, enter a string that satisfies the following template:
`absolute possessive,possessive,subject,object,reflective,name`
(With no spaces around the commas.) For example, to recreate the values for the neutral gender, one would enter:
`theirs,their,they,them,themself,neutral`
These values are then available for use by personas and Arabesque scripts, as described in "help personas".
TOPIC xanadu
`xanadu list|servers|search|disconnect|refresh`
`xanadu connect <server>`
`xanadu install|info|upgrade|remove|cache|uncache|unpack <package>`
Manages installed packages.
`search`: polls for available Xanadu package servers. Performed automatically on region change.
`servers`: lists available servers.
`connect`: connects to the server <server>.
`disconnect`: disconnects from the current server.
`list`: lists installed and cached packages. If connected, combines this list with a list of packages on the server.
`install`: requests `<package>` from the server and attempts to install it.
`info`: gives info notecard (readme file) for `<package>`. This works for any package listed by "xanadu list".
`upgrade`: installs `<package>` from the server. This guarantees the current version of `<package>` is removed first.
`remove`: removes `<package>` from the unit. A server connection is not required.
`cache`: saves `<package>` to the cache so it can be installed later.
`uncache`: removes `<package>` from the cache.
`unpack`: installs `<package>` from the cache.
`refresh`: looks for packages currently installed or in the cache. This updates the local packages shown by "xanadu list".
Exact names (including versions) are required for installing, upgrading, and removing.
TOPIC audience
`audience on|off|toggle`
Controls Audience piped audio. Analogous to the Vox pipeline (see "help vox"), Audience captures incoming chat messages on channel 0 for modification. This feature is not yet complete, and so no modifications are yet supported.
TOPIC optics
`optics apply`
`optics default|<preset>`
Sets a video filter using the specified Windlight preset. The special filter "default" disables the filter. "apply" re-applies the current settings.
TOPIC navigate
`navigate start [<name>]`
`navigate auto`
`navigate speed <rate>`
Controls navigation routing.
`speed`: sets speed of travel between nodes to `<rate>` meters per second. The default value for `<rate>` is 5.0.
`start`: manually start navigation at the last encountered node (or at `<name>` if specified; 96 m search range)
`auto`: toggle automatic starting of navigation.
TOPIC sentinel
`sentinel`
Reports the system information as tracked by ATOS/E. For more information, see [http://support.nanite-systems.com/?id=280 the online manual].
`sentinel inflict heat|combat|crash|external <amount>`
Inflicts <amount> damage through the indicated method.
`sentinel repair on|off|toggle`
Toggles nanite auto-repair. Note that self-repair cannot fully heal the unit.
`sentinel autoshield on|off|toggle`
Toggles automatic shield activation. This is triggered whenever the unit collides with a fast-moving object, regardless of its own velocity. A compatible active barrier device, such as the MESH-2100 is required. (This does not include the MSH-2100b.)
TOPIC lust
`lust`
Reports the status of the lubricant and arousal monitoring systems. TESI is required. See also "haptic".
`lust moan`
Emits a single randomly-selected voice sample indicating arousal.
`lust leak <source> <rate>`
Emits fluid particles from nozzle `<source>` (see "lust parts", below) at the specified rate `<rate>`.
`lust parts`
Lists supported parts and current nozzle dilation levels.
`lust plateau <level>`
Prevents arousal from falling below `<level>`, on a floating point scale (0.0 to 1.0).
`lust deposit <amount> <type> <red> <green> <blue>`
Adds `<amount>` liters of fluid type `<type>` with color `<red>` `<green>` `<blue>` to the system. Any type other than `lubricant` will be treated as a contaminant. Normal fluid volume is 5 L.
Color should be in floating-point format, e.g. `1 0.5 0` for orange.
`lust font [refresh|probe|<name>]`
Lists or selects a voice font. Use `lust moan` to test, and `lust font refresh` or `lust font probe` to update the list of available voice fonts.
`lust nozzle <name> enable|disable|orgasm`
Controls whether the specified nozzle will leak or not. If the option `orgasm` is provided, additional fluid will be added during orgasm. `disable` removes a nozzle from both lists.
`lust arousal build|decay|verbal|physical|set|plateau <amount>`
Sets one of the arousal metrics to `<amount>` (0.0 to 1.0 unless otherwise specified):
`build` (default 0.1): The base rate at which arousal is built per second during stimulation.
`decay` (default 0.01): The base rate at which arousal decays per second after stimulation is removed and the natural plateau period has ended.
`verbal` (default 0.2): The coefficient used for stimulation from "audience"-based keyword sources (unimplemented).
`physical` (default 0.125): The coefficient used for stimulation from physical (e.g. Epidermal touch) sources.
`set`: Overrides the unit's current arousal level immediately.
`plateau` (0.5 to 2^30): Sets the duration of the natural plateau (the number of seconds that TESI should wait before decay begins)
Note that `lust arousal plateau` is not the same as `lust plateau` (see above).
`lust climax trigger [dry]`
Immediately induces an orgasm. The unit must have a non-zero amount of arousal (try `lust arousal set` or `lust plateau`) and be above the minimum arousal threshold.
If `dry` is specified, no lubricant is spent.
`lust climax deviation|mean|threshold|power <amount>`
Sets the metrics for the unit's orgasms:
The base orgasm intensity is a Gaussian-distributed floating-point number generated using the `deviation` and `mean` parameters.
The amount of arousal removed is determined by multiplying the orgasm intensity by the `power` coefficient.
The unit may only orgasm if its arousal is at least `threshold` and also non-zero.
The default values for climax deviation, mean, threshold, and power are 0.4, 1.0, 0.6, and 2.5, respectively.
`lust sensitivity base|build|decay|default|<surface> <amount>`
Configures the sensitivity metrics:
`base` (0.0 to 1.0, default 0.25): the sensitivity value that the unit should settle on if it has not been stimulated for a long time.
`build` (any float, default 0.03): the rate at which sensitivity changes when the unit is being aroused; may be positive or negative.
`decay` (any float, default -0.01): the rate at which sensitivity changes when the unit is no longer being aroused; may be positive or negative.
Set these constants intelligently: if you use a positive `build` value, then you should use a negative `decay` value, and vice-versa; otherwise, sensitivity may climb or fall infinitely. Likewise, the `base` value should be low if `build` is positive, and high if `build` is negative.
To ignore sensitivity entirely, set `base`, `build`, and `decay` to 1.0, 0.0, and 0.0, respectively.
`<surface>` (any non-negative float): the coefficient applied to stimulation on a given surface
`default` (any non-negative float): the coefficient used as a fallback for surfaces not individually configured.
A surface coefficient e.g. of 2 causes 1.0 seconds of touch to be treated as 2.0 seconds. In general, highly sensitive erogenous zones such as the glans or clitoris should have a higher coefficient than other surfaces.
For a list of surfaces and their default sensitivities, see [http://develop.nanite-systems.com/?id=1924 TESI protocol documentation].
In summary, an instance of physical stimulation causes arousal to be added according to the following formula:
arousal amount = duration × physical coefficient × current sensitivity × surface coefficient
TOPIC haptic
`haptic`
Support utility for TESI. See also "lust".
`haptic rescan`
Re-scans #RLV/~NS/fluid/ for fluid stages.
`haptic anim [debug]`
Controls animation indexing. `debug` toggles logging of animation starts and stops. If no parameter is specified, lists the tracked animations.
`haptic anim add <UUID> <rate>`
Builds arousal at `<rate>` when animation `<UUID>` is playing. If `<UUID>` already has an arousal rate configured, this will be updated.
`haptic anim remove <UUID>`
Removes arousal building for animation `<UUID>`. Fails silently if animation is not configured to build arousal.
TOPIC module
`module`
Lists supported system modules and their running states.
`module probe`
Checks for available modules and resets libraries. Recommended method for recovering from crashes and clearing stuck tasks.
`module reset <name>`
Resets the indicated module. See also "help reset".
`module info <name>`
Reports detailed information about the specified module. The exact name (including leading underscore, for system modules) is required.
TOPIC task
`task`
Lists the currently running tasks and threads and their modules of origin.
`task flush`
Discards currently running tasks. This does not automatically suspend libraries; try "module probe" afterwards. See "help module".
TOPIC halt
`halt`
Powers down the system immediately. See "help shutdown" for more options.
TOPIC off
`off`
Powers down the system immediately. See "help shutdown" for more options.
TOPIC reboot
`reboot`
Reboots the system immediately. See "help shutdown" for more options.
TOPIC preload
`preload <sound>`
Prepares the sound file `<sound>` for playback. This command causes the Arabesque script processor to sleep for 1 second after use.
TOPIC sound
`sound <key>`
Plays a sound file over the audio output processor. The sound must either be located in the processor, or specified by UUID.
To control the unit's audio output settings, see "help volume" and "help scheme".
sound vox <name>
Plays a system voice message over the audio output processor. Possibilities are:
- `battery-0`
- `battery-5`
- `battery-10`
- `battery-20`
- `battery-50`
- `teleport-complete`
- `operation-complete`
- `access-1`
- `access-0`
- `lock-0`
- `lock-1`
- `power-1`
- `power-0`
- `power-profile`
- `module-1`
- `module-0`
- `module-reset`
- `love-1`
- `love-2`
- `love-3`
- `love-4`
- `greet`
- `greet-2`
- `charge-1`
- `charge-0`
- `bye`
- `personality-0`
- `personality-1`
- `error`
- `error-charge`
- `error-critical`
- `error-device`
- `diagnostics-1`
- `diagnostics-0`
- `device-1`
- `device-0`
- `notice`
- `subsystem-1`
- `subsystem-0`
- `volume-100`
- `volume-20`
- `volume-10`
- `volume-0`
- `motors-0`
- `motors-1`
- `motors-2`
- `connect-1`
- `connect-0`
TOPIC trigger
`trigger [<event name>]`
Runs a script with Arabesque identified as being an event script. Unlike normal Arabesque scripts (see "help do"), these scripts start with the `e_` prefix. No message is emitted if the script is not found.
Event scripts are activated automatically by the system during certain events, such as when the system boots or shuts down. As of Companion 8.4, the following events are supported:
`e_charge-start`: Called when charging begins.
`e_charge-end`: Called when charging ends.
`e_boot`: Called on system boot.
`e_shutdown`: Called on system shutdown.
`e_teleport`: Called on teleport or region crossing. Sets `$region`.
Personas also have special initialization scripts, called `px_` scripts. See "help personas" for more information.
TOPIC charge
`charge <command>`
Sends a command to the charger, if connected. Supported commands vary per charger. Type "charger help" while connected for a list of supported actions.
TOPIC leash
`leash`
Causes the unit to follow you.
TOPIC unleash
`unleash`
Causes the unit to cease following you.
TOPIC open
`open [<app name>]`
Opens a program from the applications menu. If no name is specified, a list is provided.
TOPIC range
`range <distance>`
Sets the distance at which the unit is to follow you, measured in meters. By default, `<distance>` is 5. See "help follow" for more information.
TOPIC reset
`reset <module>`
Restarts the indicated system module. Ownership may be required to restart some critical modules, such as the user manager and bootloader.
TOPIC safeword
`safeword`
This command is only usable by the unit. After notifying the unit's owner(s), it grants basic self-access to the unit. To fully regain autonomy, it is typically necessary to type "keychain reset" afterward.
TOPIC send
`send <range> <channel> <message>`
Sends `<message>` on channel `<channel>` to all objects within `<range>` meters. If `<range>` is 0, sends `<message>` to the unit's attachments. If `<range>` is `region`, sends to everything in the region.
The special keyword `lights` can be used to indicate that the message should be sent over the light bus. (See "help development".)
TOPIC rlv
Synonym for the "restraint" command. See "help restraint" for more information.
TOPIC restraint
`restraint on|off|toggle|reset|auto|manual|cycle|status|debug`
`on`/`off`/`toggle`: controls the RLV relay.
`auto`/`manual`/`cycle`: controls RLV auto-accept.
`reset`: clear all user-mode restrictions. (Does not affect system restrictions or enable subsystems.)
`status`: list active restraints
`debug`: toggle debug messages
TOPIC domain
`domain set <domain>`
`domain search`
`domain clear`
`domain sync`
Controls domain membership. A domain is a central server that defines the unit's users, policies, and other settings.
Upon joining a domain with the 'set' command, the unit will automatically be assigned a role and immediately download user and configuration settings. By default, this role is 'candidate'.
Depending on the domain's configuration, membership in a group may be required to join.
TOPIC guests
`guests whitelist|blacklist [<key>]`
`guests unwhitelist|unblacklist <key>`
`guests tidy white|black`
`guests default accept|deny|toggle`
`guests consent on|off|toggle`
`guests consent timeout <seconds>`
Allows the unit to control access by unauthenticated users (hereafter called 'guests'.) To return to behavior from 8.3 and earlier versions, set "guests default accept" and "guests consent off".
There are four lists: trusted, permitted, banned, and refused. The first two are whitelists, the last two are blacklists. The 'permitted' and 'refused' lists differ from 'trusted' and 'banned' only in that their entries are temporary.
Whitelisted guests may access the system as long as "access" is set to public for their interaction modality (see "help access").
`whitelist`: lists all whitelisted guests.
`whitelist <key>`: adds a user to the trusted list.
`unwhitelist <key>`: removes a user from both whitelists.
`blacklist`: lists all blacklisted guests.
`blacklist <key>`: adds a user to the banned list.
`unblacklist <key>`: removes a user from both blacklists.
Temporary list entries (permitted and refused) will time out after a certain period of inactivity. The default is ten minutes.
`tidy`: empties the temporary (permitted and refused) lists.
`default`: controls what happens if the unit fails to respond to the confirmation prompt within the consent timeout; accept adds the user to the permitted list (whitelisted for 10 minutes), and deny adds to the refused list (blacklisted for 10 minutes).
`consent`: if enabled, the unit is prompted to decide what to do whenever a new guest attempts to access the system. If disabled, the default action (see above) automatically occurs.
The default consent timeout is 10 seconds; this can be adjusted with the `guests consent timeout` subcommand.
TOPIC aux
`aux GPS|audio|radio|video on|off|toggle`
Configures auxiliary power. This provides power to some subsystems for a limited time while the unit is powered down.
The subsystems that can be controlled are `GPS` (view location), `audio` (hearing), `radio` (receive/transmit IMs), and `video` (vision). Some motor functionality (self-touching) is always allowed when auxiliary power is enabled.
If auxiliary power is completely disabled, the unit will not be able to do any of the above when powered down.
Auxiliary power, as the name implies, draws power from a secondary source, called the auxiliary capacitor. Subsystems continue to draw power at their normal rate from the capacitor, and when it is depleted, the unit is totally inactivated.
The auxiliary capacitor is recharged whenever the unit is powered on by drawing power from the main battery. Type "aux" without any arguments to see its status.
TOPIC beacon
`beacon fire|test|on|off|toggle|interval <minutes>|message <message>`
Configures the distress beacon for contacting the unit's owners and managers when the unit is out of power. Normally, the beacon triggers on a repeating interval.
Firing the beacon will cause it to send the configured message to the unit's owners. A test fire adds extra text to the end of this message indicating that there is no crisis.
If `GPS` is on auxiliary power when the beacon is fired, the unit's position will also be included in the distress signal.
Firing the beacon while the unit is powered down drains the auxiliary capacitor. See "help aux" for more information.
`@beacon fire` can be used even when the unit does not have self-access or is powered off.
TOPIC tutorial
`tutorial on|off|toggle`
`tutorial forward on|off|toggle`
`tutorial cycle`
Controls the hints system. When forwarding is enabled, messages are displayed through the Screen Console Manager HUD (_console-screen). When it is disabled, messages are shown in chat. `cycle` switches between the three possibilities (off, chat, HUD).
TOPIC policy
`policy subsystems|persona|apparel|vox|curfew on|off|toggle`
`policy radio open|users|owner|cycle`
Controls enforcement of the specified policy. The following are the effects of the indicated policies, when turned on:
`subsystems`: prevents adjustment of subsystem (power) settings.
`persona`: prevents adjustment of persona settings.
`apparel`: prevents adjustment of apparel on the unit.
`vox`: prevents adjustment of the speech pipeline.
`curfew`: forces the unit to teleport home at a specified time (see below)
`radio`: limits radio communications to users or owners only.
The keywords `lock` and `unlock` may be used in place of `on` and `off`.
`policy curfew time <hh>:<nn>`
Forces the unit to teleport home at `<hh>`:`<nn>`. Time must be specified in 24-hour format, SLT.
`policy home here`
`policy home set <sim> <x> <y> <z>`
Sets the home location. The unit will teleport to this location at the curfew time if curfew is enabled.
TOPIC conf
`conf`
`conf <key>`
`conf <key> := <value>`
`conf delete <key>`
Accesses or updates the key/value configuration data store. Note that `delete` is recursive.
`conf dump`
Exports the contents of the current configuration in a mostly machine-readable, compact format.
`conf backup`
Writes the current configuration to LinksetData (LSD), which is a permanent attribute of the controller and will survive OS updates.
`conf restore`
Reloads the configuration store from LinksetData (LSD), which is a permanent attribute of the controller and will survive OS updates.
Hives that did not exist when `conf backup` will not be affected by `conf restore`, but any other hives will be completely replaced. For maximum sanitation, run `reset balance` before `conf restore`.
TOPIC boot
`boot`
Engages normal power and initiates the start up sequence. This can only be issued by the cortex for self-booting while the unit is turned off or under auxiliary power; attempting to use it at any other time, or remotely, will fail.
"on" is a synonym of this command.
Note that this is the only way for a unit to turn itself on when auxiliary power is depleted.
TOPIC on
`on`
See "boot".
TOPIC warp
`warp <x> <y> <z>`
`warp <sim> <x> <y> <z>`
`warp <landmark>`
`warp save <landmark>`
`warp delete <landmark>`
`warp list`
Teleports the unit to the specified destination, or saves/deletes the indicated landmark. Does not work if the unit is charging or powered off.
`warp list` will provide a list of all saved landmarks.
If no sim name is provided, then the coordinates are interpreted as being local to the current sim.
"jump" is a synonym of this command.
TOPIC jump
`jump`
See "warp".
TOPIC disk
`disk ddt`
Toggles the memory card version of the debugger.
TOPIC persist
`persist on|off|toggle`
Enables, disables, or toggles script persistence.
Script persistence causes the controller's system memory to remain active while in no-script areas. This solves issues pertaining to speech and teleporting, but is not compatible with speech filters.
Disabling script persistence will allow standard AOs to correctly detect when the robot is turning or backpedaling.
The chassis specification unit's AO implements turning through a fallback method that still works when script persistence is enabled.
TOPIC kinematics
`kinematics`
This is a device command. It is provided by the 'chassis' device, better known as the OC EXB-8505 Chassis Specification Unit (CSU).
This command controls the integrated animation overrider (AO). Documentation for the CSU's main functionality can be found [http://support.nanite-systems.com/?id=1192 online].
The `kinematics` command was added in CSU version 8.5.7. It is not present on the 8.4 version of the CSU.
If this command is reported as 'unregistered', run `device probe` to re-register attached active peripherals, then check the output from "device" to ensure that both the `chassis` device and the `kinematics` device command are present.
`kinematics <profile>`
Loads the specified profile notecard. Profiles should be named `ao_<profile>` and placed inside the CSU's root prim along with all necessary animations.
Notecards are accepted in the Oracul, ZHAO-II, and Vista (AKEYO) formats.
In addition to the standard AO directives, the CSU recognizes the special state [Menu Access], which plays an animation while the controller's holographic projector is active.
(Not recommended for use if your controller lacks a holographic projector.)
`kinematics on|off`
Controls whether or not the AO is active. Note that it will automatically be suspended via the OpenCollar AO Link protocol if the unit's motors are suspended for any reason, such as being carried or shutdown.
`kinematics sit`
Toggles whether the AO's sit animations are used.
`kinematics sitg`
Toggles whether the AO's sitg animations (ground sit) are used.
`kinematics reload`
Reloads the current AO profile; see `kinematics <profile>`, above.
TOPIC handle
`handle`
This is a device command for controlling devices using NS Handles Firmware.
Note: The name of this command may differ from the examples shown. It matches the connection address of the handle, which can be determined by invoking "device".
"device" should also list available device commands. If it fails to list items you expect to be present, run `device probe` and check again.
The most command handle command names are `handles` and `horns`, but third parties can provide arbitrary connection addresses as long as they do not contain spaces. More creative vendors might put Handles Firmware into `ears`, `tail`, `hair`, or even `right_nipple`.
`handle dress [add <folder>|remove <folder>]`
Opens the dresser interface. If `add` or `remove` is specified, adds/removes the specified folder under the root path.
`handle carry|yank`
Picks up the unit if possible. Yanking is more interesting.
`handle pose <animation>`
Starts a pose.
`handle use <use_name>`
Starts a use (multi-avatar pose with poseballs).
`handle unpose`
Releases the unit from poses (not uses, seats, or carrying).
`handle seat <chair>`
Seats the unit on a chair with `<chair>` as its UUID (name support coming soon).
`handle stand`
Stands the unit up and releases it from poses.
`handle release`
As `handle stand`, but also de-rezzes poseballs created by `handle use`.
TOPIC handles
See "handle".
TOPIC horns
See "handle".
TOPIC sign
`sign cancel|<sequence>|<image>`
Controls the holographic sign on the SuperBit and Qubit devices. `cancel` disables the sequence, whereas providing any other string will attempt to load an image or sequence by that name.
A sequence is a series of images with the suffixes _1, _2, _3, etc. The sign will automatically cycle through them in order.
This is a device command and is only available when the appropriate devices are installed.
The command "device" should list all available devices and their commands. If it fails to list items you expect to be present, run `device probe` and check again.
TOPIC mood
`mood <text>`
Sets the mood for the titler on the SuperBit or Qubit devices.
The command "device" should list all available devices and their commands. If it fails to list items you expect to be present, run `device probe` and check again.
`mood template <text>`
Qubit only: sets the mood template. See [http://support.nanite-systems.com/?id=2715 online documentation] for supported substitution variables.
TOPIC icon
`icon yes|no|victory|defeat|love|question|jeep`
Triggers an emotion from a Nanite Systems Chromatic Communicator or compatible device. Icons supporting this feature are not yet widely available.
The command "device" should list all available devices and their commands. If it fails to list items you expect to be present, run `device probe` and check again.
TOPIC matrix
`matrix`
Controls the TESI Matrix device.
The command "device" should list all available devices and their commands. If it fails to list items you expect to be present, run `device probe` and check again.
`matrix animation <name> <z-offset> <preduration> <postduration>`
Adds or updates an animation preset to use the specified z-offset (in metres), preduration, and postduration values.
Contrary to the syntax recognized by most system commands, the name may contain spaces if it is enclosed in double quotation marks.
`matrix cargo <name> give|<z-offset> <cost>`
Adds or updates a cargo item to use the specified z-offset (in metres) and lubricant cost (in litres).
When the capsule is touched, the item will be rezzed with its center at the indicated z-offset from the floor.
If the special value `give` is provided as a z-offset, the item will be transfered directly to the recipient's inventory instead if possible.
Contrary to the syntax recognized by most system commands, the name may contain spaces if it is enclosed in double quotation marks.
`matrix start <cargo>`
Queues up the specified cargo item for production.
`matrix stop`
Cancels the first item in the production queue and refunds the lubricant used so far.
TOPIC !greet
See "help bangs".
TOPIC !greet2
See "help bangs".
TOPIC !love
See "help bangs".
TOPIC !love2
See "help bangs".
TOPIC !love3
See "help bangs".
TOPIC !love4
See "help bangs".
TOPIC !bye
See "help bangs".
TOPIC !broken
See "help bangs".
TOPIC !fixed
See "help bangs".
TOPIC !working
See "help bangs".
TOPIC !done
See "help bangs".
TOPIC !fan
See "help bangs".
TOPIC !spark
See "help bangs".
TOPIC !fault
See "help bangs".
TOPIC !release
See "help bangs".
TOPIC !lamp
See "help bangs".
TOPIC !repair
See "help bangs".
TOPIC !repaired
See "help bangs".
TOPIC !light
See "help bangs".
TOPIC !
See "help bangs".