Linkset Data (LSD) – a new feature for Second Life

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).

Hello, my name is NeoBokrug Elytis, and I’ve been a creator in Second Life since 2005, with a focus on scripting, project management, and exploring the bleeding-edge features of SL.  Today I’m a guest contributor here to tell you all about Second Life’s newest upcoming feature – Linkset Data (LSD). TABLE OF CONTENTS

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

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.

Lab announces Homesteads for Premium Plus, and some thoughts

via Linden Lab

On Tuesday, November 1st, 2022, Linden Lab announced that Homestead regions are now available to Premium Plus members directly from Linden Lab and without the need to hold a Full region.

The offering was first indicated as a “coming” Premium Plus benefit during the Lab Gab session with Grumpity and Patch Linden held on October 21st – see here for a summary of that event – and the November 1st announcement builds on this.

In short the details are:

  • Premium Plus members are now able to hold  one private Homestead region from Linden Lab against their account:
  • Regions can be requested using a Support Ticket via Tickets should:
    • Place an order via Land & Region → Order Private Region.
    • Provide a unique name for the region (in accordance with the region naming rguidelines) and a preferred location on the grid for placement.
  • The region can be held only as long as the member maintains their Premium Plus account. Should they downgrade to Premium (or any forthcoming Premium subscription level that does not include the Homestead “benefit”) or to Basic will lose the region.

There are no other changes to Homestead ownership, including the fact that anyone is able to own Homestead regions as long as there is at least one Full private region owned on that account as well, and pay the required fees.

Does This Make Premium Plus More Attractive?

Whether the ability to hold a Homestead region when taken on its own will make Premium Plus a worthwhile upgrade is questionable.

  • If you are not already a Premium or Premium Plus member, then looking at Premium Plus purely in terms of a means to obtain a Homestead region probably isn’t a worthwhile proposition.
    • When you add the minimum monthly fee for Premium Plus (US $20.75) to the Homestead region tier of US $109, it likely comes out to more than the monthly cost of renting a Homestead region from an established private rental estate.
    • Both renting privately and holding a Homestead via Premium Plus have the same core risk: paying the monthly tier.
  • If you are currently a Premium Member, then looking at Premium Plus purely as a means to obtain a Homestead region is a little less clear-cut.
    • On the one hand, upgrading to Premium Plus from Premium costs at least an extra US $12.5 a month.
    • On the other, this fee, plus the month Homestead tier will still be a competitive outlay when compared to renting a homestead through a private estate.
  • If you are a Basic or Premium member who already sees value in other Premium Plus benefits (such as the reduced fee for Name Changes, the other reduced fees, etc.), and are attracted to the idea of holding your own region, then upgrading to Premium Plus is liable to be worthwhile and cost-effective.

This last point is really the key to this offer: obtaining a Homestead is not the sole benefit available to those upgrading to Premium Plus, so it needs to be considered as a part of the overall package of benefits, and any decision made on upgrading should be made on that basis. For example, the option of holding a Homestead region is of little interest to me – but the forthcoming Premium Plus Linden Homes do. I’m therefore waiting to see what happens on that front before I make any decision on a potential move from Premium to Premium Plus.




2022 SUG meetings week #44 summary

Clair View Ruins and caves, The Realm of Rosehaven, September 2022 – blog post

The following notes were taken from the Tuesday, November 1st, 2022 Simulator User Group (SUG) meeting. They form a summary of the items discussed and is not intended to be a full transcript. A video of the entire meeting is embedded at the end of the article for those wishing to review the meeting in full – my thanks to Pantera for recording it.

Server Deployments

Please see the forum deployment thread for the latest updates.

  • On Tuesday, November 1st, the Main SLS and Events channels were restarted without any simulator update being deployed leaving them on simulator version 575585.
  • On Wednesday, November 2nd. simhosts on the RC channels will be updated with simulator release 576126, comprising the new Linkset Data capability (see below for more).

Available Official Viewers

No changes to the current set of official viewers at the start o the week, leaving the list as:

  • Release viewer: version – formerly the Maintenance M RC viewer –  promoted October 26.
  • Release channel cohorts (please see my notes on manually installing RC viewer versions if you wish to install any release candidate(s) yourself).
    • Maintenance P (Preferences, Position and Paste) RC viewer version September 19.
  • Project viewers:
    • Puppetry project viewer, version,  issued on October 12.
    • Performance Floater / Auto-FPS project viewer, version, October 4.
    • Love Me Render (LMR) 6 graphics improvements project viewer, July 21.

Linkset Data (LSD)

  • 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.
  • It works similarly to Experience Key-Value store, but:
    • It does not require an underpinning experience – the data lives with the object that sends and receives the data.
    • Only scripts in the same linkset will be able to read the data written with this feature.
  • Important Note for the initial deployment:
    • Like all scripts containing new LSL functions, scripts running LinksetData* calls will only run on regions running version 2022-10-27.576126 or newer (so only the RC channels to start with).
    • However unlike some other functions if you move an object containing Linkset Data (or teleport wearing an object containing Linkset Data) 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.
    • This limitation will no longer exist once the back-end support for the capability has been deployed to all regions on the Main grid.

llLinkPlaySound and Associated Functions

  • llLinkPlaySound together with llLinkStopSound llLinkAdjustSoundVolume and llLinkSoundRange are new LSL functions that are described as “coming soon”, and which allow sounds in child prims of a linkset to be played without the need for a supporting script.
    • Additional related functions might be considered if subject to a Jira feature request.
  • This is something that has been requested by content creators (particular vehicle creators) for a good number of years.
  • Flags included will be SOUND_LOOP, SOUND_PLAY, SOUND_SYNCH and SOUND_TRIGGER, and will be used to replace the llPlay/Loop functions.
  • Other sound restrictions within linkset remain unchanged.
  • The announcement spurred an extended discussion on the SL sound system as a whole (including pre-loading sounds), as well as options for the new functions, through the first two-thirds of the meeting – please refer to the video.
  • I’ll have more on the link sounds functions as and when LL have documentation on them and are ready to start deploying them.

In Brief

  • For a full (and maintained!) list of LSL functions,  please refer to the official wiki page LSL_Functions.