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
The planned list of versions was rewritten on June 26, 2024 to be more concrete, and to re-prioritize planned tasks based on urgency and impact.
(Previously 0.4.4)
New filesystem implementation ✔
New help system implementation ✔
Morgan's control freak tranche:
Update art assets for Beta 3 (working widget, install wizard) ✔
Add autoexec.as detection to new filesystem ✔
Add resolve_i() calls to non-volatile programs ✔
Test package installs ✔
Sexuality preview 2 will be the next project after 0.5.0 ships.
Solve obstacles to recharging dead units ✔
LL Combat 2.0 compatibility ✔
Add !working widget support to new filesystem ✔
Work yet again on the 'command' light bus message ✔ (?)
Solve Tekklaa's Bug ✔
WARRIOR release 1 will be the next project after 0.5.2 ships.
Version 0.5.3 is reserved for the compatibility work required to make WARRIOR R1 function properly. It will most likely only affect the internals of _repair, _status, and other systems that WARRIOR needs to interact with.
WARRIOR R1 and ARES 0.5.3 will not ship with diagnostics bed compatibility. This is the diagnostics bed compatibility patch, which will be released in concert with the diagnostics bed updates.
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
rent application
Bug review
domain hierarchy/XNMS client
New settings backup disks based on phase/LSD
Investigate env corruption
Unreliable reassertion of RLV restrictions (mainly after login)
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.
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.
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
New ax refactor for handling monstrous package lists (axsc)
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
defensive low-power-masking
Militarizer
Shipping soft differentiation
Apps: Hookup, transponder, cal, etc.
DIVE support.
DIVE release 1 will be released when 9.2.0 ships.
Shipping hard 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
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 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.
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 with a single attachment, a little like X Windows. For sanity and sanitation reasons we intend to implement the HCS interface using HUDware. 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 RLV (and soon pure LSL), 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 current 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. Remember, consent under duress is not true consent.
Note that Uplink is considered a high-risk system because it depends on the availability of a persistent external server. It would not function at all in the case of a server outage or end-of-life contingencies.
See also:
ARES updates
New Roadmap
The planned list of versions was rewritten on June 26, 2024 to be more concrete, and to re-prioritize planned tasks based on urgency and impact.
Beta 3
0.5.0
(Previously 0.4.4)
- Remember chat capture status on login ✔
- Policy to forbid chat release ✔
- Current persona display on HUD ✔
- Current persona display in persona menu ✔
Sexuality preview 2 will be the next project after 0.5.0 ships.
0.5.2
WARRIOR release 1 will be the next project after 0.5.2 ships.
0.5.3
Version 0.5.3 is reserved for the compatibility work required to make WARRIOR R1 function properly. It will most likely only affect the internals of _repair, _status, and other systems that WARRIOR needs to interact with.
0.5.4
WARRIOR R1 and ARES 0.5.3 will not ship with diagnostics bed compatibility. This is the diagnostics bed compatibility patch, which will be released in concert with the diagnostics bed updates.
0.5.5
rent application
0.5.6
domain hierarchy/XNMS client
New settings backup disks based on phase/LSD
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.
0.6.2
Sexuality preview 3 will be the next project after 0.6.1 ships.
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
9.0.0
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:
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 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.
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 with a single attachment, a little like X Windows. For sanity and sanitation reasons we intend to implement the HCS interface using HUDware. 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 RLV (and soon pure LSL), 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. Remember, consent under duress is not true consent.
Note that Uplink is considered a high-risk system because it depends on the availability of a persistent external server. It would not function at all in the case of a server outage or end-of-life contingencies.