[Limiting a Script to work only on a specific sim/estate]

Instead of a timer, could use a CHANGED_REGION changed event.

["Linkset Data" is coming.]

On 12/3/2022 at 12:12 PM, primerib1 said:

Can't open it.

What characters?

U+0001..U+0008, U+000C, U+000E..U+001F

A bunch of ASCII control characters. This affects use in values too. You can use these characters fine, but it will become unrezable, which is kinda a problem. 

["Linkset Data" is coming.]

We all missed a bug testing this back on Aditi.

Rezing and attaching break if the LSD store has key(s) containing certain characters.

https://jira.secondlife.com/browse/BUG-233015

[Mainland tier fees lowered?]

47 minutes ago, Qie Niangao said:

Yeah, it's disappointing. Also, at some point (when you're already at a full region, maybe), it reveals that the next step is 1¼ regions (81,920 sq.m.) for $208, which used to be $219, for a 5.29% reduction.

It's nothing new, but that region-and-a-quarter pricing remains a huge disincentive because the step from 1 to 1¼ costs $42, whereas the step from ¾ to 1 costs only $24. Even from ½ to ¾ costs less, at $39.

What I think is going on there is that they're aiming for a constant average cost per area ($1.30 / 512m²) for the total amount owned, same as for a full region, but that's sure not how it feels, having to pay 175% as much for that next incremental ¼ region compared to the previous ¼ region step.

I'd seriously consider tiering-up with the lower fees but man, that next step is a bitter pill. If they instead held constant the incremental cost per area at $24 per ¼ region, that next step to 1¼ would total $190/month, which "feels" about right to me, but would lower that average cost to only $1.19 / 512m² for the total area.

Yeah... tier pricing has always been kinda screwy. Linear discount across the higher tiers would better than current, though it would be preferable for that to be at least slightly better than a non-linear increasing discount. Would be nice to have incentives for increasing parcel sizes to both soaking up more of all the spare mainland and reduce region load. I've seen a number of regions that are half abandoned with the occupied parts chokers with stacked skyboxes.

[Mainland tier fees lowered?]

Quote

we’re lowering the price at 1/8 region (8,192 m2) and higher by over 10%.

Umm... I think either the wording on that might be a bit wrong or there was an error in the price changes. Only 1/8 and 1/4 are currently fitting that description.

Fraction	Size	Old	New	Change	% Change
1/128	512	$4	$4
1/64	1024	$7	$7
1/32	2048	$13	$13
1/16	4096	$22	$22
1/8	8192	$35	$31	$4	11.43%
¼	16384	$67	$60	$7	10.45%
½	32768	$112	$103	$9	8.04%
¾	49152	$150	$142	$8	5.33%
1	65536	$175	$166	$9	5.14%

[How to stop media player from appearing?]

If you are wondering how these are randomly getting created, its likely from accidental drag-n-drop of text which lands on a modifiable object face. I'm not sure why that is a feature.

["Linkset Data" is coming.]

On 11/10/2022 at 11:45 AM, Kehf Nelson said:

1. I know the correct answer to my "When?" question here is something like: "I'll be ready when it's ready..."

But what's the "best guess" to when LSD will work grid wide?  Mid 2023? 

2. How much faster or slower are we thinking LSD will be compared to Desc strings on "settings" linked prims?  

3. How bad of an idea would it be to use LSD for link_set object communication vs link_message for larger strings/data?

4. Feature Creep, don't suppose we could get a llDumpLinkSetDataToJSON() and llParseJSONtoLinkSetData() too? 

---> Shameless Plug https://github.com/knscripting/Simple-KVP-Node-for-Secondlife

 

2. I didn't explictly benchmark that, but from just my benchmarks of LSD alone, I'm gonna guess that if there is a difference, it's likely less than measurement tolerance plus script time variance. LSD is about as fast as working with data in lists, but uses less memory.

3. If your link message is purely updating variables in another script, LSD fully supplants that.

If the other script needs both updated stored data and the event, then the LSD update event will work with some caveats. The event only fires when the value actually changes, so if you need to always fire the event even when the values may not actually be different, you'll need to use something like a nonce.  Also, the event will fire any changes for all scripts with linkset_data, so extra filtering code may be needed.

4. The input and output string vars of those functions could easily be too large. Application specific implementation of such functionality would be pretty simple to add ourselves.

FYI, you can do similar functionality to your Node based KVP with just a Google Sheet and some GAS scripts for a basically server-less setup. :p

["Linkset Data" is coming.]

