roadmap
The future of ARES
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.
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
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.
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.
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
implement stream-oriented API, adapt command-line pipes
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 (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
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.
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.
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.
Beta 2 Targets
Since the launch of Beta 1 we have learned two things:
Therefore we are taking on the following tasks before continuing:
Other Beta 2 perks include:
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:
Cleanup:
Beta 4 and Beyond
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:
WARRIOR
WARRIOR is an enhanced combat add-on for ARES that adds features originally slated for ATOS/CX.
Outstanding WARRIOR implementation tasks:
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:
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.