the future of NS operating systems

In late 2022, Linden Lab added a new feature to scripting in SL called LinksetData. This allows for storing up to 64 kilobytes 128 kilobytes[1] of text in the root prim of a linkset. It was probably intended to mitigate the proliferation of furniture using resource-hogging "memory" scripts to store poseball offsets, but its potential for revolutionizing the design of Companion and systems like it is extremely immense.

To properly take advantage of this means fundamentally changing how scripts communicate. But after nine years of constant development and growth, moving forward means starting again from the ground up.

Our original architecture was built exclusively around link messages, and used a large set of uniquely-numbered system call messages that could be received by all the scripts in the same prim. Many of these calls related to conveying or querying bits of information, like whether the unit was powered on, or what its name was.[2] Unfortunately this meant that every message passed between two scripts had to be analyzed and then ignored by every script in the prim, including the script that sent it. By the time we released Companion 8.4 in 2017, even modestly-sized gatherings of NS units could bring a sim to a crawl.

The solution to this was both severe and intricate: a kernel. Most scripts in the 8.4 system spend the majority of their time idle, only waking to uselessly dismiss messages being spammed between other parts of the OS. For example, while the unit is on a charging pad, the charging script constantly communicates with the battery manager, to indicate that new power has been received, but every system component, from the users script to the path-following navigator, is told about this. These scripts could instead be set to not running while unnecessary, only awoken when requested. This is thanks to a fortunate quirk in SL's design: when scripts are told to enter a non-running state, they preserve their memory unless you rez them again, teleport to a new sim, or return them to your inventory. The kernel's job is to keep track of all the link message numbers, which scripts handle which messages, and what tasks, if any, they're currently processing. If all the moving parts play nicely, the user only suffers a slight performance overhead. This is the _whip module that is responsible for module probes, and it is largely invisible until something goes wrong.

Realistically, something does go wrong fairly often. Script event queues can get saturated (they can only store up 64 incoming messages before they start dropping), and when your avatar arrives in a new sim, utter chaos erupts in the controller because of how many components need to re-register themselves and recover their settings from the configuration manager, _balance. Thus, for literally three or four years, it has been common to see cases where units lose their name or color settings after teleporting—it's better now than it was, but it's still not perfect. Needless to say more intricate settings options get even messier. More than one customer still swears by 8.4.5, lag and bottlenecks be damned.

Around the middle of 2022, just before the release of LinksetData, we began exploring a new communication design where scripts would talk to each other using chat channels instead of link messages. These have some caveats[3] but they're manageable.[4] Chat channels are excellent at preventing the combinatorial explosion of direct link messages because events are only generated if a listener is registered in advance. Moreover listeners can be set to only receive messages from one prim, allowing the architecture to enforce a ban on cross-talk. This is the basis of our new OS, the Advanced Research Execution System, or ARES. ARES also uses the system call space generically,[5] which greatly reduces the amount of actual work the kernel needs to do—it doesn't need to keep track of script capabilities to nearly the same extent.

Adding LinksetData to this new design further reduces the amount of script communication required, because a configuration storage script is no longer mandatory; scripts can fetch their own settings whenever they want. Indeed, most scripts in ARES are completely reset when no longer in use, allowing their memory to be freed up from the sim. LinksetData is also useful as a communications medium itself: in ARES it holds pipe buffers (temporary blocks of text) for when scripts need to communicate with users or each other, making it practical to implement certain extremely complicated or memory-intensive technologies like applying vox filters to incoming chat, connecting to the controller from outside SL (via telnet or a web interface), and fully abstracted file I/O.

As of this writing, many of the hard steps to implement ARES are already complete, but there is still a lot more to be done before it lives up to its potential and is a worthwhile replacement for Companion. We hope to have a preview build available in early April in June 2023, but much about the situation is fluid and subject to change.

NS-860 Jovian

At the heart of the NS-860 Jovian is a military-grade communications array designed for signal dispatch and battlefield intelligence. With state-of-the-art spectrum-hopping, jamming, and multiplexing circuitry, it is capable of eavesdropping on encrypted and scrambled communications at hundreds of kilometers away in Earth-standard atmosphere, and up to fifty times further in the vacuum of space. Patented NANOCOM decoder technology, leveraging the latest advancements in adversarial neural networking techniques, allows the Jovian to achieve an excellent signal-to-noise ratio under circumstances where traditional top-of-the-line amplification hardware is completely useless.

But the Jovian isn't just a self-propelled communications terminal. Thanks to the power of its built-in ECM-860 Electronic Countermeasures Module, the Jovian can produce an omnidirectional electromagnetic pulse (EMP), disabling all machines within a 10 m radius for up to 4 seconds. It does this while also sporting a unique form of electromagnetic interference mitigation, which prevents 75% of all EM bursts, including from traps and interference weapons. With the Jovian, the face of war is changing.

Warning: the export and import of advanced high-power radio equipment may be the subject of sanctions. Consult local laws before acquiring.

Individual NS-860 units are available through NS flagship stores and select service locations for L$1100. For government and corporate orders, contact your Nanite Systems sales representative.

In defense of epidermal coating compatibility

NS is widely known as one of the foremost manufacturers of epidermal coating systems for anthropoid robots, particularly gynoids. Over the years we have extensively refined our production methods to develop the best polymer-alloy and chromium colloidal systems available on the market. Of course, this industry is only a fraction of the size of the market for organic skins worn by humans, but as chassis designers get more daring in their mimicry of real life, the boundary between the artificial and real person is steadily eroding. With that convergence comes changes in the underlying technology at play.

