Kadah Coba

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

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.

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

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.

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%

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.

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

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.

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

I'd prefer #2 if some usecase needs the event on all commits, that KVP really should be using a nonce. Use a nonce. 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.

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. That would be extremely nice to have. If num could be a range or better, a bitmask, that would be cool. Gimme gimme~ 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. 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.

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.

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

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.

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

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

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.

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

Except chat messages aren't fully reliable. Pretty sure that's gonna earn a special meeting if a TPV releases such and not cleared with LL first. :p

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). If a resident has mod on something they own, they have the right to break it. We kinda don't need more slam bits.

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

That is a reasonable trade-off. Awesome

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.

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

Passphrases counting against the store was what I was expecting. Per row locks would be ideal, so that's good to hear.