On 11/6/2022 at 1:34 PM, WolfGang Senizen said:

Depending on the whole external accessing of LSD this might not be so necessary, but a function I'd like to see would be
 

llRezObjectWithData(object,pos,vel,rot,param, ["key1","val1","key2","val2"]);

 

Would be useful to rez a configured object, rather than the current, rez, wait for event, and handle messages to pump config into rezzed item.

Also, that maybe read write and delete should have been overloaded with a list instead of adding protected versions of the functions, allowing for easy future expansion without more functions requiring multiple variations, e.g.

llLinksetDataWrite(key, value, [LSD_PASS,"secret", LSD_PUBLIC, TRUE]);

The same for read/delete obviously... (though some options may not apply for all)

Instead of exponentially more new functions in the future.... with the current scheme if the scope were to be increased.

llLinksetDataWrite(key, value);
llLinksetDataWritePublic(key, value);
llLinksetDataWriteProtected(key, value, pass);
llLinksetDataWriteProtectedPublic(key, value, pass);

Could also be further expanded to accept a parameter like LSD_TARGET_ID to allow reading a remote object in the future, with or without pins or whatever is decided (but pins seem superfluous to me given we have passwords already), though some form of secondary functions for that may be more on form with the key being the first proper argument, not a parameter in the list.

I'm still hoping to get at least remote-same-region read.

Write would be cool, but with just read we could expand on many of the low latency interactions we were discussing on the #scripting Discord the other week.

["Linkset Data" is coming.]

6 hours ago, Wulfie Reanimator said:

Changes made to attachments are not committed until they are detached, so when you crash hard enough (not just logging out or getting disconnected), the normal "save on unrez" process doesn't take place.

You can, for example, change the texture on an attachment and then make copy the inventory item you're currently wearing. The copy you've just created won't have the changed texture, it's a copy of the attachment before you put it on (including script state).

It should follow that LSD will behave exactly the same.

The old inventory object verses asset object differences. Outside of viewer dev and this behavior, nobody really needs to care that difference as you'll basically never need an inventory ID for anything.

This behavior does come in handy sometimes, for instance, when needing to undo changes to an attached object, can just make an inventory copy of it while still attached to get point-in-time copy from last detach. That's saved me a few times when selections do wrong and the original textures aren't available for restoring. (Though generally its a good idea to be working with a copy from the start instead. lol)

3 hours ago, Anna Salyx said:

I understand academically how/why it a happens but I can't really understand the "why" of it.  Certainly a region change should be enough to trigger an unsaved state commit. I get it if i crash on teleport right after changing something that things will revert. But if I've hoppiting and boppiting around the grid for a dozen or more regions certainly somewhere along the way a unsaved changes commit should be triggered (in my mind on the first successful region change).  I also get it if doing unsaved commits on a timed schedule might not be desirable, but why not on teleport? I mean it's functionally a detach/reattach event since things can 'fall off' during the processes. 