In general, we have striven to avoid getting involved in compatibility disputes between body manufacturers. For the past decade, the popular Omega applier system has allowed body designers to ensure that both organic and polymer coatings look consistent on a wide variety of body types and variants. However, with the introduction of Linden Lab's Bakes-On-Mesh (BOM) technology for applying epidermis coloring, some vendors have seen the opportunity to revisit their commitment to industry standards and have sadly withdrawn partly or entirely from the Omega ecosystem, under the pretense that Omega appliers are a hindrance to BOM adoption. For many human skin designers this may be acceptable, but it is a major problem for the unique linework and shading that goes into our epidermal coatings. Vendors like these continue to offer their own isolated ecosystem of materials appliers, but like previous efforts at building such "walled gardens," they are at best a hassle to the consumer and at worst an attempt to sabotage future competition, by "locking in" designers to specifically supporting their anatomy.

Since this is primarily an issue with head vendors, starting today, NS has begun shipping the full-permissions textures for head specular and normal channels with our Liquid Metal, Metalloplastic Akagi, and Metalloplastic Theory skins series. This will trivialize the effort required for customers to produce their own appliers if necessary, or install the skins directly through facilities where made available by the vendor. Existing users can obtain access to these textures by requesting a redelivery of their purchases using an XVS Pocket Redelivery Terminal or Redelivery monad.

NS-478 Revenant

NEW EISA VILLAGE, EISA—Following many hard, long months of intensive research studying the mysterious ruins unearthed beneath the former Eisa Colony site, engineers at the Nanite Systems Xenoarchaeological Technology Transfer Group have successfully manufactured a miracle, raising an ancient technology from the dead: the reprogrammable hardware left behind by Eisa's first-ever occupants.

The new controller, dubbed the NS-478 REVENANT, in reference to its journey of resurrection, offers the best of our flagship combat hardware platforms in reliability and performance while also leveraging the unique material properties of the xenological results. In addition to being fully ready for ATOS/CX, the NS-478 uses a unique hard-light barrier to protect crucial systems and can project a holographic display ventrally (forward) despite being back-mounted.

The NS-478 Revenant is already available at Nanite Systems flagship stores, and includes a steel nanoweave faceplate for night operations. The manufacturer suggested retail price (MSRP) for the Revenant is L$1200. An upcoming patch for the control system will add in the ability to control the orientation and offset of the screen projection.

In late 2018, Eisa Colony, the major settlement on the small resort moon Eisa, suffered a catastrophic disaster when a test of an illegal faster-than-light engine triggered a gravitational resonance cascade in a mineral deposit beneath the colony. An estimated 8740 civilians and Nanite Systems personnel were killed, with more than ten thousand more injured. Property damage was estimated at $14.2 billion, including $4.5 billion in destroyed or damaged robots.

In the wake of this disaster, rescue efforts were hampered by interference from a large number of autonomous aerial drones, which were initially believed to be the second phase of a deliberate terrorist attack but subsequently determined to have originated beneath the moon's surface, deep in the crater created by the explosion. Upon determining the drones were not of Terran origin, the company leveraged its extensive contacts in academia and the private sector to assemble the first-ever team of xenoarchaeologists, who would spend the next two years studying the ruins and the technology they contained. This unique multidisciplinary group has since spent almost two years studying the technology of the crater, and to date Nanite Systems has successfully brought four different products to market, based heavily or exclusively on reclaimed machinery.

Among the many devices uncovered during the XTTG excavation of the Eisa site were the oXq.205 series of oXq.205 series of robot control units, specifically a little-known variant called the oXq.205.0x. Superficially similar to the 205.4i in size and shape, the 0x modules were found to be much more programmable and are believed to have been hand-built prototypes for the 4i, 8i, and likely many other 205 models that have yet to be discovered.

Companion 8.6 now in development

For the past three years our civilian software development has been focused on completing Companion's big 8.5 update. This update emphasizes reduced processor load, and was aimed at solving region gridlock issues caused by the popularity of our systems. We've seen a lot of success in reducing unnecessary script overhead, but also a multitude of new challenges brought about by the mixing of new and old code. By design, many parts of the system in 8.5 remained essentially untouched, and customers testing 8.5 builds have encountered many related issues, mostly in the form of settings rollbacks and other configuration problems.

The solution to this is to go forward, and to start digging deeper into the parts of the OS that went unchanged in 8.5. That's why, in keeping with our planned development cycle, we're now calling the new version 8.6. Along with the realization of these planned upgrades, we'll be introducing exciting new technology previews and features targeted at 8.6, including both in-world and web-based remote control, a new scripting language, Unix-style shell pipes, and so much more. To keep up to date on all future releases, remember to keep an eye on the Group Notices section of the Nanite Systems User Group.

Arachne X8

From NSIF's legendary Orion Belt Foundries comes a maintenance platform that will make you cry.

Seriously. It throws way more shade than the VectorLogix bed. And unlike the VectorLogix bed, it was designed from the ground up to weld broken robots back into one piece, using its high-powered electric welding arm to treat even the toughest of transceiver, cortex, and chassis damage. You'll wonder how you ever repaired damage without it.

Facts

• Price: L$800
• Available: now, in-world (Eisa)
• Land impact: 12
• Permissions: copy/mod
• Relinkable: yes (requires script extraction and re-insertion)
• Gender: huge bitch
• Favorite color: apricot
• Included package sideloading mechanism: Xanadu Package Server 1.1.4
• Welding arm degrees of freedom: 5 (base pivot, pneumatic welding head extensor, and 3 pitch control joints)
• Scripts: 6 (213 KB required memory)
• Charging speed: 160 kW (11% faster than an ARC, 21% faster than a Charger 3)
• Designer: Tamara Peluso

Additionally, the VectorLogix diagnostics bed has been reduced in price to L$600 (from L$750).

Disclaimers and other notes

