Thread by @NeoBokrug

(1/24) There's a super great upgrade coming to @SecondLife scripting, that I don't think is getting great attention it should. Before I go on forever about why this is great and will fundamentally change #SL please consider a retweet and maybe a like - to help spread the word. :)

(2/24) TL;DR: Jump to thread post (15/24).
Before I get really deep in to this, it's important to know where we came from with regard to SL scripting, and how the evolution of scripting has changed SL. This will be long, stick with me.

(3/24) In the early days of #SecondLife, scripts could only host about 16kb of instructions and stored information. They had minimal interactivity, and could really only communicate with other objects in the same region. If you wanted something complex, you needed more scripts.

(4/24) Features like XML-RPC and email communication with inworld objects eventually came in to existence. Most importantly it allowed us to save and pull data outside of SL; although a bit hack-y. All this was of course while scripts still had a 16kb limitation.

(5/24) Eventually the Mono VM was introduced to the simulator. This was both faster and more memory efficient for scripts running on a region. The biggest gift of this update was that scripts would have 64kb of memory to work with.

(6/24) Even after the Mono update, and consolidating lots of tiny scripts into bigger more efficient scripts; scripters in Second Life kept pushing the boundaries of what is possible inworld. Eventually projects became so complex and big, that multiple scripts were needed again.

(7/24) More features were added, and a few years later HTTP-OUT and HTTP-IN were added to the features scripters can use. This allowed for really nice and well known products such as Casper vend to flourish, by saving and recalling a lot of data to servers outside Second Life.

(8/24) Experiences were added, which allowed for automatic permissions grants if you opt-in once. One overlooked feature of experiences was the Key-Value-Pair data store. The KVP allows scripts to store up to 128MB of *persistent* data on LLs servers - no external servers needed.

(9/24) While the KVP system of Experiences seems like a gigantic boon, it comes with a lot of caveats: The land or region must allow the experience. The script must be compiled toward the experience. Not to mention you need to have a Premium account for an experience.

(10/24) Requesting, sending, and processing data from these sources comes with its own burdens; a common issue is where any "link" in the chain of requests fails - and then creating error handling and graceful fails for those events.

(11/24) Now we've got so many functions and features at our disposal, that we can highly optimize our scripts and use less of them. And we're to the point where objects in SL can know quite a bit about their surroundings, and interact with other objects or avatars on the region.

(12/24) Despite all the advances Linden Scripting Language (LSL) has made over the years, there's never really been a good persistent data storage option. If a script resets or crashes, any defined variables stored in script memory would be lost.

(13/24) Some tricks scripters have been known to use is to store persistent data on invisible hovertext, object descriptions, extra scripts for memory, and plenty more hacks. Point being - working with just 64k is hard. As an example viewing HTML for a single tweet is over 200kb.

(14/24) Then there's the issue with storing large unchanging data for script menus, static text, etc. I specifically made a feature request this year to expand the data returned from a notecard line from 255 to 1023 bytes, just so I could store more data outside of script memory.

(15/24) Coming very soon is a new feature called LinksetData (LSD):
wiki.secondlife.com/wiki/Category:…
It is absolutely AMAZING! In a nutshell it will allow us to store 64kb of Key-Value-Pair data on the root prim of a linkset. Why is this so amazing!?

(16/24) As I mentioned earlier storing variables and static data is a big bite out of our measly 64kb of script data. If we could move all that to its own space outside of what is used to process the script, then we can have that much more script to put functionality into.

(17/24) It's BETTER than experiences for most applications. You DON'T need to be premium. You DON'T need land set to an experience. You DON'T need to do anything special to use it. It'll just be there and available to *ALL SCRIPTS IN THE LINKSET*!

(18/24) In the event you need more than one script for your project, having the KVP data being available to all scripts in a linkset, means any script can add, change, or modify that data. Even 3rd part ones like plugins and APIs.

(19/24) The best part is that this data is PERSISTENT, even if scripts are removed or crash! That also means that you can shift-copy things, and copies of the data will also be on the new object.

(20/24) When you link two linksets that both have data, the simulator will try it's best to merge that data together. As long as it's not more than 64k in total you shouldn't have too many problems. The new root will be the master, and anything more than 64k gets discarded.

(21/24) When I heard of this new feature set, I showed up to the Server Inworld Meeting and said that password protected values in KVP would be nice to have, because there are times I want to release modify objects, but no-mod scripts. They developed that feature in A WEEK.

(22/24) Right now all of this is in testing on the beta grid. Persistent data is something that's been long desired for as long as I have been in SL, by anyone who does serious scripting. Dozens of JIRAs have come and gone, but this seems to be the best of all of them.

(23/24) Let me phrase it like this: When #SL got windlight, it was a big deal. When SL got mesh, it was a bigger deal. When @SecondLife got rigged mesh, it changed everything. This is as big of a deal as that was, but for scripting.

(24/24) I want to give my profound thanks to all the region/simulator developers. I know those office hour meetings can be hard, but I am grateful you listen to the users. If you the reader found this useful, please spread the awareness with a retweet. :D