The sender is requesting to be identified to the system at address <device>, where <device> is a one-word mnemonic describing the class of peripheral or machine, e.g. icon or battery. No two connected devices may have the same address at the same time. For peripherals, the add message should be sent in response to an on_rez() or attach() event, or in response to the probe message. The controller will respond with either add-confirm or add-fail.

Variant of add. See Packaging for information on the <version> syntax used.

This syntax is used to block old, incompatible devices from being used with newer OSes, which usually do not send a <version> at all. Consequently this syntax is required for HUD and shield devices, and it has also been used to block incompatible battery devices in earlier versions.

For devices with updatable firmware, this message should be sent instead of the normal add message. The controller's package manager will recognize the device as an upgradable package, with the name format <device>_<version>. This message syntax is required for the chassis device, as the CSU syntax changed significantly during 8.5, and the EXB-8505 is firmware-update capable.

During the firmware update process, <PIN> will be passed by the package manager to the package installer in cleartext, along with the root UUID of the device. The package installer is responsible for translating this into the actual secret number. See Packaging for more information on version syntax and how to create an updatable device.

Registers a new federated system command (an @ command) with the controller. This will be available until the device is removed or the controller next probes for the device (e.g., at login.) When the command is received, the command message will be sent to the device.

Asks the controller to verify that the user <key> has local access. If the user is authorized, then the controller will respond with accept <key>. This message may take some time to process if consent is required. If the user is not authorized, then the controller will notify him or her directly, and the device will not receive any response. Devices should obtain permission for the user to act immediately upon user contact and avoid caching any commands or actions that may require authorization.

For more complex security interactions, see 205 SEC_PROGRAMMABLE_LOCAL and 210 SEC_PROGRAMMABLE_REMOTE, which may be utilized through the internal message.

See support article for relevant definitions pertaining to access types, user ranks, and consent.

Modified version of auth. Checks if <user2> is at least <user1>'s rank, and if so, sends accept to the device for <user2>. This allows decisions about whether or not <user2> has the right to pre-empt <user1>, for example when grabbing a leash.

The unit is currently being carried by the avatar <key> using the handle <device>. When carrying stops, the message will be sent with <key> = NULL_KEY. This message should be accepted from any attachment. The controller will send it in response to carrier-q.

Instructs the controller to send carrier.

Instructs the controller to send color, color-2, color-3, and color-4.

Removes values from the system settings store. See conf-get for syntax notes.

Retrieves <setting-name> from the configuration manager (_balance/SettingsService). If the setting exists, a conf message is returned. Multiple settings may be retrieved by separating their names with a linebreak, e.g.



These will be returned with a single conf message, such as:

Updates settings kept in the configuration manager (_balance/SettingsService). As with conf-get, multiple directives may be issued in a single message by separating them with linebreaks:

Instructs the controller to send a list of connected devices (using multiple device-list messages.) If installed, the ATOS security enhancements module will also send the weapon-active message to the destination key, which is normally only sent to the HUD.

Sends the follow message.

Queries the controller's current gender settings. <topic> must be one of physical, mental, or voice. Sends gender in response; see that entry for recommended usage of each gender topic.

Relay a linked message through the controller, i.e., trigger an internal system function. The set of supported linked messages can be found here. To send a system command (such as those listed here), use a <number> value of 0 and the <key> of the user interacting with the device, or the unit's own key (from llGetOwner()) if no such user applies. Most system commands will accept NULL_KEY as a root user.

For example, to turn off the unit, try: internal <device> 0 00000000-0000-0000-0000-000000000000 off

This command is guaranteed to not work unless the device has first authenticated with add.

In Companion 8.5 and later, all internal calls are wrapped as TASK_START messages (see best practices for 8.5 application development) to ensure backward compatibility.

The device <device> is currently using <W> watts of power to perform the task named <task>. Loads must be uniquely named, so re-sending a message with the same task name will update the usage for that device/task combination. When the task is completed, send this message with a wattage of 0 to remove the load; loads are also removed when the device is detached.

Task names should be a single word reflecting the reason why the device needs the power, for example load shield recharge 100. These burdens are shown by the power system command, under the section 'external loads.'

Instructs the controller to send persona.

When this message is produced by a device instead of the controller, it signals that the prim <key> can provide port functionality of the type <type>. This means that it should be used as a particle target for wires emitted by base stations. Port types supported by Nanoconnectivity 1.6:

class
power
audio-in
audio-out
data-1
data-2

Note that if the controller sends this message, it instead indicates a redirect to another device; see port-real and the entries above it.

For use by external devices, such as a charging station or other appliance. The sender wishes to connect a cable to a port of the indicated type (see port). The controller will respond with one of two messages:

1. If it responds with port <type> <key>, then the accessor should re-send the port-connect query to <key>, which is the actual port host responsible for managing connections. This occurs most often if the host can handle many simultaneous connections of the same type.
   
2. If it responds with port-real <type> <key>, then the accessor should accept the key provided as the particle destination and begin effects as appropriate.

If the request needs to be forwarded to a port host (the first case), then the host is guaranteed to provide a port-real message.

The port of indicated type is no longer in use; see port and port-connect for an explanation of how ports work. The attaching device (i.e., the one that sent port-connect in the first place) must still stop sending particles. Unlike port-connect, the controller is guaranteed to forward this properly to the port host.

Instructs the controller to send on or off as appropriate. It will also send bolts.

Removes the device from the device manager. Most peripherals do not need to do this, but it is appropriate for foreign devices (e.g. docking stations) to do so. Standard batteries also send this message when ejected. As with many active messages, the <device> name must be registered to the UUID sending the message.

Checks if <subsystem> is enabled, and reports back to the device with the subsystem message. See table at subsystem for parameter format. Note: before Companion 8.5m3, the parameter was ignored, so this command could only return the unit's video (0) status.

The device supports Xanadu-assisted firmware updates. It is currently running the <version> release of its code, and can be updated with a package using the PIN provided. Updater packages and device firmware should both apply salt to the PIN in some manner, and send only the portion of the PIN that excludes the salt.

See combat protocols.