• Due to the nature of the grid's permissions system, most software packages, especially system updates, cannot be redistributed once they are delivered to the user. This means it is not possible to use your bed to install official NS software on controllers belonging to other avatars.
• No software packages are included with the Arachne X8. The VectorLogix bed included four, which could be used to reinstall parts of the operating system in the event of a script crash. These packages are no longer necessary, as Companion 8.5's @reset system command can be used to restart scripts in user memory. Consequently, they have not been included.
• The X8 was tested extensively with Companion 8.5. Users of Companion 8.4 may still face guest permissions issues when using beds owned by others if the consent prompt expires or is rejected. To resolve this situation, try the following commands, in order:

  @reset hierarchy
  @reset obedience
  @reset submission
  @reset puppet

  It should then be possible to receive the consent prompt again.

Mesta

The NS-120 Mesta main controller is now available in-store and online for L$900. Featuring a robust midcentury modern design with original slate gray paintwork, the Mesta is the perfect fit for larger androids destined for industrial, military-logistic, and construction work.

Additionally, it comes with Companion 8.5 release candidate 2 pre-installed, the first controller to feature the 8.5 version of our civilian operating system after years of hard work implementing and innovating new technologies. This allows the Mesta to automatically unload its power cell (and re-load, if batteries are not swapped) when the doors are opened, greatly simplifying this most common of maintenance tasks.

When human strength fails, the Mesta succeeds. NS-120 androids are the backbones of industry on dozens of colony worlds, working tirelessly in factories, foundries, mines, quarries, and even army engineering corps to sustain the precious jewels of civilization that mankind has built in the barren, lifeless wilderness. They may be worn from years of grueling labor, missing bits of epidermal coating and chips of paint, but they are always dependable, keeping the flame of humanity's ambitions fueled. And like the great fifty-kiloton metal presses of twentieth century Earth, their contributions are beyond measure.

You can also see how the Mesta stacks up against other controllers on the feature comparison page.

TESI early access

wcn/3

We introduced the first wireless charging nodes (WCNs) back in 2015, creating an era of effortless and easy power maintenance. Sporting a distinctive design inspired by the electrical transmission coils of Nikola Tesla, they proved highly popular. Today, dozens of locales on the grid have at least one hangout where the distinctive chord hum can be heard.

Under the hood, these classic version 1 WCNs were much more complex than they needed to be. In order to support opting out of wireless charging, each node needed to keep a list of every human and robot in the region, their controllers (if applicable), and the opt-out flag. To track this information the WCNs regularly communicated with each other in a sort of ad hoc network, known as a mesh network, in addition to regularly polling for new potential clients. And to account for the possibility that someone might become a robot at any time, they had to constantly probe non-robot avatars in search of controllers!

Earlier this year we experimented with extending this idea further in the version 2 WCNs. Our original vision for the wireless charging network was that the charging field would never exceed the charge output of a single node, so that a busy club or nook could use peripherally-placed nodes to produce a zone with consistent strength. Implementing this proved harder than expected—each robot would be assigned a 'home' node that provided the desired charge, based on its knowledge of the locations of all the other nodes. Unfortunately, this could cause nodes to fight over robots, each convinced they were more qualified to provide the service. It was not surprising this implementation could end up using tenfold more processing time than the original.

Enter the wcn/3: a clean, simple charging apparatus that strips away all of the complexity of the charging network in favor of an easy-to-use and efficient experience. Unlike previous wireless chargers from Nanite Systems, the wcn/3's configuration file can be used to easily and quickly change illumination color, charging power, range, and frequency, as well as enabling or disabling sound effects. And if there's no one in range—well, then it does nothing at all. It's ideal for large communities, and future versions will even support our Power Distribution System, making it possible to integrate your wireless charging network directly into your own electrical power grid.

We did have to cut some corners to achieve the wcn/3's low overhead, however—the opt-out feature is no longer available. If you miss it, don't worry; Companion 8.5 will support adjusting environmental induction efficiency via the chassis specification unit. That's a lot of fancy words that mean you'll be able to reduce or completely block the effectiveness of passive chargers like the WCNs, demo stands, display cases, and more, without impacting true charging pads or power outlets. In exchange for this, you get a wireless charger that's just 4 LI—much better than the 6 LI used by the original version!

If you've already purchased the WCN, you can get the new version 3 chargers by obtaining a redelivery from the terminal at our main store. Otherwise, stop by today and this must-have will be yours for just L$400.

companion 8.4.4

This service release for Companion 8.4 fixes a security bug caused by incorrect implementation of the 'trigger' command. It also fixes 'charge' for large values and improves display of port connectivity on NS-226 units. Updating is strongly recommended for all 8.4.x users.

Full documentation for 8.4 is available at support.nanite-systems.com.

Battery recall: If your batteries were purchased before February 11, 2017, they need to be replaced to be used with Companion 8.4.2 or later. To get replacement batteries, send your current power cells to Takura Thielt (any time), Kuro Umino (any time) or rhet0rica (weekends only). See the batteries page for more information.

installation instructions for Companion 8.4.4

1. Check your current software version by selecting 'about' from the main menu. If it's 8.0.0 or later, you're good to go. If it's older, or you can't even find the 'about' item, contact technical support directly for further assistance. You can also use the command @about to get the same information.
2. Come to a region with Xanadu support.
3. Getting ready. Type the following to back up your current list of users: @keychain save
   This is optional if you do not wish to preserve your current users.
4. Installation. Go to the following menu: manage > software. If you are running 8.2.1 or earlier, select install. If you are running 8.3.0 or later, select connect.
   1. Select the sim's primary update server. If you are in Eisa, this is xcentral:0. If you are in one of the other supported updating sims, see the list here.
   2. If you are running a version of 8.4 already, select update. (Otherwise, select install.)
   3. Select the Companion_8.4.4 package and upgrade or install it.
   4. If you do not see the update package, see alternative instructions for updating via the command line.
   5. Accept the notecard _System_8.4.4_info when it is offered. If you are running an Aegis that was previously running 8.2.0, there are additional instructions inside that are very important.
   6. Installation will take up to 2 minutes. You will receive a message saying Done. Installed 56 files total. when the process is finished.
   7. Turn the controller back on.
