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:
| command | menu | effect |
|---|---|---|
| @device | devices... | List all active, connected light bus devices. |
| @device <address> peek <user> | devices... › address › status | Instructs the device to report its current status to you. |
| @device <address> poke <user> | devices... › address › access | Instructs the device to present its user interface to you. |
| @device <address> restart | devices... › address › restart | Sends a probe message to the device. (Useful for re-seating batteries.) |
| @device <address> eject | devices... › address › eject | Sends a removal message to the device. |
| @device probe | n/a | Re-check for available light bus devices and make sure they are connected properly. |
| @device <address> | n/a | Summarize 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-commandThis 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:
- What devices are compatible with ARES?
- Collection of hardware documentation
- Liner notes included with the product itself
For anything not covered by the above, please contact the Nanite Systems User Group, or the company directly in-world.
Device protocols
ARES communicates with objects using the following transmission formats:
| Protocol | Channel | Supported Functions | Documentation |
|---|---|---|---|
| NS Light Bus | (varies based on UUID) | general communication with attachments | in ARES SDK |
| NS Public Bus | -9999999 | remote control | develop.ns/public |
| ATOS Arena | -9990009 | combat hints | not yet available |
| NS Meteorological Service | -78838783 | local weather | support.ns/meteorology |
| Alteran Stargate Hint Service | -900000 | FTL telemetry | unpublished |
| Open Robot Interface (ORIX) | -15180925 -15180924 | ping only | dedicated wiki |
| Autonomy Control Systems (ACS) | 360 | charging interference | develop.ns/resources/ACS-charging.pdf |
| NS Capabilities | 411 | directory service | develop.ns/CAPS |
| RLV Relay System (requires app) | -1812221819 | broker for RLV commands | at wiki.secondlife.com |
| PHASE/PATH | 1608011905 | file access | develop.ns/PHASE and develop.ns/PATH |
| ARES Xanadu Software Service | confidential | package management | confidential |
| ARES Xanadu Package Archive System | confidential | package management | confidential |
| ARES Navigation Service (ANAV) | confidential | pathfinding assistance | confidential |
| TESI Lust Channel (requires Sexuality) | -9999969 | arousal manipulation | at develop.ns |
| TESI Lust Effects Channel (requires Sexuality) | -1010101 | particles and sounds | at 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.