Add LinkSet data equivalent to avatars – AvatarData
tracked
Kristy Aurelia
Linkset data is amazing for persistent storage and sending data between scripts.
Having a set of data for avatars would be great too. It would enable synchronizing settings between multiple items of the same brand a lot easier. Storing shared settings, for example access block lists for interactive attachments. Or storing settings data when before swapping to a redelivered version of the same item, that can then read it. Sending password protected data between HUDs and other attachments, instead of using chat channels. I’m sure scripters would fine plenty of uses for something like this.
Functionally it should have all the features of the LinkSetData, with some differences:
• No equivalent for LlLinksetDataReset, as we wouldn’t want one brand’s items destroy other brand’s item’s data.
• Larger storage than 128k, as there can’t be 30k avatars in a sim, compared to regular prims, more storage shouldn’t be a problem, I’d say 1mb or more sounds reasonable starting point.
• Equivalent of https://feedback.secondlife.com/scripting-features/p/edit-linksetdata-from-inside-the-viewer would be a must, with a reset all button for the viewer. We wouldn’t want a broken item filling in someone’s whole storage, so ability for the Residents to clear all data or just select data would be required.
• Maybe add a permission request before item can Write/Delete AvatarData, no read permission, or auto-grant read on attach. Again, since it is permanent storage on avatar, we wouldn’t want it to be corrupted by a broken script.
• In terms of documentation there should be caveats pointed out that the data can be reset at any time by the Residents and that it should not be used for storing any license key or authorization type data.
• Should have a listener functionality (similar to chat listen) for specific key changes instead of an equivalent of linkset_data event, as we wouldn’t want to trigger loads of scripts on many different attachments with each change.
Log In
KyliaDaden Resident
The per-avatar analogue to LSD should probably not only keyed against avatar ID, but also object ID. Therefore an object not only cannot mess up the data stored by other objects, it also cannot peek into other object's probably private/sensitive data.
E.g. the KVP database would have as a key the tuple of (object_id, avatar, label, password).
This also prevents a bad object from filling out the per-avatar data storage, as it can only fill up it's own allocation.
We can additionally limit this per-avatar per-object data to, say, only 4 KiB. Or 16 KiB if LL is generous.
Finally, if object of a certain object ID ceases to exist, then the whole database keyed to that object ID can be deleted with one fell swoop.
Jenna Felton
I pretty like this feature. I am looking for a way to store scripted data (like script settings) persistently. because sometimes attachments fail to store the changed linkset data (mostly it is script data) when the owner crashes even hours after the data has changed.
Using external database is not an option, not everyone can have one and it is not always available. Using experiences is not always an option, the owner has to be premium to have one or find a premium scripter who can offer the KVP for storing data.
This feature could allow to have a persistent KVP database attached to an avatar, unless LL fails to store the database content when it was updated and postpone the storing process to the moment of owner logging out. Then the persistence will become as limited as the regular LSD or script data is.
Signal Linden
tracked
Journey Bunny
A lot of the use cases make sense, but I feel like it's going down a difficult path if avatars have data. Many parts of this feature spec are workarounds for serious problems that will arise by the feature existing. For example, giving the avatar in in- viewer editor with an option to "reset all" would largely negate the feature, because we'd have a lifetime of settings that we'd have to clear just because of one bad actor or because we just got a new product and we've run out of Avatar data storage space. It would be impossible to create products that rely on the availability of this data space.
Linkset data neatly steps around the problem by compartmentalizing data per object per product. Realistically, and added remote capability for linkset data as some other people have mentioned would make it possible to do something like a "brand HUD" that accomplishes everything in this feature spec with regards to stored and shared data among multiple products, but without the added complications. A brand HUD is already possible, using linkset data and channel-based chat, even though we can all admit that it's a little bit clumsy.
Is there anything that Avatar data could be completely uniquely needed for, that couldn't be solved with some clever or slightly harder-to-program uses of the existing linkset data?
Kristy Aurelia
Journey Bunny: > rely on the availability of this data space
PS2 Memory cards had limited space, yet most games still supported making save games.
Jokes aside, you basically covered the main points - an easier way of achieving things. Current ways of achieving it take up precious memory and processing time, when compared to a single function call. We didn't really need LinkSetData, since we could always just make a script that can send and receive data via link messages and just store it in it's memory, but having LinkSetData achieves the same result a lot easier, faster, with less overhead and also has additional benefit or surviving script resets. As you mentioned, there is that other suggestion about having remote LinkSetData reading, do we really need that one? We could make a sender/receiver script that sends the data over the chat.
My personal uses cases would be to store small amount of persistent data, like few UUIDs and few integers. As well as use it for bulk temporary data transfers - for example, upgrading to a new version of a product that is a multi-link unrigged item. The old item could dump all the linked part position/rotation/scale data as a big blob and any additonal setting and such, which is likely to be quite a lot bigger than a typical chat mesage, and a new item could read it back and reapply it, then delete it.
KyliaDaden Resident
Journey Bunny per-avatar per-pose adjustments for publicly usable furniture.
128kB can only store a certain amount of data until it's full, and needs a way to track LRU data.
If said furniture can store its data on the avatar, then the storage issue for the furniture piece becomes moot.
Also, see my comment on the main feedback itself: Allow 4 KiB of data per-object per-avatar. Perform mass deletion when object ceases to exist.
Peter Stindberg
Imagine 110 agents on a region (or 175 on an event region), 20% of them coming or leaving every minute, each of them "carrying" 1 MB of agent-LSD data... shoving onto the simulator, offloading from the simulator... I can imagine this leading to heavy lag.
The "accidentally overwriting keys" could be handled with prefixing, as described here: https://wiki.secondlife.com/wiki/Category_talk:LSL_LinksetData#1._Prefix_keys
Kristy Aurelia
Peter Stindberg: You can already wear 38 attachments with 128KB of LinkSetData each which adds up to 4,864 KB.
Teleports causing sim stalls is a whole different issue that really needs to be sorted out separately, it should barely take any time transfer few MB of data within the same data centre...
Kadah Coba
From memory from over a decade ago when compression was added the avatar packing and unpacking serialization when moved between regions, and also remember from when I ran the benchmarks a few years ago on zlib (which was what was being used last I knew, but very likely could be something better now)...
Worst case if the gird was still running on hardware from 2010, using one of the generally bad zlib implementations, with an extra 100MB would possibly add a few ms to one thread at worst.
Most of the lag a region experiences is probably that new agent getting everything for rez and all the associated updates from there being a new agent in the region.
KyliaDaden Resident
Peter Stindberg LSD is stored on a separate server, microservices-like. So all those LSD bytes don't actually move along when crossing regions.
Vincent Nacon
I'm failing to see why we need this when we could just ask for a Remote LSData function. Not forget to mention that we already can store data via Experience KVP.
Kristy Aurelia
Vincent Nacon: Experiences are limited to a parcel that adds them?
Also. This would be way easier in terms of creating non-password protected data and having and open format for many creators to be able to use specific keys for a things. Without need of experience contributors.
With a viewer side UI, Residents could modify Key-Value pairs to change script configuration. Same as in LinksetData.
Not dataserver based, just like LinksetData.
Vincent Nacon
Kristy Aurelia: There was a change back in September 2023,
"
Experience KVP functions no longer require an experience to be enabled on the land.
"Kadah Coba
Vincent Nacon: Yeah, that change finally make eKVP something that could be used finally outside of fixed self-own-land experiences.
Rohacan Hirons
Vincent Nacon KVP could be a good solution if only we could have a data size limit per user for each experience, even if it's only a few kb. The current system with a global limit can quickly become saturated if the experience is too successful.
Kristy Aurelia
I’ve just realised - Attachments vs Non-attached vs Seated... Probably the easiest way would be to always use the Owner, because allowing access seated avatar's data might cause privacy concerns?