(and yes, I'm sure there is probably a good reason, but i can grumble about the general unfairness and hostility of if all just the same).

Inventory storage (asset servers) is a completely separate thing from simulator memory. Rez'd assets live in the later and get passed from region to region as needed. AFAIK, committing objects in to inventory storage can only happen on take (create) and detach (replace).

The asset servers already do a lot, not sure extra delay of committing back every TP/region cross would be something we'd want. If you are worried about loosing changes from a TP fail, just cycle the attachments after editing. I used to do that regularly back in the day, but TP fail is a lot less frequent now.

["Linkset Data" is coming.]

On 10/24/2022 at 5:29 PM, Rider Linden said:

Which of those two would people prefer?  

1. linkset_data is thrown even on a "trivially" successful operation. 
2. linkset_data is thrown only when there is a change to KVP data. 

I'd prefer #2

if some usecase needs the event on all commits, that KVP really should be using a nonce.

On 10/25/2022 at 12:01 AM, Love Zhaoying said:

Ok, had to read back: "no change" meaning, an LSD KVP update resulted in no update because the KVP didn't change? Well then, if that's the case, we need to tell everyone, "HEY!! Hey hey heyyyy! One of the links tried to update this here KVP, but the value did NOT change!" Because that way, the script that needs to know can stop doing whatever it would have done if the value HAD changed. 

Use a nonce.

On 10/25/2022 at 3:41 PM, Lucia Nightfire said:

Except when Oz ordered llSetPrimMediaParams() & llSetLinkMedia() changed to add url schema enforcement. 😉

I still haven't fully recovered from that... At least I got them to setup a temp region without that change so people could recover data that got locked out.

["Linkset Data" is coming.]

On 10/22/2022 at 10:22 AM, Jenwen Walpole said:

Because you can have so many keys, it be nice if you could just enable/disable events on specific keys. 

Also along those lines perhaps the abilty to enable / disable all linkset_data events so that when your doing mass updates to many keys your can disable generating events.

Thoughts?

I was actually thinking similarly. But instead of the mess of duplicate functional, maybe a flag param, which would also allow for additional functionality in the future.

On 10/22/2022 at 1:09 PM, Qie Niangao said:

Although, as I recall folks mostly wanted to be able to subscribe to specific values of the integer num parameter, to avoid spreading scripts around the linkset and targeting links specifically, to reduce the number of scripts waking up for irrelevant messages.

That would be extremely nice to have. If num could be a range or better, a bitmask, that would be cool. Gimme gimme~

On 10/22/2022 at 1:09 PM, Qie Niangao said:

(That said though, I anticipate only rarely handling the linkset_data message at all, favoring a link_message with more specifics from the sender about where to find changes in the linkset data store.)

Mostly ditto here. I don't see using the LSD events much, but far less likely if all scripts using it are going to every LSD event.

4 hours ago, Nika Talaj said:

is there any indication in the build menu that an object is already using LSD?  

I see it as a quick way to warn amateur scripters/builders like myself that they might want to take a a little care re-linking or adding more LSD usage.  [Yes, I know, one could always dump in a little script to check available space.]

Forget the "amateur" part, you'd have to already know the object has an LSD store or explicitly check for it via a script.

I second this as a "would be nice to have". Could be added conditionally to the contextual selection_count field that shows num objects selected, land impact, etc. Could display something like "X LSD keys in Y objects" where X is the sum across the selection if >0.

13 minutes ago, Jenwen Walpole said:

what i think would be an easier to implement and more flexable soltuon is to have write and delete fuctions that do not generate events. so you can simply use those fuction when nessisary and still have events when you want / need them.

 

["Linkset Data" is coming.]

2 hours ago, Jenwen Walpole said:

great work kahda,

one of the things i am curious about is if the amount of space  effects performance at all, though i suspect it will have no impact.  I mgiht check that anyway.

i also noticed perormance variations run over run. when doing them conscutivly .. i just asumed that it was the luck of the draw on the slicing and other thigns takign up scipt time.

I see the iops go down as expected as the data size goes up..but the bps goes up.  it be interesting to graph for the bytes per sec or kbps.  I .just did a rough calcualtion for  and if my calulations are right you were about 10x higher data thoughput at 1024 over 8 bits, even though the number of operations/itterations droped to 1/10th

 

 

I would think worst case impact would be less than one additional idle script.

That very likely just script-time variance. I ran more and longer ones and the averages were pretty much in the same ranges.

I have no idea what the internal structure of the store is like, but there seems like there may be some sort of difference after/around 64 bytes. There's going to be many trade-offs to using longer single values: more storage for values, higher access times, more script mem, more script time in parsing/serializing, etc.

Any case, still far less punishing/limited that Exp KVP. LSD has far more usage potential than just a local KVP store, it can pretty much function as a list of strings on its own stack.

["Linkset Data" is coming.]

9 hours ago, Jym Nova said:

For a use case such as cache, you could simply just store those values like normal, ( llLinksetDataWrite ), and for your functional values use protected ( llLinksetDataWriteProtected ). Then just run a loop to clear the "cache".

clearCache(){
    list my_list = llLinksetDataListKeys(0,-1);
    integer i = 0;
    for(i; i < llGetListLength(my_list); i++;){
        llLinksetDataDelete(llList2String(my_list,-1)); //using "-1" for hopefully obvious reasons
    }
}

It's not perfect, but it'll get the job done.

(Of course I would hope that if protected keys are returned they would silently fail with this example to not stall the script)

Ignoring that my_list could easily be larger than the current free stack, for stuff I might do, a for loop of 10k+ iterations would not be ideal. 

Locked with public key would work though.

4 hours ago, Jenwen Walpole said:

wow ... it is a LOT faster then i expected.

back of the matchbook testing ot me 1,000,000 copies of a 10 char linkset data to a local var in 0.085416 milliseconds and just for fun, becase it was so fast i did the same copy but from global to local var in 0.000156 milliseconds just to see the comparison.  ymmv

This is going to repalce a lotta link message stuff i am doing and config file handling.  PLUS the extra fuctionality of persistant data and more var space. .. my head is spinning wiht ideas

I did some benchmarks on earlier pages, though I think I may have only posted the chart some of that on the Discord.

Value length in bytes (from 8 to 1024) verses write+read cycles per second. Each point measured 2,000 iterations. Consistently there is was a odd-even pattern (might be the regular LSL time share kicking in), so for 2 of the 4 runs, did an extra 8byte run at the start (that was discarded) to see if the odd-even pattern was unrelated to the value size, which it was.

I did not explicitly check (yet), but this might be pretty close to using lists.

["Linkset Data" is coming.]

If we're gonna have delete protect on locked, can we have optional protect on non-locked? I'm seeing a use-case where LSD is used for cache and reset is used to quickly clear all the keys in the cache portion. That would be possible with locks though, would just have to document the pass somewhere for keys to function as public. Not sure if all the search functions (can) work on locked keys however, as that could be a hindrance.

I'd still enjoy LSD stores on child links, not just the root, to completely side-step the merge and conflict issues. But that's me and I'll probably use that for more novel uses, like massive L2 cache. x3

 

Gonna keep hoping for remote (same sim) sync read access. The immediate use-case we have is allowing for greater flexibility for low-latency interaction in games.

Right now we use object descriptions, which is painfully limited to 127 bytes. The main thing is that this does not require a back and forth comm between the object and HUD, nor using sensors in the game world objects. Many objects types don't need any scripts for this to work, just the correctly set desc string, and the ones that do, don't need to have a lot of duplicate game logic.

The HUD does 2 short ray traces and if the object is different from last, reads the description. A down trace sees what the avatar is standing on, this is for stuff like footstep sounds based on ground type.

A trace along the mouselook camera forward vector gets what the being directly looked at for a wide array of custom interactions. Things like "look at ladder, press action key to grab, use ladder like every video game since there have been ladders in first person games" and the ladder can be scriptless, so adding more only has LI cost.

Yeah... you could somethings with touch and/or collision instead, but then every obj needs logic to handle when its ok to be touched, or the player HUDs have to deal with even more incoming comms processing and filter out stuff like when a player is trying to shoot/cast but their cursor was over a touchable obj across a room. Collision is good for game event triggers, using it for the things like footstep sounds would make it not worth doing. For the most part, using chat comms for everything adds a lot of latency and failure points (ie. 2 generals problem, etc), there's a lot of cases where only one side needs to know or do anything and having to needless make that a two-way conversion handshake is painful.

Video demoing some of this. That game is NSFW, though there is nothing above PG in the video.

 

["Linkset Data" is coming.]

6 hours ago, Wulfie Reanimator said:

It wouldn't be ideal for scripts to be able to hog the entire data store, either maliciously or by accident (such as changing and/or forgetting what password you used, or accidentally creating protected keys and forgetting to remove them). The protected keys shouldn't be permanent, so a function like llLinksetDataReset should be able to get rid of all data.

The protected write/delete functions have their use for managing individual keys. 🙂

It should also be noted that making a new copy doesn't get rid of any keys, those get copied too.

If I have an mod object I want to reuse without its scripts, it would be nice if part of the LSD store isn't locked off from an old script. And if there is some other function like llLinksetDataResetButAlsoLocked(), then that function will probably just get used instead of llLinksetDataReset() and its the same problem.

5 hours ago, Lucia Nightfire said:

This allows a mod product's end-user to add their own links/scripts/functionality with their own storage with their own passwords and keep existing scripts "happy" while also preventing existing scripts from accidentally/intentionally breaking things without having to go "all-in" and reset data.

Granted, an application's protocol could have still been set up to wipe all data naturally/occasionally and without being nefarious or to satisfy a previous owner's control.

It's like multiple people living in a dorm, respecting each other's space and property and not kicking each other or their property out. Coexistence.

It's also like the "Good fences make good neighbors." proverb.

This is the same type of thing as the existing issue with scripts with incomparable link messages.

"But just put those scripts in another link", sure as long as they use link_this, but then the LSD store conflicts could also be avoided by child links being able to have their own stores.

["Linkset Data" is coming.]

29 minutes ago, Rider Linden said:

The RC channels on Agni. But I need to convince QA first. 😉 

Tell them they can either QA this or PBR this week. :v

["Linkset Data" is coming.]

1 hour ago, Zi Ree said:

llLinksetDataReset() helps here.

Someone(s) was requesting that llLinksetDataReset() doesn't reset locked keys.

I disagree with that as well. If its mod and I now it, I should be able to break it.

["Linkset Data" is coming.]

10 hours ago, Jym Nova said:

Pretty sure my concerns have been addressed one way or another. I just want it live on Agni now. LoL

Except that whole "crashes the region on key doesn't exist" thing.

["Linkset Data" is coming.]

9 hours ago, Jenna Felton said:

I think most of what was asked here can be done by using a script in the linkset and using it as an API: Chat messages for access the store from outside and link messages to access from within the link set (when the keys are protected). The script would respect the access level of the keys and allow or block the operation request.

Except chat messages aren't fully reliable.

9 hours ago, Jenna Felton said:

As for viewer access applications. For example the viewer could store the last region and last position under keys "viewer.last.region", "viewer.last.position". Then not only firestorm will be able to rez the object at the position it was picked up and even then when the object was picked up with an other viewer or by someone else (when the keys remain stored.) Also, every TPV could then store the own information into the LSD store of a linkset under their own main prefix.

Pretty sure that's gonna earn a special meeting if a TPV releases such and not cleared with LL first. :p

["Linkset Data" is coming.]

11 hours ago, Jenna Felton said:

Thank you Rider, having protected keys is cool, but I'd like to have a way to get access to protected keys to some degree without having a password. Because there are applications extensible via plugins, be it scripts installed into the application or (never seen but possible) linked to core prim. The core script and the plugin script can be by different creators.

Now the core script may want to maintain some keywords while plugin scripts would have only read access to them unless the developer or the core script made the write or deletion password known to the plugin script.

I would suggest to create protected key like this:

llLinksetDataCreateProtected(string name, string pass, integer level);

while level defines if the key is read protected, write protected, delete protected.

• Write protection inherits read protection (read protected key needs password to be changed)
• Delete protection inherits read and write protection.
• Write protected keys can be read without password but not changed
• Delete protected keys can be read and changed without password but not deleted.

Edit

Better to separate creation of the key and actual writing because this will avoid to change the protection level every time you change the content. After the key is created it can be changed via llLinksetDataWriteProtected as defined.

 

 

 

Much of this would possibly be better implemented as a custom link_message API instead.

Read-only keys could be handy though. More so if we get remote access from other objects (unless that is purely read-only).

8 hours ago, Jym Nova said:

This is great to an extent, I was going to say, I read through the first 4-5 pages and didn't see my concern(s).
Of course I'm not seeing the details of the 3 new added functions either.

I strongly disagree with "Protected keys are removed by a call to llLinksetDataReset."
Maybe negate protected keys & values by adding: llLinksetDataResetProtected(string pass);

#1 is Security, should I decide to distribute a "modifiable" object, anyone can read the data.
`llLinksetDataRead` which appears you have managed a solution: `llLinksetDataReadProtected`
What about: llLinksetDataListKeys? are protected keys negated or still fed in to the list?
> Not good if the data is meant to be private.
(I foresee this being great for HUD's though, since they will almost always be no modify)
(I don't care if they want to count how many keys I have or know how much data is available)

#2 is Persistence, should I decide to distribute a "modifiable" object, anyone can wipe the data.
> Not good for modifiable objects if you want persistent data.
`llLinksetDataReset` currently would wipe all data, even the protected keys.

If a resident has mod on something they own, they have the right to break it. We kinda don't need more slam bits.

["Linkset Data" is coming.]

Did some more testing, here's what Unicode doesn't work since I'm guessing there's at least a few here who are gonna try doing something silly at some point.

U+0: Null. Cannot be in LSL strings, ever.

U+25C8 and up don't work in keys. That's an odd point for it to stop, mid way in to the Geometric Shapes block.

U+FFFE and U+FFFEF both return U+FFFD, which you shouldn't use either (is the "replacement character"). Generally just don't use the whole Specials block (U+FFF0..U+FFFF)

U+D800..U+DFFF are the high and low surrogates. Its UTF-8, you can't use those values on their own. Doesn't work in LSL strings anyway.

U+110000 and up don't work in LSL strings. Unicode reasons.

If you're going to try to encode data to save space, you're better off using BASE64 for speed or BASE127 for maximum packing. Higher bases will actually use more space due to UTF-8.

So if you need a special character for key prefixes or whatever, it appears anything from U+1 to U+25C7 are usable.

 

I do love the speed of LSD. Its nice to have something new that will be useful but has is also not been kneecapped with highly restrictive bottlenecking.

Exp KVPs could have been handy, but between the land scope requirements and async, it really makes it hard to find applications for it. Despite having access to 4 or 5 exp keys, I have yet to have some use for exp KVP. When the land scope isn't much of a problem, the async then makes http an option to consider. x3

2 hours ago, Quistess Alpha said:

If you expect a single key to maybe have data, couldn't you just use llLinksetDataRead() ?

If I'm searching for something, I would expect the possibility of multiple matches.

I was gonna say. There seems like there is zero utility in doing searches for an exact key match when you can just try reading the key directly.

["Linkset Data" is coming.]

47 minutes ago, Rider Linden said:

Protecting a key incurs a 32byte overhead in addition to the value and key length. 

That is a reasonable trade-off. Awesome

["Linkset Data" is coming.]

9 hours ago, Jasdac Stockholm said:

I feel like this would be significantly more useful if we had a way to remotely access said data. One of the biggest issues when making games in SL is trying to sync data. Like trying to sync player HUD UUIDs in an active game between a multitude of HUDs. With an object description, you're limited to 3 UUIDs. Using the chat system to do that is laggy, async, and prone to events being dropped. The #1 issue when developing large games on SL for me has been to keep things synced.

What I'd like to see is something similar to remote loading:

llSetLinksetRemoteDataPin(int pin)
llRemoteLinksetDataRead(key uuid, int pin, string name);

And if the wrong pin is entered, do the same thing as llRemoteLoadScriptPin and sleep the script + delay.

That way you can pass the pin using messaging or if you want it to be public, just use a constant number.

I don't see the value in being able to write from another script, only read. While previously using prim media URLs to sync data, the best design has always been to assign write permissions for specific values to specific scripts, then using link messages or say messages to have that script update the value. Otherwise you have to battle race conditions.

4 hours ago, Jasdac Stockholm said:

While we're spitballing ideas anyway: Another benefit of allowing remote linksets to fetch data is that it allows the community to set some standards for metadata. Perhaps a PIN of 0 could be used as a "my data is public, please read me" setting. Trying to read from PIN 0 on a linkset would just return an empty string and not throw an error.

TL;DR: by using metadata and a HUD for interactions, you can remove a ton of scripts from your world objects when making experiences, games and such.

Per KVP/row pins/passes would be good for this usage. Exposing just the rows needed with granularity.

Going with the game example, an object could have data that all other players' hud can access under one pin, data that only other team memebers' can access under another pin, a another pin that is a constant which forms part of a public API for third-party extensions (like public score boards, telling if somebody is in game, etc.), and everything else in the object's store as private or shared with links within the hud.

For remote access, read-only would be completely workable as each object could read from each other. I keep saying this... the same limits as llGetObjectDetails on where it can work are fine.

Right now, a lot of time, script time, sim time, and especially dev time is spent just getting data from one script in to other scripts.

I've had many projects balloon and eventually die due to rabbit-holing trying to make effective data serialization.The last few I seriously put effort in to (which was many years ago), couple/few weeks was spent on the actual proof of concept, but then many months to most of a year on just data packing and script-to-script messaging, which eventually results in abandoning when the partly working solutions to that core functionality become so complex that adding anything without starting over from scratch is now impossible. You almost have to hyper-optimize first just to get running, or just give up and do it all remotely on a web server while compromising on many ideas for real-time/low latency features.

The joke would be "fast, efficient, reliable; pick two", but usually it's "pick one as long it you pick low memory usage", because all roads lead to string parsing due to the lack of native data types in comms and script mem being highly restrictive even if the script purely dedicated to only serialization and comms. It'd be pretty much unpossible to implement something like ACK to deal with the random comms dropage problems without some steep trade-offs.

There's the potential that LSD could resolve many of the brick walls LSL has with storing and moving data around. As it is right now, its fixing a few, like having to make stored data as compact as possible. Buuut it'll be more awesome if takes away the months of creating project specific custom data (de)sterilizers/protocols and supplants it for using a handful of new llfunctions with much faster type recasting.

[Deploy Plan for the Week of 2022-10-10]

Here's the link to the work in progress wiki page for Local KVP / Linkset Data

["Linkset Data" is coming.]

19 minutes ago, Fenix Eldritch said:

That did come up during this week's server meeting (and in fact commanded a large portion of the conversation). I believe Rider said he was going to experiment in adding the feature, with a lean towards an additional set of read/write/delete functions that required an integer pin (that way you wouldn't lock out the entire store). Some suggested using a string for a passphrase, but if that happens, Rider said he'd count those against the store size.

Passphrases counting against the store was what I was expecting.

Per row locks would be ideal, so that's good to hear.