Broadly speaking, a device is any object that interacts with ARES using one of the standard protocols that the operating system understands. Dozens if not hundreds of different types of devices exist, including many functionally identical items with purely visual differences.

Certain devices, called active light bus devices, can be managed through the devices... menu, or equivalently with the @device command. This provides the following functions:

commandmenueffect
@devicedevices...List all active, connected light bus devices.
@device <address> peek <user>devices... › address › statusInstructs the device to report its current status to you.
@device <address> poke <user>devices... › address › accessInstructs the device to present its user interface to you.
@device <address> restartdevices... › address › restartSends a probe message to the device. (Useful for re-seating batteries.)
@device <address> ejectdevices... › address › ejectSends a removal message to the device.
@device proben/aRe-check for available light bus devices and make sure they are connected properly.
@device <address>n/aSummarize what the OS knows about the specified device.

In the command examples above, <user> is the UUID of the user in question. If your command is routed through the _exec shell, you may substitute $user to send the response to yourself (the person activating the command) or $self to send the response to the unit.

Note that not all devices will show up in the menu:

  • Devices that do not send any commands to the OS, such as eyes, ornamental lights, and charging seats have no reason to register with the system and function entirely by using passive messages and queries that generate passive messages.
  • Certain pieces of equipment, such as charging platforms, operate using totally different protocols, for historical and compatibility reasons. These are summarized in the device protocols section, below.

External and foreign devices

A light bus device is called external if it is not attached to your body. It may additionally be called foreign if it is owned by someone else. For example, a diagnostic bed, remote control, or display booth requires use of the active light bus protocol, and will present as an external device.

Most devices will generate access consent prompts when they attempt to connect to you, and they may (in some cases) appear to be coming from the owner of the device rather than the device itself. ARES will do its best to perform "sanity checks" on improbable commands generated by devices, such as guest access attempts made by someone who is not in the same region as you.

Device commands

Active devices can add new commands to the operating system to facilitate their use. These are usually documented within the device's user manuals. To see a list of available device commands, type:

@db input.device-command

This will produce a JSON list of raw command names. For example, if the response to this command is

input.device-command ["icon","horns","kinematics","sign","mood"]

...then the commands @icon, @horns, @kinematics, @sign, and @mood are available.

Help with specific devices

Documentation for other NS products is beyond the scope of the ARES manual. The following resources may be useful:

For anything not covered by the above, please contact the Nanite Systems User Group, or the company directly in-world.

Not every product sold by NS is compatible with ARES. In particular, the Chassis Specification Unit, VectorLogix diagnostic bed, and Arachne X8 diagnostic bed are still being reworked. Please review the device compatibility page for purchasing advice.

Device protocols

ARES communicates with objects using the following transmission formats:

ProtocolChannelSupported FunctionsDocumentation
NS Light Bus(varies based on UUID)general communication with attachmentsin ARES SDK
NS Public Bus-9999999remote controldevelop.ns/public
ATOS Arena-9990009combat hintsnot yet available
NS Meteorological Service-78838783local weathersupport.ns/meteorology
Alteran Stargate Hint Service-900000FTL telemetryunpublished
Open Robot Interface (ORIX)-15180925
-15180924
ping onlydedicated wiki
Autonomy Control Systems (ACS)360charging
interference
develop.ns/resources/ACS-charging.pdf
NS Capabilities411directory servicedevelop.ns/CAPS
RLV Relay System
(requires app)
-1812221819broker for RLV commandsat wiki.secondlife.com
PHASE/PATH1608011905file accessdevelop.ns/PHASE and develop.ns/PATH
ARES Xanadu Software Serviceconfidentialpackage managementconfidential
ARES Xanadu Package Archive Systemconfidentialpackage managementconfidential
ARES Navigation Service (ANAV)confidentialpathfinding assistanceconfidential
TESI Lust Channel
(requires Sexuality)
-9999969arousal manipulationat develop.ns
TESI Lust Effects Channel
(requires Sexuality)
-1010101particles and soundsat develop.ns

Of these, the most important by far are the light bus and ACS protocols, which are used for most device interactions; nearly all devices you will interact with use the light bus, with the exception of chargers, which generally operate using the ACS or public bus systems. As a consequence, "device" is often used as shorthand simply to refer to light bus devices, and this is the case within the ARES user interface.

Elaborating on technical specifics beyond the above is out of scope for this article; visit develop.ns if you are interested in creating your own ARES-compatible hardware or software products.