Request: llLinksetData functions via pin | Voters

Request: llLinksetData functions via pin

Journey Bunny

I found a request for llLinksetDataWritePublic; I'm requesting something similar but distinctly different, hoping this will be compatible with what we have now.

I'd like to request a variant of the linkset data functions with the word Remote, and a pin parameter. This set of functions would permit scripts in objects to get or set the linkset data in other objects via a secret access pin when the prim is set to Mod.

There's precedent for this! We have remote script pin, for starting/stopping/replacing scripts in other objects. I propose we do the same for data.

(I'll bold the new functions & events, the rest work like their current counterparts)

Function Spec:

function
integer llSetRemoteLinksetDataPin(integer pin)

Allows a prim to have scripts remotely get and set linkset data

function
integer llLockRemoteLinksetDataPin(integer pin, integer Locked)

Allows a prim to be set to

prevent

linkset data access from being granted via pin, using a different pin. Eg, a creator could use a pin to set lock to TRUE, preventing a customer from enabling remote data access with a Mod prim.

integer llLinksetDataRemoteWrite( key target, integer pin, string name, string value);
string llLinksetDataRemoteRead( key target, integer pin, string name);
integer llLinksetDataRemoteDelete( key target, integer pin, string name );
list llLinksetDataRemoteDeleteFound( key target, integer pin, string pattern, string pass );
llLinksetDataRemoteReset( key target, integer pin );
integer llLinksetDataRemoteAvailable( key target, integer pin );
integer llLinksetDataRemoteCountKeys( key target, integer pin );
integer llLinksetDataRemoteCountFound( key target, integer pin, string pattern );
list llLinksetDataRemoteListKeys( key target, integer pin, integer first, integer count );
list llLinksetDataRemoteFindKeys( key target, integer pin, string regex, integer first, integer count );

Read, Write, and Delete functions traditionally have a *Protected variation that works the same but adds a string password. This spec could extend protected functionality as well, or we could choose to implement just the functions above to alow data that is "already public."

Events Spec:

Minimal spec, using existing event:

linkset_data( integer action, string name, string value )

Gains the following constants:

LINKSET_DATA_REMOTE_RESET | The remote linkset's datastore has been cleared by a call to llLinksetDataRemoteReset.
LINKSETDATA_REMOTE_DELETE | A key in the remote linkset's datastore has been deleted. Either through a call to llLinksetDataRemoteDelete or llLinksetDataRemoteWrite with an empty value
LINKSETDATA_REMOTE_MULTIDELETE | A comma separated list of the keys in the remote linkset's datastore which have been deleted through a call to llLinksetDataRemoteDeleteFound.

Maximal spec, using a new event:

function
integer linkset_data_listen( key target, integer pin ) | Fires a linkset_data_remote when the remote linkset data changes. Returns handle
function
linkset_data_close( integer handle ) | No longer fires an event when a remote linkset changes.
Event
linkset_data_remote( key linkset, integer action, string name, string value ) | Receives all linkset data events from the remote object as though it were that object itself.

I see a minimal event spec as being useful and easier to implement; it essentially just tracks when successful

remote

linkset operations instigated by

this

script have completed. This provides the minimal needed feedback, and the script would need to check remote data when it intends to use it.

The maximal spec might generate a lot of events between objects. But, it's nothing we're not already doing, more clumsily, with the messaging system, but this way would be much cleaner.

With a dedicated listen/event event, we could properly have a multi-object game using common data, with events and functions fired by remote trigger. A real game platform!

One consideration: It might be desirable to have mod objects, without allowing third-party control. I have included a function to lock/unlock pin access for this purpose.

August 28, 2025

Journey Bunny

Discussing example use cases in Discord, I wanted to paste this in here, too, so it's clear what this set of features could do for us!
So, imagine a party game where everyone's wearing a HUD, and there's some central game object in-world that does all the fun stuff. Maybe everyone's HUD needs to know what "mode" the game is set to, in order to present different options on the display. We can accomplish this now: The game object just yells the game mode any time it changes. So, that works for simple stuff!
But then, imagine that there's lots of updates happening in the game, relevant to different players. Maybe some HUDs need to see the data for Red team, and others need the data for Blue team, and others for Green team. Now we start having some crazy scripts to write, where we track team lists and loops and send data to all the right HUDS, or we blast all the data to all the HUDs and have lots of filtering stuff. With remote access to LinksetData, HUDs could read the info they need (basically, requesting it from the simulator, as "keyname RedTeamData from object <UUID>") without adding all the messaging congestion to our code.
We can already do that now within objects with multiple scripts, which is a great way to coordinate information between scripts. This way, if we need several scripts inside one object, we don't have to send copies of the data around to multiple scripts (increasing sim memory usage and bytecode to handle the messaging). I'd love to extend that data sharing.
There's a second, optional but "it'd be nice piece" there, too.
Iff we could extend not just the functions, but the events as well, then we could set an object to "listen" to that little database for changes. Suddenly, a HUD could subscribe to updates to the RedTeamData key from the main game object, and fire an event on each change. That'd go even further to making a truly event-driven game-like system involving multiple separate objects~~
This again is something we can do now within the object; eg, one script can set the "current_player" in LinksetData, and then other scripts can just read that value without having to handle a message about it--and can even use the linkset_data event to take action only when that value changes. We could do that across all obects in an interactive system if that were extended to remote access!