5. If you do not currently have a HUD at the bottom of your screen, type @setup console. If you already use the HUD, you should have been offered an updated one during the install process.
6. Finalizing. Reboot once to apply the applicable changes from the last step.
7. Important note for returning customers: A battery recall was issued on February 11, 2017. Older power cells will not work with the new release. See above for instructions on replacing your battery. If you purchased your battery on or after February 11, 2017, this does not affect you.

changes in 8.4.4

• Fixed environmental charges being ignored if over 20 kJ (a prompt would be generated, but the result discarded); this should fix the pulse beacon, taser, and large @zap jumps.
• Fixed the 'trigger' public bus command to work as intended; it was producing system commands with no arguments instead of activating the Arabesque trigger system. You can now use Arabesque notecards called 'e_charge-start' and 'e_charge-stop' to execute instructions when starting/stopping charging.
• Fixed a slight cosmetic issue with the NS-226 Hephaestus controller not using the visible ports on its case when cables were connected without a Nanoconnectivity adapter installed.

changes in 8.4.3

• Support for shielded uRTG batteries
• Removed spurious debug messages in the SCM damage effect code

changes in 8.4.2

• Resolved inconsistent format in QUERY_SUBSYSTEM and response messages, creating difficulty for app creators who needed to check subsystem states.
• Battery swap-outs were still causing explosive overheating in ATOS/E. This should be resolved now. An update to ATOS/E is not required.
• Fixed devices menu reporting devices as not found or not installed.
• Added version checking for batteries. Please also ensure that you get an updated battery.
• Fixed a bug where '@color company' would cause the unit's lights to go black.
• Restored the hinge script in the XSU.

dax/3 goes mini

It's hard to believe it's been almost eleven months since the DAX/3 first hit the store shelves—our fastest-ever selling controller design, with millions of preorders shipped to eager robot owners across the galaxy just on its first day. But today that bit of history just might be old news, because the DAX/3 mini is a thing of true beauty.

Featuring a matte black ceramic exterior, the DAX/3m is designed to fit in perfectly with our popular Metalloplastic Nova epidermal coating system. Tint its numerous exterior faces however you like, and in whatever patterns you like. It can even be scaled down to just two thirds of its default size if you have a very small avatar. And if you want to change what parts of the hardware light up, no problem—the modern autoconf flicker is more than happy to read new settings out of part descriptions with just a quick reset, and also provides controllable !lamp support.

The DAX/3m features Companion 8.4.3.1, a special version of 8.4.3 that includes support for the DAX/3m's battery socket and sound scheme defaults. Support will also be available in the upcoming 8.5m2 pre-alpha release. ATOS/E is not included by default, but can easily be installed by following the instructions at support.nanite-systems.com.

Available now online or at one of our store locations for just L$900. Become more!

And as always, information on our other controller systems is available at the feature comparison page.

Regarding recent events

Over the past week, you may have heard about our decision to cooperate with federal regulators in the United States pertaining to the improper procurement of biological samples for use in our recreational android and gynoid products. There have been a lot of rumors circulating as to the exact nature of the sampling process, so I'd like to take a moment to clarify some key facts about what happened and what you can expect going forward.

Sampling is a means of sourcing biological and neurological information from an organic template in order to enrich the human-like qualities of our robots. With only a few exceptions, units manufactured and sold by NSCP are designed to have unique appearances and personalities, so that they can better simulate the real experience of talking to a human being. In some cases, we use in-place sampling, also known as 'conversion,' 'robotification,' 'cyberization,' or 'nanite refabrication' to extract the relevant details from a person. Normally, this is done voluntarily, which is legal under Federal law and in several states.

Nanite Systems regularly employs promising students in a wide variety of internships to help foster the talent that our company is built on. As of this writing, we have over fifty thousand interns with the company on dozens of planets, moons, and satellite colonies. As a conglomerate with interests in robotics research, military logistics, and industrial supply, it is inevitable that our employees, as well as interns, are sometimes in risky or hazardous situations, including dangers inherent in the military research and development process, battlefield resupply, and deep space cargo hauling. We take every step available to safeguard the lives of our current and future employees, but in the event that loss of life does occur, next of kin are notified immediately, per standard industry practice and in accordance with the laws of most countries.

Recently, it was discovered that some of our sales staff used our sampling equipment to salvage some of the physical and mental characteristics from interns, both living and recently deceased, exploiting these tragedies that affect everyone in the company in order to obtain bonuses intended for conversion candidate recruitment. In a number of cases it has been confirmed that the living interns involved in these forced conversions were unwilling or had been misled as to the procedure and its consequences. While the resulting product may appear to emulate the attitudes and outlooks of their organic predecessors, they are not to be confused with full-body cyborgs and are only shallow imitations.

After consulting with a number of families of the victims, we've decided to institute a company-wide ban on conversion and to screen against any units that contain detectable traces of human personality or experience, except where an audit can confirm that the unit was voluntarily converted. It is of utmost importance to us that customers can be confident their machines are safe and behave within expected parameters. I and the company as a whole cannot express enough how sorry we are that grieving families have had to grapple with questions of whether or not their daughters, sisters, sons, and brothers have been properly laid to rest. Hopefully, this will set us on the road to making amends.

If you're concerned one of your family members may have been improperly subject to sampling, we want to hear from you. Contact us by email.

ATOS/H combat meter

L$ 300
marketplace link

customer motivation survey

What makes a robot a robot? The purpose of this survey is to better understand why our customers buy our products. The data from it will be used to identify opportunities to satisfy and supplement under-served segments of our userbase. All questions are optional. A summary of overall survey results may be made public, but your individual answers will be kept confidential and anonymous. Everyone is invited to answer, including owners and users who are not robots themselves.

Take the survey here.

customer survey for male-bodied avatars

