Editorial note on Linkset Data
This capability was deployed to the Main Grid Release Candidate (RC) regions, which account for ~30% of the entire grid, on Wednesday, November 2nd. If all goes well, the capability will be available grid-wide after the deployments of Tuesday, November 8th, 2022. But until the capability is grid-wide, it is important to note that:
- The capability will only work on the RC regions where it has been deployed.
- If an object containing Linkset Data is moved (physically or via teleport) from a region that supports the capability to a region that does not support it, all Linkset Data stored with the object will be lost, even if you go back to a region that supports the feature.
- Therefore, until such time as functionality is deployed to all main grid regions:,
- The functionality should be used for testing purposes only.
- Products that use it should not be sold or otherwise released until such time as the Linkset Data functionality is grid-wide.
Update, November 15th: LSD functionality is available grid-wide on Agni (the Main grid).
I’m super excited about it, because I think it will forever change SL similarly in the way that rigged mesh changed avatars; but for scripts.
A Brief History of Scripts
In the early days of Second Life scripted content was crude and simple. All code, custom functions, and stored variables had to fit within 16 kilobytes (kb) – as that was the limit for scripts back then. For comparison, the HTML alone for viewing a single tweet is over 200kb, not including any images.
If you wanted a complex scripted object back then, you needed to add more scripts and use link-messages to communicate between the scripts. Think of it as a scripts-only chat inside an object where they’re listening and reacting to each other. It’s still used quite a bit today.
Back then and still today objects can communicate with each other using chat, typically on hidden channels. Another way objects could communicate was with features such as XML-RPC calls, and object emails. They were a bit clunky, hard to work with due to memory constraints, and required a bit of a hack-y solution to be practically useful.
Eventually Mono was introduced to the simulator to make scripts better. There were a few significant things that made it better than what we had been using. First, was the speed of script execution which was over 200x to 500x faster for math-intensive workloads. Second, mono could do byte code sharing — which means copies of the same script shared the same memory in the simulator; a gigantic advantage for SL. But the biggest gift of this update was that scripts would have 64kb of memory to work with instead of 16kb!
Even after the Mono update, and consolidating lots of tiny scripts into single but bigger and more efficient scripts; scripters in Second Life kept pushing the boundaries of what is possible in-world. Eventually projects became so complex and big, that multiple scripts were needed once again.
Over time more and more features were added to scripting, including a function for making HTTP requests. It allowed objects to have a shared memory on external servers. For example if you sold a game where it kept track of high scores across 100s of copies of the game, you could do that! But it was still an external server, so if there was ever any communication problem, or the server went offline, you had to write more code to gracefully handle those errors.
Fast-forward many years, and Second Life introduced Experience Tools. But the rub of Experience Tools is that you or your customers need to allow your experience on their land. And just to have an experience, you need a premium account. One less commonly known perk is that you can read and write key-value-pairs to a table of data associated with your experience. That table could hold up to a whopping 128 megabytes of data! So if you wanted to keep track of player scores across the grid you could, AND you wouldn’t need your own external 3rd party server. For example your key could be “player_uuid” and its value could be “player_score”. You could store this information with any object that’s on any land that is a part of the experience. Then anywhere else on the grid where the experience is allowed, another object could read or change that data.
Using HTTP and Experience Tools requires a set of connections in a chain of communication in that they both need to contact a server that is not part of the region itself. In my experience HTTP is a bit more fickle than Experience Tools because it has to travel over the greater internet, and you’re less in control of the hops it has to make to get to its destination. That’s not to say Experience Tools hasn’t suffered from SL grid-weather itself; but it still has to travel internally, so once in a blue moon there are a few issues. Not to mention the requirement of a premium account.
The Hacks We’ve Used (and Still Use)
The methods I’ve described so far all are good examples of how persistent data is traditionally stored, or data that doesn’t change after a script reset or crash. And for the most part, that’s been it – except for creative scripters trying to find solutions that don’t involve other servers. I and others have been known to use a lot of little hacks here and there, just so we don’t have to use external servers or experiences.
One of the earliest and possibly most well known methods is to save persistent data in a note card that a user can edit. But reading note cards is quite slow, and you can only read the data; you can’t ever write data to a note card. I know that sounds strange, so here’s a fun fact: Every time you save a note card it creates a new asset on the asset server.
Another option is to have another script just to store data. While it is faster than a note card, it is another script in your project which might just get wiped out if the script is ever deleted, resets, or crashes.
That begs the question; where else can scripters read AND write persistent data in an object? The object description of course! While the length of the data in an object description is limited to only 127 bytes (characters), it’s good for saving simple product configurations and user options. Most big projects in SL use this, including the well known and now Linden Lab owned CasperTech. There are a few more places to save persistent data including invisible hovertext, storing keys on hidden faces of objects, etc., etc. None of which are “private”, and may cause viewers to try to download non-existent textures. That last bit I’m not 100% sure of, but reasonably — it makes sense.
Overall, the hacks folks use only allow small amounts of data, could be slow, might just be an extra script, or might cause some problems here and there.
What IS Linkset Data?
So far everything I’ve described has some sort of gotcha or caveat. What I didn’t mention was that workarounds for all of those caveats typically take a big bite out of your measly 64kb of script memory. Despite a lot of JIRA feature requests to add persistent data storage over the life of SL, nothing has really come of it… until now!
Linkset Data is a new collection of script functions and one optional event that reads and writes key-value-pairs to a small 64kb table of data that is part of a root object. These new functions clear out a ton of hurdles scripters have faced, and solve some long-standing issues that SL scripting has had since the start.
Think of it as an invisible table of information that travels with the object, except that only scripts can read and write key-value-pairs to it. Because this data is now part of the object itself, it doesn’t need to rely on external servers. It also doesn’t add any script time or script memory to the region because it’s not a script. It’s just a small ledger of information the object carries with it.
During the Simulator User Group meeting, it was asked if this data could be protected because some creators like to give out modify objects, but not modify scripts. It took less than a week for the server developers to add llLinksetDataWriteProtected and llLinksetDataReadProtected to the feature set. The way this works is the data is protected by a password. If you try to read, write, or delete it without the password, nothing happens (note: at the time of writing, the protected functions are not listed in the wiki article). It should be noted that the data can still be deleted with llLinkSetDataReset, which purges all the data in the linkset.
You may be asking, “Well what happens if I have two prims with Linkset Data on them, and I link them together?” The Lindens thought of this and here’s what happens:
- The new root becomes the new Linkset Data, and all data on other links in the newly formed linkset are checked for duplicate data which is discarded.
- Remaining data in child prims is then merged to the Linkset Data until the 64kb limit is reached, where after more data is discarded.
- In summary, it imports what it can up to the 64kb limit.
If you boil it down it all sounds real simple, but it’s probably the biggest and most impactful change to scripting in Second Life since HTTP requests were introduced!
How Will It Change Second Life?
Most importantly, Linkset Data is persistent. A script may be deleted, reset, or crash, but it won’t clear out the data. It’ll still be there for whenever a script needs it again.
LSD is better than Experience Tools because it doesn’t require a premium account, and doesn’t require land to allow an experience to run. It’s better than HTTP for certain applications, because there’s not going to be any communication errors in accessing the data. It’s better than note cards and all the little hacks we use now, because it’s crazy fast, and doesn’t require a lot of code to read and write data. In testing, it’s been reported that there can be over 6,000 reads and writes per second to the LSD.
We won’t need little “memory-bank” scripts or note cards to store large swathes of unchanging data. For instance in The Wastelands I have non-player characters NPCs that have dozens of lines of text stored in a script which easily takes up most of a script’s memory; now I can just store all of that as key-value-pair data!
All scripts in the object can access the data stored in the LSD – and the fact that any in the object can, and can modify the data in a linkset is a complete game changer. One of the causes of simulator-side lag is the volume of “Script Events per Second” (“eps”) it has to manage.
To explain: whenever a script has an outside influence that it’s waiting for, it will trigger an event; this can be as simple as hearing chat, being touched, or as complex as getting information from a HTTP request. An object can queue up as many as 64 events before they begin to be discarded. Currently, many objects in SL (vehicles being a good example) relay on link message events: the control scripts in the root of the object which send messages to the scripts in other prims in the object, which have to listen for them; so if the object has 10 links all listening for messages from the root – that’s 10 script events. Using LSD could eliminate those link messages entirely, helping us remove some of the load from the simulator!
If all this script talk seems overwhelming; let me phrase it like this: When Second Life got Windlight skies, it was a big deal. When SL got mesh, it was a bigger deal. When Second Life got rigged avatar mesh, it changed our in-world appearances permanently. This is as big of a deal as that was, but for scripting.
As of now, these new features are testing on the beta grid. They might be on the Release Candidate regions by time this article is published, which means that this new set of features should be on the main Second Life Servers within a couple of weeks, assuming that there are no issues with the project. I’m super excited!
I want to give my profound thanks to all the Linden region/simulator developers. I know those office hour meetings can be hard, but I am grateful you listen to the users. I want to thank Inara and Pantera for dutifully keeping track of all the office hours, and the opportunity to write this article. This all started out as a long tweet thread when I got excited about the feature!
About NeoBokrug Elytis
NeoBokrug Elytis (“Neo” to his friends) has been active in Second Life for 17 years. He has defined his time within Second Life in many ways – as a creator, a region designer, a community builder, a teacher, and an innovator. His passion for the platform has remained constant throughout his time in-world, where he has not only founded (and continues to play a lead role in managing) The Wastelands, the largest post-apocalyptic community in Second Life, he has also provided services to third-party organizations as a recognized Second Life Solution Provider.
This service, offered via his business entity, Desolate Studios, has enabled clients like Brooklyn Law School establish a presence in Second Life, as well as being contracted by the Electric Sheep Company to develop their 2007-2008 multiplayer first-person shooter and role playing game, Survival: I Am Legend, designed as a tie-in to the 2007 Warner Brothers motion picture, I Am Legend, which starred Will Smith.
Today, Neo continues to provide help and support to organizations wishing to establish a presence in Second Life, as well as continuing to help innovate the platform through the submission of considered, well-documented feature requests, many of which have been accepted and implemented by Linden Lab.
Inara Pey: Living in a Modemworld 