support

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

Limbo

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.

Post-Beta-2 Focuses

The first "Beta 2" build (0.4.0) was released on April 24, 2024, and brought huge improvements to the experience of managing the ARES UI. But, as always, there is more to do, and more to improve.

ARES 0.4.1 addresses:

Overheat alarm can get stuck if the unit teleports to a new region before cooling down ✓

Handles compatibility (including several new light bus messages) ✓

Unreliable reassertion of RLV restrictions (mainly after login)

New LSD change logger in kernel monitor

ARES 0.4.2 addresses:

Guaranteed teleports

Guaranteed forced sit and unsit

Stale EPS capacitor data

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

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

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.

HUDware

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.

Dive

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.

Uplink

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.