Nanite Systems is exploring opportunities to create more products targeted specifically at customers who use bodies that are non-feminine. We are interested in collecting data on market size and composition, usage rates of various popular mesh bodies, and where our customers feel our existing offerings are deficient.

The questionnaire includes 13 questions and should take 10-15 minutes to complete. Click here to take the survey.

companion 8.4.3

This service release for Companion 8.4 addresses a HUD issue and adds support for the new uRTG battery that will be released later today. Other bugfixes and improvements are still scheduled for Companion 8.5 and are not included in this patch.

Full documentation for 8.4 is available at support.nanite-systems.com.

Battery recall: If your batteries were purchased before February 11, 2017, they need to be replaced to be used with Companion 8.4.2 or 8.4.3. To get replacement batteries, send your current power cells to Takura Thielt (any time), Kuro Umino (any time) or rhet0rica (weekends only). See the batteries page for more information.

installation instructions for Companion 8.4.3

1. Check your current software version by selecting 'about' from the main menu. If it's 8.0.0 or later, you're good to go. If it's older, or you can't even find the 'about' item, contact technical support directly for further assistance. You can also use the command @about to get the same information.
2. Come to a region with Xanadu support.
3. Getting ready. Type the following to back up your current list of users: @keychain save
   This is optional if you do not wish to preserve your current users.
4. Installation. Go to the following menu: manage > software. If you are running 8.2.1 or earlier, select install. If you are running 8.3.0 or later, select connect.
   1. Select the sim's primary update server. If you are in Eisa, this is xcentral:0. If you are in one of the other supported updating sims, see the list here.
   2. If you are running a version of 8.4 already, select update. (Otherwise, select install.)
   3. Select the Companion_8.4.3 package and upgrade or install it.
   4. If you do not see the update package, see alternative instructions for updating via the command line.
   5. Accept the notecard _System_8.4.2_info when it is offered. If you are running an Aegis that was previously running 8.2.0, there are additional instructions inside that are very important.
   6. Installation will take up to 2 minutes. You will receive a message saying Done. Installed 56 files total. when the process is finished.
   7. Turn the controller back on.
5. If you do not currently have a HUD at the bottom of your screen, type @setup console. If you already use the HUD, you should have been offered an updated one during the install process.
6. Finalizing. Reboot once to apply the applicable changes from the last step.
7. Important note for this version only: A battery recall was issued on February 11, 2017. Older power cells will not work with the new release. See above for instructions on replacing your battery.

changes in 8.4.3

• Support for shielded uRTG batteries
• Removed spurious debug messages in the SCM damage effect code

changes in 8.4.2

• Resolved inconsistent format in QUERY_SUBSYSTEM and response messages, creating difficulty for app creators who needed to check subsystem states.
• Battery swap-outs were still causing explosive overheating in ATOS/E. This should be resolved now. An update to ATOS/E is not required.
• Fixed devices menu reporting devices as not found or not installed.
• Added version checking for batteries. Please also ensure that you get an updated battery.
• Fixed a bug where '@color company' would cause the unit's lights to go black.
• Restored the hinge script in the XSU.

announcing the project incubator

Eagerly awaiting a product release? Wish we'd get something out the door sooner? Help shape the company's future! Today we're announcing the availability of our project incubator website. Vote to tell us what you want to see, and we'll prioritize the most popular ideas. You can upvote as many projects as you want, but only once. Click here to get started.

Have an idea for something you think we should really, really offer? Check the support site to make sure we don't already have it, and then contact our support email with your suggestions, or send a notecard in-world to rhet0rica or Tamara. Be certain that you don't mind sharing, though—when offering ideas, you must be willing to waive all rights to them, and allow us to use them without expectation of giving you any credit, control, or monetary compensation for the contributions.

companion 8.4.2 + battery recall

This service release for Companion 8.4 addresses a few minor issues. It also comes with an absolutely necessary battery recall.

Updating is mandatory and should not be delayed.

Note: Full documentation for 8.4 is a work in progress. Check the support site, at support.nanite-systems.com often.

Battery recall: For several reasons, all batteries currently in service must be replaced. Old batteries (purchased prior to 1 PM SLT on February 11, 2017) will not function with this version of Companion or any subsequent OS release. Your controller will simply fail to turn on. We have done this to force users to update. To get replacement batteries, see the batteries information page.

New batteries end in -X, -C, or -G. Nightfall users who have decided to stick with the one-hour fuel cell can simply get a redelivery, as these batteries are copy-mod. OC Alkaline Batteries are now 0093-24, replacing the old 0093-23+ version. If your battery does not include a part number in its name, it is obsolete.

Changes in the new batteries include non-degrading behavior for more expensive cells (and degrading for cheaper cells), auto-positioning for all cells, new sound effects, new animations, improved insertion angle, and more. These new batteries will work in controllers running older versions of Companion.

Auto-positioning: All new batteries are designed to automatically position themselves in the controller's battery socket. To adjust this behavior, edit your battery and change the number in the description field. (If the description field is blank or says "(No description)", replace it with "-0.334", without the quotes.) This is dependent on the depth of your torso and must be configured individually for each unit. If for some reason auto-positioning doesn't work for you (e.g. your controller is not centered on your back), then you can disable it by attaching the battery to your chest and the controller to your spine, instead. Some manual adjustments will still be required.

installation instructions for Companion 8.4.2

1. Check your current software version by selecting 'about' from the main menu. If it's 8.0.0 or later, you're good to go. If it's older, or you can't even find the 'about' item, contact technical support directly for further assistance. You can also use the command @about to get the same information.
2. Come to a region with Xanadu support.
3. Getting ready. Type the following to back up your current list of users: @keychain save
   This is optional if you do not wish to preserve your current users.
