Nanite Systems is currently working on a new operating system for robot controllers in Second Life, called ARES (Advanced Research Encapsulation System). We expect it to be ready for general use some time in late 2023. 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.

Features

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 are some things to look forward to:

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 they 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 and completed features

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.

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: September 2023.
• SEXUALITY. Also jokingly referred to as "TESII" or "Daggerfall," this complete rewrite of the TESI 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. Expected arrival: August 2023.
• 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: September/October 2023.
• 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.

Limitations

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.

Dropped features:

• 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 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; most prominently the remote console, which already needs to be fully replaced to support the new ARES menu format. As ARES furthermore allows for free-form serial numbers, determining a private channel reliably is somewhat impractical.
• The navigation routing system. This is being redesigned rather than removed. Although nearly 300 customers have purchased the navigation system in its current form, which allows directing a unit along a path of sequenced actions, like a tour guide or animatronic puppet in a theme park, we believe many of these customers would be better-served by a system that focuses point-to-point teleporting and automatic pathfinding between a variety of destinations. If this sounds bad to you, don't worry—we're still collecting input on the idea at our biweekly @beacon meetings. Because of this proposed overhaul, navigation will be one of the last features to be added to ARES and won't be available until late July.
• 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.
  • Some devices 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 Summer and Autumn 2023.

Delayed features:

• 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.

Getting ARES

At present, the only way to obtain ARES is by purchasing the CX/Supervisor main controller from the vendors at Eisa Botanical Gardens, just north of our main store in Eisa. It costs L$1400. These vendors will be sporadically available throughout the development process and not always accessible. Pay attention to notices in the NS User Group to stay informed as to when ARES is obtainable.

Release Schedule

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): TBD. This version will add the AMenu utility and continue the work of meeting the original A1 target.
• Alpha 2: TBD.
• Alpha 3: TBD. We hope for the replacement for TESI and the new navigation system to be ready by this date.
• Beta 1: October? We hope to also release a new combat-focused add-on called WARRIOR around this date. The first controllers that were sold running Companion will be converted to run ARES.
• Beta 2: November? We hope to also release a new remote access add-on called 'dive' on this date. By this point all customers who have previously bought a controller should have ARES.
• Beta 3: November? We hope to finish updating devices around this time, and to have a new replacement for the CSU available. The limited-edition ARES controller (Supervisor) will be retired by this point.

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 to-do page, which lists the outstanding tasks and how long each is estimated to take.

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