Looking for the Companion support site? Click here.
Having trouble accessing your brand-new ARES system? Read this.

Nanite Systems is currently working on a new operating system for robot controllers in Second Life, called ARES (Advanced Research Encapsulation System). ARES is a near-complete rewrite and replacement for the Companion operating system (formerly known as the SXD System Firmware) which we introduced in 2014. Thanks to the use of new technologies and script communication strategies, ARES is able to offer vastly improved performance, efficiency, usability, and customization options over all versions of Companion.

ARES Beta 1 (0.3.1) is now available. Click here for updating instructions.

What's in ARES?

ARES brings back nearly every Companion feature, from big things like personas and chat filtering to small details like the GPS subsystem and PIN locking. If not mentioned on this page, it's probably still available. That said, here's what you should expect if you're upgrading:

New operating system architecture

As the "Research" in the "ARES" acronym suggests, the present operating system project began as an experiment to reimplement Companion in a new and clean way, using the concepts that had developed over the past several years of Companion development but were unsuited or ill-fitting within the existing framework. The major highlights are:

  • Hybrid IPC. Instead of receiving messages through the common link message bus, daemons and user programs each have several chat listeners. These receive messages on a unique channel and are limited to taking input from the other compartments in the system, which correspond to protection rings.
  • Microkernel architecture. The Psyche kernel is extremely light-weight compared to the prior Whip kernel, as it targets messages to recipient scripts based on process ID number (or, as a fallback, filename). The Whip kernel maintained a list of all messages in the system and then decided what should be awake in order to receive said messages.
  • Robust daemons for text handling. It is considered a faux pas for a user program to use llOwnerSay() or llRegionSayTo() in order to communicate to an avatar—instead messages are stored in a LinksetData variable using a special print() macro, and delivered by the io daemon. This abstraction makes it possible for users and developers to pass text messages on in previously unimaginable ways, including to outside of Second Life.
  • Built-in HUD interface. Although our sales model for main controllers won't be changing, nearly all of the code for ARES is contained within a HUD rather than the controller itself. This greatly increases the performance of the interface and the amount of information it can display, while also making it much easier to change main controllers (and make new ones).
  • Variable-width text-on-a-prim with Variatype. SL "blue menu" dialogs are finally dead—ARES uses a new text-rendering engine, Variatype, to display them on both controller hardware and on (most) HUDs. The same system is also used for certain key alert messages and consent prompts.
  • DONE. Programs can now report to parent tasks when they are no longer working, making it possible for complex operations to trigger events in a reliable sequence.
  • Clean development environment. ARES programs are developed using a robust macro language that provides an easy-to-understand interface for application developers whether or not they have experience with large LSL projects. Programs are written using a template that handles all the preamble necessary for a program to interface with ARES, but can be overridden at several key points to extend it further. Automatic memory management is built in to the template and can be turned on with a simple macro declaration.
  • Extensive reorganization. Elements of the OS that frequently interact with each other, like heat production and power consumption, are now kept together in one script, eliminating the need for message-passing between these components. Listeners that were previously duplicated among multiple scripts, like ATOS and the public bus, have been combined into one component.
Dead bugs
  • Data loss. The most prominent bug in Companion, data loss after teleport or relog, cannot occur in ARES because of its use of the LinksetData storage system.
  • Fragility of user permissions checks. Security checks are now performed synchronously within the program that has requested them. Consent prompts for guest access are the only time another system component needs to get involved.
  • Fragility of the menu system. The Companion menu was spread across three components, one of which hibernated when not in use, causing long waiting times. This bulk was necessary to support both SL dialog menus and loading bespoke graphics for each menu button and state. Thanks to the shift to Variatype character-based text menus, and the availability of new storage options, only one menu display script is needed per system, and these scripts are much less likely to run out of memory or encounter data corruption.
