More than a few customers are, no doubt, wondering where ATOS/CX is, which was originally announced in 2018 and is mentioned on marketing material as recently as November 2022. Since shortly after the release of Companion 8.4, new ATOS/CX-centric features like module hibernation were developed and tested within the main Companion branch to assess their viability with a large audience. In some cases, these were successes, like the Native HUD, which follows many of the design goals of the promised ATOS SHIELD interface. But while we did make headway on actually putting together an ATOS/CX build last year, it eventually became apparent that more would have to change in the Companion software architecture than we had planned.
One: The lag problem
Customers and units familiar with the history of Nanite Systems robots are no doubt aware that development on Companion has slowed considerably since the release of version 8.4 in 2017. The six years after were largely spent looking for ways to reduce the drain on sim resources that the immense feature set of 8.4 caused. Like other large SL projects before it, Companion used a method of interprocess communication called link messages, which, although highly efficient for bulk data transfer, caused all the scripts in the same prim to process an event whenever one was received. Consequently, communication of n messages from one script to another in a prim containing m scripts caused O(nm) script events. This was particularly evident at company gatherings in late 2017, where a crowd of ten robots near a wireless charger could trigger upwards of 260 script events per second simply due to the charging process, even though only around 20 of those events were actually productive. The infamous rainbow color-cycling program could achieve even higher numbers on a single unit, easily using more script time than the rest of the region combined.
Companion is not the only project to suffer from this problem. Although smaller in scope, early versions of OpenCollar suffered from the same issue. Their solution was to partition scripts to minimize crosstalk ("OpenCollar Six"), with most of the key system components receiving their own prim. This idea has considerable merit, and lives on in the "Peanut No. 9" fork, but would not have scaled well to the complex interdependencies of the Companion architecture.
Although it took many iterations to develop, we eventually produced the Whip Microkernel, which achieved stability in 2018 and is now a familiar sight to power users of Companion 8.5 and 8.6. Whip introduced the practice of script hibernation: around half of Companion's core modules were converted into a format that could be suspended and resumed at will, preventing them from receiving link message events they weren't meant to hear. Unfortunately, scripts lose their memory if they are hibernating when the avatar moves to a new region or puts on the controller, so like a game cartridge, it was necessary to back up this data with an active element, the balance configuration manager.
Unfortunately, the combination of the already-mature OS being converted to use this new infrastructure, the intense flurry of activity caused by sim transfers, and the unreliability of link messages in crowded regions means that Companion-powered units are often greeted by unexpected color changes and the name NS 100-00-0001 whenever visiting a busy place. More determined customers have learned to live with the problem by ensuring that their units always reload the correct data in the event that the configuration manager is reset, but for all their tenacity they are still greeted by a system that is at times painfully slow—opening a menu on a physical screen, for example, can require upward of 10 sequential script calls as the kernel wakes multiple delegate libraries to check security permissions and generate the next menu state. (A similar nightmare explains why TESI has never been able to include permissions-checking.) While the design of the Whip kernel is a theoretical triumph, it is simply not practically useful for further expansion of the Companion ecosystem.
Two: Improvements in the Linden Scripting Language
In late 2022, Linden Lab released the llLinksetData (LSD) API, which allows objects to store up to (currently) 128 KB of text in a key-value store. The name comes from the fact that the data is stored as part of a linkset (e.g. an attachment), so all the parts of that linkset can access the same data. Critically, LSD allows for synchronous reading and writing of entries, so the entire requirement for a configuration manager or "memory" script is obviated—scripts can simply read and write whatever information they need. This improvement could theoretically be backported to Companion, but everyday use would still be hobbled by the "Catch-22" of performance issues described above.