4. Installation. Go to the following menu: manage > software. If you are running 8.2.1 or earlier, select install. If you are running 8.3.0 or later, select connect.
   1. Select xcentral:0.
   2. If you are running a version of 8.4 already, select update. (Otherwise, select install.)
   3. Select the Companion_8.4.2 package and upgrade or install it.
   4. If you do not see the update package, see alternative instructions for updating via the command line.
   5. Accept the notecard _System_8.4.2_info when it is offered. If you are running an Aegis that was previously running 8.2.0, there are additional instructions inside that are very important.
   6. Installation will take up to 2 minutes. You will receive a message saying Done. Installed 56 files total. when the process is finished.
   7. Turn the controller back on.
5. If you do not currently have a HUD at the bottom of your screen, type @setup console. If you already use the HUD, you should have been offered an updated one during the install process.
6. Finalizing. Reboot once to apply the applicable changes from the last step.
7. Important note for this version only: A battery recall was issued on February 11, 2017. Older power cells will not work with the new release. See above for instructions on replacing your battery.

changes in 8.4.2

• Resolved inconsistent format in QUERY_SUBSYSTEM and response messages, creating difficulty for app creators who needed to check subsystem states.
• Battery swap-outs were still causing explosive overheating in ATOS/E. This should be resolved now. An update to ATOS/E is not required.
• Fixed devices menu reporting devices as not found or not installed.
• Added version checking for batteries. Please also ensure that you get an updated battery.
• Fixed a bug where '@color company' would cause the unit's lights to go black.
• Restored the hinge script in the XSU.

companion 8.4.1

This service release for Companion 8.4 addresses a number of minor issues.

All users are strongly encouraged to update.

Note: Full documentation for 8.4 is a work in progress. Check the support site, at support.nanite-systems.com often.

installation instructions

1. Check your current software version by selecting 'about' from the main menu. If it's 8.0.0 or later, you're good to go. If it's older, or you can't even find the 'about' item, contact technical support directly for further assistance.
2. Come to a region with Xanadu support.
3. Getting ready. Type the following to back up your current list of users: @keychain save
   This is optional if you do not wish to preserve your current users.
4. Installation. Go to the following menu: manage > software. If you are running 8.2.1 or earlier, select install. If you are running 8.3.0 or later, select connect.
   1. Select xcentral:0.
   2. If you are running a version of 8.4 already, select update. (Otherwise, select install.)
   3. Select the Companion_8.4.1 package and upgrade or install it.
   4. Accept the notecard _System_8.4.1_info when it is offered. If you are running an Aegis that was previously running 8.2.0, there are additional instructions inside that are very important.
   5. Installation will take up to 2 minutes. You will receive a message saying Done. Installed 57 files total. when the process is finished.
   6. Turn the controller back on.
5. If you do not currently have a HUD at the bottom of your screen, type @setup console.
6. Finalizing. Reboot once to apply the applicable changes from the last step.

changes in 8.4.1

• Improved overcharging protection: inverse square law past 20 m, consent required. This means that any @zap command usage or other charging device will need consent to send more than 20 kJ of power to you.
• Re-examine animation permissions errors.
• Fixed message 170 ignoring 'method' parameter.
• Model tamper warning, automatic OEM chip reload.
• fixed @verbosity being renamed to @VERBOSITY_LEVEL.
• Fixed issues in startFollowingName() affecting two-part legacy names when using _devotion collars.
• Code modernization in user manager.
• Fixed: @access displays local access setting in place of remote access setting.
• Various fixes affecting @autolock.
• Check permissions properly for @bolts, @gender and @commands.
• Guard against more math errors (checking battery level immediately after 5% shutoff while drawing 0 W).
• Automatically blank-out unused faces of touchscreen prims (specular issue; affects mostly XSU users).

companion 8.4

It's taken close to a year, but Companion 8.4 is finally available for regular use. This is an immense update, almost doubling the size of the firmware code base.

release highlights

• RLV relay
• Tutorial mode
• Smarter HUD delivery
• Auxiliary power, giving more flexibility in what subsystems are available when powered down
• Distress beacon
• Domain membership, including downloading settings and users from a central domain server
• Guest access control
• Path navigation (see previous announcement)
• Improved following mechanics
• Improved ATOS/E support
• Foreign device connection
• System policies
• And more!

Companion 8.4.0 is required for two new systems that were released during its development cycle, the XSU and DAX/3. All other users are strongly encouraged to update, as well.

Note: Full documentation for 8.4 is a work in progress. Check the support site, at support.nanite-systems.com often.

installation instructions

1. Check your current software version by selecting 'about' from the main menu. If it's 8.0.0 or later, you're good to go. If it's older, or you can't even find the 'about' item, contact technical support directly for further assistance.
2. Come to a region with Xanadu support.
3. Getting ready. Type the following to back up your current list of users: @keychain save
   This is optional if you do not wish to preserve your current users.
4. Installation. Go to the following menu: manage > software. If you are running 8.2.1 or earlier, select update. If you are running 8.3.0 or later, select connect.
   1. Select xcentral:0.
   2. If you are running a pre-release version of 8.4 already, select update.
   3. Select the Companion_8.4.0 package and upgrade it.
   4. Accept the notecard _System_8.4.0_info when it is offered. If you are running an Aegis that was previously running 8.2.0, there are additional instructions inside that are very important.
   5. Installation will take up to 2 minutes. You will receive a message saying Done. Installed 54 files total. when the process is finished.
   6. Turn the controller back on.
5. If you do not currently have a HUD at the bottom of your screen, type @setup console.
6. Finalizing. Reboot once to apply the applicable changes from the last step.

changes in 8.4

8.3.11.1

• NS-409 Nightfall support

8.4 milestone 1

