NeoBokrug Profile picture
Oct 19 24 tweets 6 min read
(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

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with NeoBokrug

NeoBokrug Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @NeoBokrug

Nov 20, 2020
@ebbealtberg The Good (1/2): Region Crossings and Teleports are better in general, hands down. Region performance regarding scripts is better in general! That's super great and I love it; I look forward to more performant changes like this.
@ebbealtberg The Good (2/2) I'm super grateful everyone who worked as hard as they did to tackle the HTTP issues and Experiences-KVP things that were brought up. They seem to be a non-issue now, and it's kind of amazing to see LL work this fast on bugs like that.
@ebbealtberg The Bad (1/2): Region performance for scripts still remains an ongoing issue. It is certainly better now, but still has the same issues from early 2019. Specifically the "Scripts Run" stat and Script Time/Spare Time. The longer a region runs, the worse it gets.
Read 8 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Don't want to be a Premium member but still want to support us?

Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal

Or Donate anonymously using crypto!

Ethereum

0xfe58350B80634f60Fa6Dc149a72b4DFbc17D341E copy

Bitcoin

3ATGMxNzCUFzxpMCHL5sWSt4DVtS8UqXpi copy

Thank you for your support!

Follow Us on Twitter!

:(