The majority of ARES is implemented. Items are removed as they are finished, mostly from the top. Nothing on this list is set in stone or final. Names in square brackets are what system components are involved.

ARES updates


These are to-do items that need to be done but, for various reasons, are annoying and keep getting put off. Exactly when they'll actually get done is anyone's guess.

  • Vox bugs: dot commands blocked, duplicated chat
  • finish core personas
  • consent request bundling; updatable alerts [security, variatype]
  • defensive low-power-masking
  • forget deleted scripts [kernel]
  • standard external menu HUD (AMenu)

  • ARES-to-ARES menu access [variatype + menu]
  • db backup, db load support for character streams (web sources) [db]
  • policies pt 2: curfew [policy]; distress beacon [power], IM policies [policy], owner radio policies and exceptions, TP yank

  • Beta 1 Targets

    The main thrust of Beta 1 is controller compatibility. Although some other minor QoL improvements and bugfixes were delivered in this period, most code changes pertain to ensuring all controllers work properly.

  • See ARES Controller Info page for information on retrofits.
  • See Device Compatibility page.

  • Beta 2 Targets

    Since the launch of Beta 1 we have learned two things:

  • There is substantial technical debt around restrictions management. To fully implement Sexuality and Warrior, the effector daemon needs to be fully capable of managing multiple sources of any RLV restriction (including pseudo-restrictions like movement lock, animations, and movement friction.) ✓
  • The ARES immersive HUD design experience is not valid for all users. 4K screens, tiny laptops, windowed mode, and (disgusting) theme choices can all render it non-workable, and it is currently too much effort to customize.

  • Therefore we are taking on the following tasks before continuing:

  • Move interference from _effector to _repair ✓
  • Move bang commands from _effector to _device — deemed not necessary (yet)
  • Implement deep multi-source tracking for all rules in _effector ✓
  • Add new system program, _display ✓
  • Implement WYSIWYG UI configuration in _display ✓
  • Move main interface layout function from _interface to _display, and expand to include alternatives ✓
  • Move device interface from _variatype to _display, and add support for expanding in alternative directions ✓
  • Create a new wizard for selecting UI presets

  • Other Beta 2 perks include:

  • Managed HTTP listeners ✓
  • HW-CAPS protocol support (see memo) ✓
  • AV-CAPS auto-attachment management
  • Better memory management support for multiple package servers ✓

  • After this is done, development will return to work on Warrior and Sexuality.

    Beta 3 Targets

    Previously known as Beta 2, this update's main purpose is to set the stage for DIAG and HCS (see below) by making room in the kernel and in the _status daemon for future growth. Additional goals during this period include:

  • Spring Utilities replacements with new rental, proximity, and cron (scheduler) facilities
  • Hierarchy/XNMS compatibility [domain]—no server code changes anticipated
  • not implementing database overlays: this is a cut feature, as the db utility is already brimming
  • update remaining devices (those that previously depended upon the Companion "internal" message)
  • fast loading of local notecards
  • short-circuit trivial filesystem refreshes

  • Cleanup:
  • shakedown of interference and security rules
  • shakedown of documentation completeness
  • shakedown of guest access
  • shakedown of announcer rules; second set of announcers
  • recheck all code in <kbd>@help</kbd>; root out problems

  • Beta 4 and Beyond

  • implement stream-oriented API, adapt command-line pipes

  • Extensions


    Sexuality is the ARES equivalent of Companion's TESI add-on. It provides arousal, cryolubricant management, tactile sensors, and more. Sexuality is part of the same purchase package as TESI Complete.

    Outstanding Sexuality implementation tasks:
  • Example furniture and devices
  • Voices (software works, but need data)
  • Orgasm nozzles
  • Fluid production
  • Reproductive Matrix
  • Friction
  • Installer
  • Wizard
  • Models
  • RLV outfit switching
  • Menu controls
  • Anim detect (head)
  • Prevent touch duration accumulation
  • Anim playback (pelvis)


    WARRIOR is an enhanced combat add-on for ARES that adds features originally slated for ATOS/CX.

    Outstanding WARRIOR implementation tasks:
  • Targeted damage
  • Power malfunctions
  • Update VectorLogix, Arachne X8, ARC, and ExARC to detect and fix ARES power malfunctions

  • DIAG

    DIAG (short for diagnostics) is a software add-on experience for ARES that simulates malware and logic malfunctions. Its main purpose is to encourage roleplay around repair and maintenance, including a special tech support crew staffed by NS volunteers who help rescue stranded units in the field.

    Outstanding DIAG implementation tasks:
  • Implement main program
  • Update VectorLogix, Arachne X8, ARC, and ExARC to detect and fix DIAG problems
  • Update training course website
  • Organize tech crew

  • HCS: The new CSU

    The CSU is a particularly design-intensive product that requires a complete overhaul. Many of its settings are no longer meaningful, as ARES soft-codes all of the power subsystems, so these can be changed without the CSU.

    We would ideally like to replace the CSU with a "cyberware inventory" experience called the <b>Hardware Components System</b>, where you must go to your local ripperdoc (Arachne X8) to change load-outs.


    This is a generic server/client architecture for implementing multiple HUDs with a single attachment, a little like X Windows. For sanity and sanitation reasons we intend to implement HUDware first, then implement the HCS interface using HUDware.


    In 2019 we demonstrated a somewhat-janky-and-laggy-but-viable pair of gadgets for remotely controlling other avatars' movements and camera using direct control input. Dive will package this as a telepresence add-on for use between NS units in the same region.


    myNanite Uplink has been a long-standing dream project at NS, intended to provide a web-based interface for accessing and managing units remotely via a subscription service. Implementing it will require a new payments system, and (hopefully) allow integration via our upcoming Patreon.