• moved @follow from _bonds to _compliance
• @follow priority management should be better now
• @navigate in _compliance (support for automated navigation)
• an attempt at fixing repeated autolock
• message 42 (INTERFERENCE_STATE) allowing system modules to react to interference. Proof of concept: _ambiance will now shut off audio output
• entirely when type S interference is present.
• support for 'weapon' bus messages to _sentinel
• removed 'light' message (old OSL will no longer work fully)
• 'power' message now sends every 10 seconds to all devices; format changed from percentage to float
• 'rate' and 'power' now send to any newly-attached device
• converted arabesque 'sound' and 'preload' verbs into actual system commands
• arabesque 'vox' command now '@sound vox ...'
• interference now in _coil (introduced bug? interference not applied if shield fails)
• blocked _coil from emitting multiple 'charge cycle complete' audio notifications
• port protocol
• @persona now lists active RLV folder
• new probe strategy for finding batteries on attach: system probes 6 times at a normal interval until it finds a battery; this may solve every issue
• forever?
• refactor _console-screen::_manager into _core and _interface (expect bugs)

8.4 milestone 1.1

• finished incomplete optimization of _power that was causing charging issues

8.4 milestone 1.2

• implemented '@navigate auto'
• cleaned up '@zap'
• fixed BaCdrive charge bug

8.4 milestone 1.3

• fixed issues with manual starting of node navigation
• added exception to battery probe strategy for BaCdrive
• added beta-version tagging (displays in @about and on main menu)
• restored persona and carrier display to HUD
• progress on fixing exhibition-tty listener overflow
• fixed HUD removing section -1 for devices that did not have a section
• simple @off, @halt and @reboot commands
• @send - range is 0 (regionsayto self), 10 (whisper), 20 (say), 100 (shout), region (regionsay), UUID (regionsayto)
• fixed HUD not responding to @probe—no more need to reboot to make the HUD show up!
• public bus 'trigger' verb for event handling (_arabesque should hook for event-driven e_ action notecards; provide linked message API for other
• programs to respond, too)—this could be used for adding on extra custom environmental reactions to things like sitting on a charger or leaving a
• display booth; similar to 'navigate'; consider adding e_attach?
• renamed '_init' script to 'e_boot'
• added 'e_charge-start', 'e_charge-stop', 'e_shutdown' events
• arabesque now issues commands with id of script activator, not unit; added $user and $username evars for object that activated the script
• added 'H^ ' for deleting spaces before variables in arabesque.
• restructured menus into putative 8.4.0 format
• @commands reindex

8.4 milestone 2

• full RLV relay (new External Restriction Interface (ERR) module named _restraint, not to be confused with old CSB module name)
• ERR multiple restraint source integration
• ERR restraint removal
• ERR block system chat when in effect
• ERR @clear command implemented
• @charge command for interfacing with chargers directly
• attempt to fix animation permissions errors in _bonds
• attempt to eliminate remaining issues with local HUD not showing up when it should
• power profiles should now update menu text correctly
• moved vox filter interface from _obedience into _compliance to cope with enlarged command vocabulary overloading the index
• ERR send !release,ok in response to @safeword
• integrated HUD for akashic icon

8.4.0 milestone 2.1

• gender-q and gender lightbus messages; 610 (EFFECT_VOCAL) and 611 (SEND_GENDER) messages
• fixed missing menu graphics in manage > policy
• commands will automatically re-index rather than reporting 'command not found' if no commands are known
• HUD should now accept messages from non-controller peripherals; should make @rainbow work correctly
• menu states for _restraint options
• _foundation will now auto-boot after reset once _oem is done loading—let's find out if this is a bad idea!
• basic captive audio (audience); no point in using it yet, though; has the awkward habit of punching through intended deafness
• work on fixing xanadu 8.3 bug that prevents available updates from being displayed
• improved HUD efficiency; cleaned up possible sources of misbehavior e.g. stuck hovertext
• expanded 601 (QUERY_BATTERY) into DEVICE_QUERY so _sentinel can re-poll for HUD key

8.4.0 preview A (milestone 3)

• revalued jump to be 403 J/sec instead of 203 J/sec
• fixed a bug where rejected devices would install anyway
• removed 'keychain migrate' command: rarely used and upgrades from earlier than 8.2 can just install 8.3 temporarily if they really need it
• automatically add accepttp exceptions for owners provided the unit can teleport
• UPM CLI: @guest
• UPM consent
• UPM menu interface (included under manage > users)
• fixed 'previous' and 'next' buttons on user browser
• UPM integration for _restraint and _compliance::navigate
• UPM-authorized adding for light bus devices not owned by unit
• Renamed 'System' package to 'Companion' henceforth; added 'ATOS/E' package to list of updatables.
• UPM: owner-vs-object distinction (still has some bugs)
• ATOS real death (messages 905 and 906)
• Cleaned up bootstyle and boot sequence slightly

8.4 build 2016-06-01

• Added additional exceptions to guest access for controller and self access (when unit is own guest)
• Added default action selection: either accept (temporary whitelist) or deny (ignore access request.) Deny is the default. Asymmetric options are to minimize hassle required to fix the issue if the unit is AFK.
• require basic local access to control the dwm session - no more menu prompts for rejectees
• RLV relay should default to off!
• fixed guest access prompt for registered users; caused by keychain changes—cached permission bit now cleared before all keychain operations
• fixed "details" button not working on guest access dialogs for users (should have been "details...")
• fixed guest access prompts appearing for NULL_KEY and blank key
• added "!lamp on" and "!lamp off" for upcoming flicker script improvements
• fixed owners list not being cleaned after object transfer
• fixed badge clicks not working on _console-screen

8.4 build 2016-07-16

• re-fixed guest access prompts appearing for NULL_KEY and blank key
• resolved enormous and redundant lists of secure commands in the @commands index
• @audience; audience will now respect subsystem status and interference for hearing (still needs ERR integration)
• no execution of e_boot? issue seemed to go away when poked
• started implementation of chassis spec; _foundation and _power on stack-heap watch
• relocated whole remote control interface to _bonds because of running out of space in _puppet
• _puppet should no longer generate foreign device prompts for attachments