More customization
  • Full support for web folders. Although Companion could load short text files (less than 1 kb) from the web, ARES can store as many text files as you want, regardless of how the system actually uses them. This improves loading times and provides an alternative to packages for personas and schemes—just add the URL as a source, and ARES will always have the latest version of your files.
  • Granular security model. ARES still has bans, guests, consent, users, managers, and owners, just like Companion. However, the owner now has much more control over who can do what. More than 20 different configuration settings establish the required rank for performing various actions, including but not limited to adjusting vox settings, applying a new persona, sending chat messages through the unit, accessing the menus, triggering arousal (not included with base system), and automatic acceptance of teleport invitations (yanking). This same set of rules can be used to disable safewording, or to prevent anyone but the unit from changing its identity settings.
  • Soft-coded subsystem definitions. (Almost) all of the RLV restrictions that the system uses can be redefined with a database configuration file, including their power costs.
  • Many other hardcoded constants are now customizable. Nearly all HUD graphical assets can be replaced. HUD elements can be repositioned. Individual services for ORIX, weather, ACS charging, and Stargating can be toggled to protect against abuse. The shell program supports command aliases, and can be replaced by the user with a different program if needed.
  • Modularity. Companion scripts often covered many different features—for example, the "obedience" script was responsible for loading the user manual, gender settings, PIN locking, cable ports, and more. This made it virtually impossible to remove unwanted functionality. In ARES, features almost always belong to modules that fit their description, many of which can be removed if they are not relevant to the user. This means that ARES can be made into both the perfect sex-bot system and the perfect battle-bot system without requiring recompilation or different editions.
  • Open and shared source for some components. ARES comes with 4 different software licenses that allows developers to contribute to its improvement. To balance our business needs with community health, we've decided to mix software copyright and "copyleft" licenses for different components. While most of the core system remains closed source, many of the user-facing parts will be available for tinkering and in some cases even redistribution. The specifics are:
    • The SDK for ARES is under a BSD-like license. The code in the SDK can be freely reused and remixed as long as proper attribution is preserved.
    • Many of the ARES applications are under a GPL-like license. Although these will be distributed commercially with ARES, other developers will be allowed to create open-source derivative works.
    • A number of user interface components are under a proprietary "shared source" license that supports modders but maintains a full monopoly on ownership.
    You can read more about the ARES software licenses here.
Reworked features and realized plans

Some Companion features were never finished, or had to be shelved due to architectural limitations. With ARES we've spent a lot of time reimagining how to best deliver the features you know and love, while making them better and more useful whenever possible.

  • Chat input vox chain filtering. ARES uses the same infrastructure to process chat regardless of source, although different filters can be applied to each. Censor words, automatically translate one language to another, or just turn everything into gibberish. (Please note that the language translation is still one-to-one, and is for entertainment purposes only. We do not currently have plans to provide automatic language detection or state-of-the-art accuracy, as these things are actually very expensive.)
  • Progressive interference. All forms of ACS radiation/interference support multiple power levels, but both ACS and NS units have only ever implemented one level of disruption. ARES has progressive disruption for vision and mobility, where the amount of functional impedance climbs as the level approaches infinity, but is still significant at the most common power setting of 1.0.
  • System-specific accessories. As ARES becomes available for existing main controllers, the update package will include special programs or gadgets relevant to that system's official in-lore purpose, to make the controller selection process more distinctive and rewarding. For example, the Scout will include a jump booster, and the Mesta will gain the ability to repair other nearby units with its own repair nanites. (These extras are subject to change.)
  • Integrity and heat by default. All ARES units include realistic heat simulation and the ability to become damaged—in fact, nearly all ATOS/E features are built into the system, meaning it is no longer necessary to download and install a special package for this purpose. However, damage can also be turned off by enabling "degreelessness" mode or "out-of-character" (OOC) mode. OOC mode goes a step further and also disables arousal (not included with base system), interference, and the RLV relay, to protect you from nuisances when not appropriate.
  • ARES Advanced Navigation. Although more than 300 customers purchased the powerful Navigation Route Designer for Companion, it saw little use as its best use case (animatronic tour guides) was extremely niche. The new navigation system is more like a self-driving car: the operator selects a destination, and the unit walks to that destination, without having to clutter up the world with actual node markers. A central server, called the ANav Service Host, automatically determines the best route, using a mixture of SL pathfinding and waypoints defined by the sim builder. ANav also tracks Telos pads and can be used to automate the movement of Conversant-based NPCs.
Streamlined system

Sometimes trimming the fat is necessary for the health of a project. A small number of seldom-used features have been removed from ARES, or are scheduled for addition only very late in the development cycle.

