roadmap
The future of ARES
This page documents the current plan for future versions of ARES.
See also:
ARES Controller Info for information on retrofits
Device Compatibility
Previous versions of this page
Last updated: July 9, 2026.
The Beta 3 era is primarily concerned with the development and release of WARRIOR, our high-end combat system add-on. However, this has required a large number of "side quests" to manage prerequisites and technical debt, including multiple filesystem rewrites. Consequently the Beta 3 series has lasted longer than any preceding Alpha or Beta, and will likely be longer than those that follow it.
Currently working on cortex and bed compatibility with non-WARRIOR systems.
libchassis, a new clearinghouse for combining rules from multiple sources
Cortex compatibility with ARES
Diagnostic and repair bed compatibility with ARES
Finish and release WARRIOR R1
Work required to make WARRIOR R1 function properly
Make sure TrueShield stops collision damage properly
Fix back-up disks
Test hover height code
Finish implementing policies: curfew; distress beacon; IM policies; owner radio policies and exceptions, TP yank
Cron in scheduler
Proximity in scheduler
Boot and shutdown scripts
Address bug 3693 (nav doesn't automatically unleash if target vanishes)
rent application
Improve efficiency in baseband; implement remote permission for public bus access
DIAG release 1 will be the next project after 0.6.0 ships.
This version is reserved for accommodating any adjustments to the OS necessary for DIAG release 1. It will be released simultaneously with DIAG and be required to use DIAG.
domain hierarchy/XNMS client
Long-suffering vox bugs: dot commands blocked, duplicated chat
Hover height control improvements; settings for hover height in media animations
Guaranteed forced sit and unsit (problems putting the unit on furniture while it's powered down)
Sexuality preview 3 will be the next project after 0.6.1 ships. It will address non-playing sounds and cram in whatever other missing features we can fit.
If any adjustments to the OS are necessary to make Sexuality release 3 work, version 0.6.3 will ship containing those fixes.
Finish AV-CAPS support
Get Bismuth deployable via AV-CAPS
UPLINK release 1 will be the next project after 0.7.0 ships.
Compatibility patch for UPLINK.
Security shakedown
Revisit and finish personas
Unit-to-unit menus
Device compatibility
Kernel revisit
Device compatibility
Documentation
Bug round-up
Documentation
The first non-beta version of ARES will be 9.0.0. This follows the Companion version numbering scheme (which started at 6.0 and ended with 8.6.4) as well as an internal logic of simply stripping off the leading "0." in the ARES pre-release version numbering.
defensive low-power-masking
Implement militarizer
Shipping software [?id=3202#differentiation-specifics|differentiation]
Apps: Hookup, transponder, cal, etc.
DIVE support.
DIVE release 1 will be released when 9.2.0 ships.
Shipping hardware [?id=3202#differentiation-specifics|differentiation]
CX-SCADA, scour, Scout booster, etc.
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.
consent request bundling; updatable alerts [security, variatype]
forget deleted scripts [kernel]
standard external menu HUD (AMenu)
stream-oriented API, adapt command-line pipes
database overlays (the db utility is already brimming)
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 & hooks for displaying fluid levels
Fluid metabolism
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
AV-CAPS (short for avatar capabilities) is a protocol for automatically adding attachments from the avatar's #RLV folder when requested by an object in-world, without the mess of the complicated RLV Relay protocol. Used properly, this allows ARES or any other product to request that, for example, a color configuration HUD be attached temporarily when required, saving the user the trouble of digging through their inventory to find it.
AV-CAPS is furthermore designed to maintain a cache of HUDs, so they can be transferred from the product into the AV-CAPS provider when the product is first activated, and put into the user's #RLV directory only when the user actually requests the interface. Additionally, AV-CAPS can store certain user preferences, such as screen resolution or favorite colors, which HUDs and products can query from it. The specification furthermore covers an attachment status protocol, which allows HUDs to report when they are ready to receive connections, or too busy to be used. The result is a near-seamless experience for the user.
The Chassis Specification Unit was 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; therefore their power costs can be changed without the CSU's involvement.
We would ideally like to replace the CSU with a "cyberware inventory" experience called the Hardware Components System, where you must go to your local ripperdoc (Arachne X8) to change load-outs. Rather than individually choosing each specific setting, units instead select different components which have associated numeric attributes. For example, a fast-recharging FTL coil might use more power overall, but reduce the duration required for a full recharge between maximum-distance jumps.
The current scheme for the HCS has the following slots:
Cortex: Controls power costs for chat, GPS, and mind subsystems
Subdermal sensors: Controls power costs for TESI arousal, efficiency of @zap, and the reach subsystem
Optics: Eyes attachments; controls power costs for video and identification subsystems, and glitch effects
Icon: Icon attachment (if present)
OSL: Ornamental lighting attachments (if present)
Metabolic Converter: Controls cost of converting fluids into TESI lubricant
Shield: Shield attachment (if present)
Jump Drive: Controls time, cost, and efficiency of teleporting, and the appearance of teleportation effects
Animatronics: Controls cost of movement, jumping, running, and the appearance of spark effects
Flight System: Controls cost of flight, and any visual effects, and possibly extra movement control features like double-jumping or hover jetpacks
The slots that describe attachments would need manual setup in #RLV folders, and are basically a roleplay wrapper for outfit swaps that avatars can already perform freely at any time. Options for the other HCS slots would be obtained through various in-world experiences similar to crafting in a survival game.
Longevity: HCS is considered a high-risk system because it depends on the availability of a persistent external inventory server, like Uplink, this website, and the NS store. Its efficacy would be severely compromised in the case of a server outage or end-of-life contingencies.
This is a generic server/client architecture for implementing multiple HUDs within a single attachment, a little like X Windows. For sanity and sanitation reasons we intend to build the HCS interface using HUDware, and to closely integrate HUDware with AV-CAPS so that one protocol can be used to control sessions with both methods of HUD display. Technical information on HUDware can be found on the develop.ns site.
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 for standard movement. DIVE will package this as a telepresence add-on for use between NS units in the same region, allowing one avatar to remotely pilot another, called "diving" into that avatar's systems (by reference to Ghost in the Shell).
The core concept of DIVE is to detect when the controlling avatar presses the arrow keys (or W, A, S, D) and to prevent those actions from occurring on the controlling avatar, instead sending messages to the target avatar to reproduce the same effect. Using llSetAgentRot(), rotation can be set; likewise, motion can be created with llApplyImpulse() or llMoveToTarget(). The experience is not the same as self-control: there is considerable input lag (as commands must pass to the server and then to the receiver script). During a dive, the target avatar cannot issue move commands independently unless they also dive out to another body.
There are limitations to the movement of an avatar during a dive. There is no way to redirect touches or menu actions, so sitting and standing from furniture must be done with a special menu (like when issuing commands via horns or another RLV device.) There also appears to be no way to toggle flying—any movement into the air will cause the avatar to fall down repeatedly, as leash users already know.
Moving the camera is similar: with llSetCamera(), the controlling avatar's default view is moved to follow the target avatar instead of the controlling avatar. LSL does not provide for proper tracking of objects other than the viewer's own avatar, however, so this feature is both slow and jerky (the camera snaps to a new position 2-4 times per second and isn't smooth at all). It is technically possible to go a step further and override the target's camera position with the controlling avatar's camera position, but this seems like an idea that would be better packaged as a separate "camera sharing" experience, separate from DIVE.
Finally, DIVE also forwards chat, menus, and commands, so that the controlling avatar can hear, speak, and control the target's system as if it was their own. This helps with certain movement tasks like teleportation. The ARES model of using pipes to manage input and output was designed specifically to facilitate this kind of indirection.
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 Patreon.
Unlike other NS services, Uplink requires a subscription because of its dependency on external resources. These would be payable in-world using L$. Additionally, there is an upfront cost to install the Uplink software on a robot, but no cost for users.
The Uplink payments model consists of three classes of subscriptions:
Unit-to-all: A unit pays a fee to let anyone it trusts access its systems.
All-to-user: A user pays a fee to connect to any robot with the software, provided the user would have access to that robot in-world.
Couples discount: A unit or user pays a one-time discounted fee to have access to their SL account's listed Partner, and vice versa. Voided with no refund if the partnership ends.
Logging into Uplink involves making an account on my.nanite-systems.com (currently possible through the NS store Redelivery page) which is tied by a login token to your SL account.
Once logged in, a user has access to the Uplink console. Exactly what features will be on the console are not set in stone, but ideas include exposing the unit's:
Online status
Location
Teleport history
Nearby avatars
Nearby seats (for force-sitting)
Menus
Commands
Messages heard in local chat
Chat input
TP bookmark list
The web UI will be responsive and adapt to any screen size, including smartphones.
As with any piece of spyware, Uplink has the potential to generate a great deal of interpersonal drama. To make sure Uplink is a tool for fun rather than mistrust and surveillance, the unit can turn it off any time, at which point the web UI will behave as though the avatar is offline. Consent under duress is not true consent.
Longevity: While we hope to be around for a long time, buyers of Uplink should be conscious of the fact that it depends on NS-owned external servers, unlike the core ARES experience, which will always function so long as Second Life exists.
See also:
ARES updates
New Roadmap
Last updated: July 9, 2026.
Beta 3
The Beta 3 era is primarily concerned with the development and release of WARRIOR, our high-end combat system add-on. However, this has required a large number of "side quests" to manage prerequisites and technical debt, including multiple filesystem rewrites. Consequently the Beta 3 series has lasted longer than any preceding Alpha or Beta, and will likely be longer than those that follow it.
0.5.8 series
Currently working on cortex and bed compatibility with non-WARRIOR systems.
0.5.9
Beta 4
0.6.0
DIAG release 1 will be the next project after 0.6.0 ships.
0.6.1
This version is reserved for accommodating any adjustments to the OS necessary for DIAG release 1. It will be released simultaneously with DIAG and be required to use DIAG.
domain hierarchy/XNMS client
0.6.2
Sexuality preview 3 will be the next project after 0.6.1 ships. It will address non-playing sounds and cram in whatever other missing features we can fit.
0.6.3
If any adjustments to the OS are necessary to make Sexuality release 3 work, version 0.6.3 will ship containing those fixes.
Beta 5
0.7.0
UPLINK release 1 will be the next project after 0.7.0 ships.
0.7.1
Compatibility patch for UPLINK.
0.7.2
0.7.3
Beta 6
0.8.0
0.8.1
0.8.2
Release 9
The first non-beta version of ARES will be 9.0.0. This follows the Companion version numbering scheme (which started at 6.0 and ended with 8.6.4) as well as an internal logic of simply stripping off the leading "0." in the ARES pre-release version numbering.
9.0.0
Implement militarizer
Release 9.1
9.1.0
Apps: Hookup, transponder, cal, etc.
Release 9.2
9.2.0
Release 9.3
9.3.0
CX-SCADA, scour, Scout booster, etc.
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.
Cut Features
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:
AV-CAPS
AV-CAPS (short for avatar capabilities) is a protocol for automatically adding attachments from the avatar's #RLV folder when requested by an object in-world, without the mess of the complicated RLV Relay protocol. Used properly, this allows ARES or any other product to request that, for example, a color configuration HUD be attached temporarily when required, saving the user the trouble of digging through their inventory to find it.
AV-CAPS is furthermore designed to maintain a cache of HUDs, so they can be transferred from the product into the AV-CAPS provider when the product is first activated, and put into the user's #RLV directory only when the user actually requests the interface. Additionally, AV-CAPS can store certain user preferences, such as screen resolution or favorite colors, which HUDs and products can query from it. The specification furthermore covers an attachment status protocol, which allows HUDs to report when they are ready to receive connections, or too busy to be used. The result is a near-seamless experience for the user.
HCS: The new CSU
The Chassis Specification Unit was 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; therefore their power costs can be changed without the CSU's involvement.
We would ideally like to replace the CSU with a "cyberware inventory" experience called the Hardware Components System, where you must go to your local ripperdoc (Arachne X8) to change load-outs. Rather than individually choosing each specific setting, units instead select different components which have associated numeric attributes. For example, a fast-recharging FTL coil might use more power overall, but reduce the duration required for a full recharge between maximum-distance jumps.
The current scheme for the HCS has the following slots:
The slots that describe attachments would need manual setup in #RLV folders, and are basically a roleplay wrapper for outfit swaps that avatars can already perform freely at any time. Options for the other HCS slots would be obtained through various in-world experiences similar to crafting in a survival game.
Longevity: HCS is considered a high-risk system because it depends on the availability of a persistent external inventory server, like Uplink, this website, and the NS store. Its efficacy would be severely compromised in the case of a server outage or end-of-life contingencies.
HUDware
This is a generic server/client architecture for implementing multiple HUDs within a single attachment, a little like X Windows. For sanity and sanitation reasons we intend to build the HCS interface using HUDware, and to closely integrate HUDware with AV-CAPS so that one protocol can be used to control sessions with both methods of HUD display. Technical information on HUDware can be found on the develop.ns site.
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 for standard movement. DIVE will package this as a telepresence add-on for use between NS units in the same region, allowing one avatar to remotely pilot another, called "diving" into that avatar's systems (by reference to Ghost in the Shell).
The core concept of DIVE is to detect when the controlling avatar presses the arrow keys (or W, A, S, D) and to prevent those actions from occurring on the controlling avatar, instead sending messages to the target avatar to reproduce the same effect. Using llSetAgentRot(), rotation can be set; likewise, motion can be created with llApplyImpulse() or llMoveToTarget(). The experience is not the same as self-control: there is considerable input lag (as commands must pass to the server and then to the receiver script). During a dive, the target avatar cannot issue move commands independently unless they also dive out to another body.
There are limitations to the movement of an avatar during a dive. There is no way to redirect touches or menu actions, so sitting and standing from furniture must be done with a special menu (like when issuing commands via horns or another RLV device.) There also appears to be no way to toggle flying—any movement into the air will cause the avatar to fall down repeatedly, as leash users already know.
Moving the camera is similar: with llSetCamera(), the controlling avatar's default view is moved to follow the target avatar instead of the controlling avatar. LSL does not provide for proper tracking of objects other than the viewer's own avatar, however, so this feature is both slow and jerky (the camera snaps to a new position 2-4 times per second and isn't smooth at all). It is technically possible to go a step further and override the target's camera position with the controlling avatar's camera position, but this seems like an idea that would be better packaged as a separate "camera sharing" experience, separate from DIVE.
Finally, DIVE also forwards chat, menus, and commands, so that the controlling avatar can hear, speak, and control the target's system as if it was their own. This helps with certain movement tasks like teleportation. The ARES model of using pipes to manage input and output was designed specifically to facilitate this kind of indirection.
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 Patreon.
Unlike other NS services, Uplink requires a subscription because of its dependency on external resources. These would be payable in-world using L$. Additionally, there is an upfront cost to install the Uplink software on a robot, but no cost for users.
The Uplink payments model consists of three classes of subscriptions:
Logging into Uplink involves making an account on my.nanite-systems.com (currently possible through the NS store Redelivery page) which is tied by a login token to your SL account.
Once logged in, a user has access to the Uplink console. Exactly what features will be on the console are not set in stone, but ideas include exposing the unit's:
The web UI will be responsive and adapt to any screen size, including smartphones.
As with any piece of spyware, Uplink has the potential to generate a great deal of interpersonal drama. To make sure Uplink is a tool for fun rather than mistrust and surveillance, the unit can turn it off any time, at which point the web UI will behave as though the avatar is offline. Consent under duress is not true consent.
Longevity: While we hope to be around for a long time, buyers of Uplink should be conscious of the fact that it depends on NS-owned external servers, unlike the core ARES experience, which will always function so long as Second Life exists.