8.4 build 2016-07-24

• fixed faulty management of temporary whitelist and temporary blacklist causing stride corruption
• @range command for follow control; also @leash now aliases to @follow
• new order for subsystems: video, audio, move, teleport, rapid, voice, mind, preamp, power amp, radio in, radio out, GPS, identify. This will affect t3z's old power profile scripts for Arabesque. (They have been updated. Some may have changed a little.)
• switch to using list facilities for summing elements in _power
• chassis specification support: _foundation, _power, and _sentinel (ATOS/E 12.0.1) now all recognize a number of chassis options using messages 993 and 994 from _puppet (updated chassis controller module will be released soon)

8.4 build 2016-07-31

• resolved totally useless shutdown behavior
• fixed abnormal windlight changes during charging
• @policy command implemented; doesn't actually affect the system yet, though
• empty fields now hidden in @about; serial prefix is now "NS" for non-DAX and non-SXD units (otherwise still "SXD").
• @unleash to mirror @leash

8.4 build 2016-08-13

• '@persona probe' to force refresh of personas list
• XSU support

8.4 build 2016-09-10

• waypoint following should not set the device manager's follow target
• added xanadu 'cleanup' message to destroy dead package installers
• fixed '@navigate stop'
• added 100 kJ cap to @zap when _sentinel is installed (not foolproof; can cause disasters if multizap is used)
• fixed redundant dialog menus opening when touch screen is used (caused by conflicts in local guest access code)
• added optional header file for coilDDT so messages can be named
• menu controls for basic policy features
• local command input on /1, like OC commands (see '@commands local' and '@commands prefix')
• serial numbers not of length 9 will now be displayed without hyphens in the boot sequence and @about
• subsystem blocking by devices (proof-of-concept device: cortex)
• IRR policy control of subsystems, vox, apparel, and persona settings.
• beginning support for arousal model (not yet available)

8.4 milestone 5

• /1 command prefixes now forced to lower case
• curfew policy
• block follow and navigate while motors disabled
• restrict access to @restraint/@rlv (managers only)
• curfew time entry
• fixed a case where guest authorization was removing the wrong listeners
• fixed a case causing corruption of temporary white/black lists (numbers appearing in lists)
• require basic remote access to create a tty session - no more menu prompts for rejectees; unfortunately this means that old remote consoles (before 1.5) no longer work
• fixed a long-standing bug where changing @access settings would not clear cached permissions for last accessor
• don't ask for permission to respond to ! commands in RLV (??? seems to already be fixed)
• default to verbosity = 1
• IRR implementation: radio limitations (implementation restriction: clearing the user list can cause exceptions to linger until reattach)

8.4 milestone 6

• fixed HUD "0/-1" problems
• NRS: removed 'arrived at waypoint name' messages
• added subtle sound effects during _oem parsing to make it easier to diagnose hung updates
• Remote script execution
• Sync users

8.4 milestone 7

• Reapply restraints on relog
• Add semifreeze to bonds/power/coil
• Adjustable speed during navigation
• Tutorial
• beacon test mode
• beacon frequency
• capacitor charging
• permission exemptions
• timeouts
• control menu
• management commands
• block safeword with _oem switch
• Tutorial widget (HUD)
• Feedback menu
• Raise PONG_TIMEOUT to 45 sec
• Console attach in response to power off?

8.4 alpha 1

• Set @beacon and @aux to manager/owner only commands
• llList2List issues in local /1 commands
• '@optics apply' (for ATOS/E)
• Preserve manually-set !broken through teleports
• Fix inverted freeze/unfreeze light bus messages

8.4 alpha 2

• All subsystems blocked after removing a subsystem-blocking device
• no llSetTimerEvent() at all
• @navigate start <node name>
• Added menu chime schemes 6 through 9
• smarter #RLV management for consoles
• Support for chat power cost adjustments via the chassis controller
• Singularity detection (!!llTextBox!!)
• Add '@authority none' and '@name none'
• '@navigate start' should wait until arrival to trigger node
• Use '@navigate auto' even for nodes belonging to authorized users
• block send emotes
• block send whisper only
• Confirm ERR correctly detects user permissions when using @restraint command
• improve projector screen persistence
• fix 'commands' browser
• PIN locking should limit available /1 commands to unlock only
• Fix default position for segments to be less hostile to manual re-positioning
• Fix beta version display on menus

8.4 alpha 3

• Solve issues with inconsistent states in session creation queue
• Check cases of '@bolts auto' failure
• Proof of concept for foreign device consent interface: electrosense-powered door
• Switched to fartouch:2.5 for motor locks
• feedback for single-shot power loads (let devices ask for a pulse of power and get feedback)
• CB sends real-port instead of port-real
• performance overhaul to layout function
• 'allowed/forbidden' messages inverted for policies
• Fix behavior of missing buttons
• Mute 'session destroyed' messages
• Could not find notecard 'e_charge-start'.

8.4 release candidate 1

• domain functionality shakedown
• _restraint shakedown
• reimplement HUD integration API
• Add domain to @about
• Raised cached display name limit to 23 bytes
• Add CSU parameter teleport-recharge-time
• chatshout overrides chatnormal
• Fixed interference support for power-free (BaCdrive) models
• cortex strips persona folder on shutdown
• Protection against missing button labels
• Code modernization
• Encoding issues causing vanishing/imploding menu items
• Add blank items to devices list menu for spacing
• Code modernization

8.4 release candidate 2

• Audience respect for pertinent RLV restraints
• Added (( as an alias for ooc (note that this is usually intercepted by RLV)
• 'add' and 'remove' instructions in 501 EDIT_MENU
• Support 711 and 712 for system module removal
• ifexists for Arabesque
• Added @open command for triggering applications
• Added SET_SELF_ACCESS, removed SEC_SELF
• Ignore blank RLV commands