The following features have been dropped completely:

  • Charging with Refactor, UMD, and Qetesh chargers. These devices were scarce when support was added for them, and are now virtually extinct. Refactor Robotics changed their charging protocol shortly after we added compatibility to Companion, specifically to prevent interoperability, and any remaining public places with NS-compatible Refactor chargers also have ACS or NS chargers.
  • Tutorial. We hope to obviate the need for explicit hand-holding by ensuring the system is naturally informative about what it can do and what state it is in. The on-board System Information Manual is a complete reference document for all the features and functions of the OS, and there is a complete, graphical Setup program that guides the unit through the first stages of setting up ARES.
  • The private bus. In addition to sending remote commands on the public bus channel (-9999999), there was also a matching private bus, which used the negative version of the unit's nine-digit serial number. This sometimes became a nuisance if two units had the same serial number (especially if that was the placeholder value 100-00-0001). Only a few products depended on the private bus; the display booth (which is being updated) and the remote console, which has been fully replaced with an ARES version. As ARES furthermore allows for free-form serial numbers, determining a private channel reliably is somewhat impractical.
  • LaserLine. Although it was often very fascinating to watch the tiny dots over the heads of avatars with the Native Console, constantly updating these little pips was extremely resource-intensive, often taking up more simulator time than the rest of the system combined. HUD target marking has been limited to two special use cases: target lock for special heat-seeking weapons, and marking destinations during navigation.
  • Previous device and program formats. ARES is not a one-to-one replacement for Companion, but rather a successor system built to improve the experience of Companion users. As a result, no software designed for Companion will work on ARES, and most devices will need some minor modifications. In particular, please note that:
    • Arabesque scripts do not work under ARES. Although some common commands have been retained or restored through aliases, the new "_input" command-line shell has a different range of capabilities, so syntax is often quite different. For example, the old ifeq $x 1 command directive, which was an extremely limited way to check if an integer variable had a certain value, has been replaced with a full infix expressions system; the equivalent syntax is now if $x == 1 then command.
    • There is a new persona file format, the ARES .p format, which is parsed as a typical input shell script that creates the persona's data values as it runs. Once loaded, the capabilities of a persona are the same as before, but now a separate "px" script file is no longer necessary. This is both more convenient for distribution and opens up the possibility of non-deterministic personas that change every time they are loaded.
    • LSL programs compiled for Companion must be rewritten from the ground up for ARES. The API for ARES program development is much more comprehensive than Companion's application standards. A special header file included at the end of the program (a "footer," if you will) manages the entire default {} state for the developer, who is asked only to work within a special main() function. This cleanly separates the operating system's preamble from the developer's own work and abstracts the OS's architecture, eliminating a major source of confusion and fatigue for developers. Event-driven tasks like listening for chat messages, setting timers, reading notecards, and fetching text from the web are handled through API calls that trigger the main() event with an appropriate signal number.
    • Devices that deeply interact with the OS require modification. Although ARES still uses the same light bus protocol as Companion, a handful of messages have been deprecated or will no longer function as expected due to changes to the operating system. For example, the internal message, which was used to trigger OS functions that were not part of the light bus protocol, was extensively tied to the specific details of Companion's link message number table; no such thing exists in ARES. Instead these have been converted into new light bus messages where possible. Some other devices may need to adjust their power draw characteristics because of the increased realism of the heat model in ARES—fast-recharging shield devices like the Bathyscaphe will cause (and should always have caused) meltdowns. All commercially-available NS devices will be retrofit over the course of Spring 2024.
Domains and malfunctions (not yet available)

These aspects of Companion are not completely removed from ARES, but are scheduled to be implemented late in the Beta phase of development.

  • Domain support. Managing large groups of units is a concern for relatively few customers (around 220 purchases.) ARES offers alternative methods for doing this through web folders, so we have decided to prioritize other parts of re-implementing the system first. When finished, we expect that existing Hierarchy/XNMS will not need any code updates, although configuration files for ARES units will be somewhat different from Companion units since the two systems use different commands.
  • Malfunctions. NS units that get heavily damaged have a small chance of developing "malfunctions" (described here and here) that block certain system functions like enabling power or using chargers. They were originally added to facilitate the use of the VectorLogix diagnostic bed, which has since been superseded by the Arachne X8 bed, but also remains independently popular for charging and for sideloading software. Although popular with veteran users, malfunctions are extremely confusing for novices, and often mistaken for bugs. (And with the fragility of many Companion components, they were often impossible to properly fix, thereby becoming bugs.) We will be adding malfunctions only as part of the paid "Warrior" add-on, which will add other advanced combat features like a weapon switcher and damage, and in the paid "diag" add-on, which will be devoted to dealing with anomalies and (pretend) malware.
New and improved add-ons
  • WARRIOR. Customers frequently ask for a more combat-oriented experience. Up until now we haven't been able to provide that, as the Companion codebase proved unsuitable for attaining the performance necessary for enjoyable metered ATOS combat. But with a name like "ARES," the new OS surely must be better suited to combat, and we don't intend to disappoint. Warrior will include area-based damage with an on-screen body schematic, similar to how damage is displayed in the MechWarrior game series, a weapon selection interface built into the ARES HUD, and the ability to suffer malfunctions, which are not being included in the standard ARES experience. Expected arrival: February 2024.
  • SEXUALITY. Also jokingly referred to as "TESII" or "Daggerfall," this complete rewrite of the TESI Emotion arousal meter will allow the unit to select a new "interactive" mode for users more interested in poseball play with little or no typing. The previously-announced TESI Matrix accessory will be built into the lower sensor attachment. The ability to generate fluids will be built into the upper and lower sensor attachments. An engine for facial animations, and new compatibility features, will be built into a new head sensor attachment. Now available in preview form.
  • DIVE. Inspired by the iconic body-stealing telepresence technology of Ghost in the Shell, this will allow direct puppeteering of an ARES unit with normal keyboard controls, transparent chat input, and camera-following. This feature was long-planned for Companion but never released due to design problems. Expected arrival: TBA.
  • UPLINK. A subscription service rather than an add-on, this will allow owners to check on their beloved units from the myNanite website, including adjusting settings and running system commands remotely. Subscriptions will be flexible, and include options for both units and owners to allow them to operate with an unlimited number of other avatars. Our delivery date for this project is less certain as it involves setting up new payment systems. Expected arrival: TBA.

Getting ARES

The Beta 1 rollout is now in progress, which means many customers who originally bought Companion controllers will now receive ARES-based hardware when they get a redelivery. Companion will soon be fully retired. See the CONTROLLER INFO page to find out when your model is getting upgraded!


The extremely rough (and probably overly-optimistic) estimated release schedule for ARES is as follows:

  • Alpha 1 was released on July 8, 2023. To support development, the Alpha builds are only available to customers who buy a special limited edition controller, the CX/Supervisor.
  • An updated Alpha 1 (version 0.1.1) was released on July 14, 2023. This version is only available via redelivery. It is required for all future updates.
  • Alpha 1.2 (version 0.1.2) was released on August 5, 2023. This update addressed some of the outstanding minor bugs, and provided a test of the system package update process. More updates to Alpha 1 are in the works. It is available via redelivery or by following the update instructions.
  • Alpha 1.3 (version 0.1.3) was released August 19, 2023. This update was mostly a collection of bug fixes that took longer than expected.
  • Alpha 1.4 (version 0.1.4) was released August 25, 2023. This update focused on improving the update process.
  • Alpha 1.5 (version 0.1.5) was released September 15, 2023. This update added support for the Bismuth Color HUD, the ARemote remote console, and debuted an alpha version of the "Restraint" RLV Relay.
  • Alpha 1.6 (version 0.1.6) was released September 30, 2023. This version continued the work of meeting the original A1 target and added the ability to password-lock system access.
  • Alpha 2.1 (version 0.2.1) was released November 19, 2023. This version addressed a number of bugs and added a new navigation system that can be used to path-find through regions with difficult terrain. The planned AMenu HUD has been dropped for accessibility reasons.
  • Alpha 2.2 (version 0.2.2) was released December 9, 2023. This version was also bug-focused and was mainly dedicated to issues with the package manager.
  • Beta 1 (version 0.3.0) was released January 16, 2024. We hope to also release a new combat-focused add-on called WARRIOR around this date, as well as the TESI replacement, Sexuality. Most controllers that were sold running Companion have been converted to ARES.
  • Beta 1 was updated to version 0.3.1 on February 20, 2024. This version addressed a range of bugs, addressed compatibility with some controller screen features, and added new functionality for manipulating JSON inside shell scripts. It also introduced an experimental optimized version of the kernel. The CX/Supervisor controller was retired around this time.
  • Beta 2 will lay groundwork for finishing Sexuality and Warrior, and improve the UI for users without 1920x1080 screens. All later plans have been bumped back to accommodate this work.
  • Later betas will add improvements as necessary to accommodate further work on device compatibility and new applications.

The exact release dates of the beta versions are guaranteed to slip as a result of feedback from the alpha development phase. For more detail on the ARES development schedule, see the ARES roadmap, which lists the outstanding tasks and how long each is estimated to take, and the ARES devlog, which tracks work on ARES and related software.

The ARES command reference page is also now available, here. This is guaranteed to always be indexed to the latest release.