"Linkset Data" is coming.

[Quistess Alpha]

I did a few crash tests, and (unsurprisingly) crashing with a worn attachment can still lose data.

Interestingly though, there's a memory leak: llLinksetDataAvailable() always returns 65536 after being attached, and it does seem that LinksetData will hold more data than it's supposed to if you coax it over multiple attaches, but getting the data back out without crashing the script. . .

I expect that to be patched out if/when it's actually released though.

ETA: a bit messy because I was just playing around, . . .

Quote

default
{
    on_rez(integer i)
    {
        llOwnerSay( (string)llLinksetDataAvailable());
        /*
        string e = llLinksetDataRead("e");
        integer loop = 300;
        while(~--loop)
        {   e += " : "+(string)llGenerateKey();
        }
        llLinksetDataWrite("e",e);
        
        llOwnerSay((string)llStringLength(e));
        */
        
        string a = llLinksetDataRead("a");
        llOwnerSay((string)llStringLength(a));
        a = "";
        llSetMemoryLimit(65535); llSetMemoryLimit(65536); // garbage collect please.
        a = llLinksetDataRead("b");
        llOwnerSay((string)llStringLength(a));
        a = "";
        llSetMemoryLimit(65535); llSetMemoryLimit(65536); // garbage collect please.
        a = llLinksetDataRead("c");
        llOwnerSay((string)llStringLength(a));
        a = "";
        llSetMemoryLimit(65535); llSetMemoryLimit(65536); // garbage collect please.
        a = llLinksetDataRead("d");
        llOwnerSay((string)llStringLength(a));
        a = "";
        llSetMemoryLimit(65535); llSetMemoryLimit(65536); // garbage collect please.
        a = llLinksetDataRead("e");
        llOwnerSay((string)llStringLength(a));
        a = "";
        llSetMemoryLimit(65535); llSetMemoryLimit(65536); // garbage collect please.
    }
}
// I coaxed it into returning:
//[09:36] Linkset Data Test (2): : 27570
//[09:36] Linkset Data Test (2): : 27300
//[09:36] Linkset Data Test (2): : 23400
//[09:36] Linkset Data Test (2): : 23400
//[09:36] Linkset Data Test (2): : 23400

 

Edited October 9, 2022 by Quistess Alpha

[Fenix Eldritch]

15 minutes ago, Quistess Alpha said:

Interestingly though, there's a memory leak: llLinksetDataAvailable() always returns 65536 after being attached, and it does seem that LinksetData will hold more data than it's supposed to if you coax it over multiple attaches, but getting the data back out without crashing the script. . .

Same thing happens if you change regions, or take to inventory and re-rez. BUG-232744

[Pazako Karu]

Being able to handle 8-100 larger KVP or a few thousand tiny ones would be a remarkably helpful tool to have! As with a prior poster though, Id kinda want it to be less volatile than some current methods, where a crash or replace outfit will just undo potentially hours of data. Even a 60 second update-if-necessary save would be phenomenal.

Did my own speed test from excitement, these numbers may not be reflective of future implementation as limits may be imposed!

• Max KVP: 8457 (0=0, 1=1, 2=2, 10=10, etc)
• llLinksetDataRead: 130.90us
• llLinksetDataDelete, 137.36us
• llLinksetDataWrite: 227.76us
• llLinksetDataListKeys: 36,638us (36.64ms)

So, basically zero. Considering the time to process the ListKeys data, even being 10 times slower (per value) it does offer strong flexibility.

• The tests were done with a 65s or 1 run limit:
• Write filled the store with integers in string form for key and value, 0=0 etc
• Read read integers in string form (up to max for the run)
• Delete deleted integers in string form (up to max for the run)
• ListKeys read integer string and 16 count until the end, this only managed one run
• Script peaked at 0.170ms script time in an empty sim running these.

Note on Max KVP: using base64/16 wont reasonably reduce the number of string characters at these scales (8457 is still 2109 or 4oSJ, 4 characters each)

Edited October 10, 2022 by Pazako Karu

[Rider Linden]

I've redeployed an updated version where I've addressed most of the issues brought up here.  I'm looking forward to hearing more tomorrow at SLUG.

[Lucia Nightfire]

7 hours ago, Rider Linden said:

I've redeployed an updated version where I've addressed most of the issues brought up here.  I'm looking forward to hearing more tomorrow at SLUG.

linkset_data() still uses the input, integer name instead of string name. 😉

Also, empty values used with llLinksetDataWrite() return 0 and no key is stored. Shouldn't that return 3 "empty string passed as a value"?

Edited October 11, 2022 by Lucia Nightfire

[Love Zhaoying]

On 10/9/2022 at 11:20 AM, Lucia Nightfire said:

I check for new functions/constants/events all the time on aditi whenever I see a new region version.

This isn't "official" yet as there are no wiki pages, nor did any Linden say it was being worked on.

Is there a pop-up message or something when you log into Aditi that tells you about the new changes, and did that include the list of new functions?

(I kept wondering how you know what the parameters of the functions should be if there was no Wiki info yet, or Linden message about it.)

[Lucia Nightfire]

1 hour ago, Love Zhaoying said:

Is there a pop-up message or something when you log into Aditi that tells you about the new changes, and did that include the list of new functions?

(I kept wondering how you know what the parameters of the functions should be if there was no Wiki info yet, or Linden message about it.)

Whenever I see a new region version, I open the script editor and go to Help > Keyword Help to create/update a keywords file in AppData\Local.

If I see a new uuid in that file name versus what I have on record, something changed.

Edited October 11, 2022 by Lucia Nightfire

[Love Zhaoying]

11 minutes ago, Lucia Nightfire said:

Whenever I see a new region version, I open the script editor and go to Help > Keyword Help to create/update a keywords file in AppData\Local.

If I see a new uuid in that file name versus what I have on record, something changed.

Awesome!

Does the dropdown list in the Script Editor of LSL functions, with the "parameter hints" also get updated to include the new functions and/or any parameter changes?

[Fenix Eldritch]

On 10/9/2022 at 11:10 AM, Wulfie Reanimator said:

Oh I'm not a fan of that. I wonder why that's the behavior.

I opened up a JIRA on the matter and Rider kindly provided some insight as to what is going on under the hood and why it works this way.

TLDR: the keys aren't actually ordered internally, they only appear to be because the ListKeys and FindKeys function will do the sorting of the data they return.

Quote

When two linksets are merged the simulator will make a best effort to move the datastore from the old root into the new.
If there is insufficient space, the simulator will discard key/value pairs that do not fit.

The internal sequence of the map used for Linkset data is not ordered, so if you have a keyname of "B" a key with the name "C" is not guaranteed to be the next item in the sequence. (nor is the store guaranteed to start with "A". )
The simulator will attempt to keep as much as it can however.

Suppose you have 10K left in the store. And you merge in a prim with the following keys/sizes:
[ "A": 11K, "B": 5K, "C": 1K ... "G":1K]
The simulator will skip "A" since there is not enough space, but keep "B" at 5K and "C" through "G" at 1K each, since there is enough space left in the store for all of those.

One other note. If both linksets have data with the same key, the root's key value pair will not be replaced.

The llLinksetDataListKeys and llLinksetDataFindKeys functions both sort the list of keys before returning them to your script.

Linkset datastore merger is not predictable as to which keys will be discarded.

 

Edited October 11, 2022 by Fenix Eldritch

[Lucia Nightfire]

2 hours ago, Love Zhaoying said:

Awesome!

Does the dropdown list in the Script Editor of LSL functions, with the "parameter hints" also get updated to include the new functions and/or any parameter changes?

IDK which dropdown list you're refering to.

Your viewer will reference the keyword file downloaded for the list shown in Help > Keyword Help and for any data in function/constant/event hover-over popups.

[Love Zhaoying]

3 minutes ago, Lucia Nightfire said:

IDK which dropdown list you're refering to.

Your viewer will reference the keyword file downloaded for the list shown in Help > Keyword Help and for any data in function/constant/event hover-over popups.

The list shown below in the Script Editor (official SL viewer).

Note that I also do not have a "Help > Keyword Help" option in the Help menu, as shown below (official SL viewer).

 

[Rider Linden]

Quote

2 hours ago, Lucia Nightfire said:

Also, empty values used with llLinksetDataWrite() return 0 and no key is stored. Shouldn't that return 3 "empty string passed as a value"?

 

Writing a zero length string as the value actually deletes the key from the store. 

llLinksetDataWrite(key, "");

is equivalent to

llLinksetDataDelete(key);

 

[Coffee Pancake]

10 hours ago, Rider Linden said:

I've redeployed an updated version where I've addressed most of the issues brought up here.  I'm looking forward to hearing more tomorrow at SLUG.

Might not be able to make the user group.

However .. can we have a way to view the linkset data that doesn't require a script.

[Qie Niangao]

46 minutes ago, Coffee Pancake said:

a way to view the linkset data that doesn't require a script.

There's up to 64KB of the stuff so let's not dump it to chat. Maybe a web/javascript app, with search and edit functions? (which itself could be a script; in fact, not sure exactly why it would be better not being a script.)

[Lucia Nightfire]

2 hours ago, Rider Linden said:

Writing a zero length string as the value actually deletes the key from the store. 

llLinksetDataWrite(key, "");

is equivalent to

llLinksetDataDelete(key);

 

What I get for not having verbose on for linkset_data() when doing that test.

1 hour ago, Qie Niangao said:

There's up to 64KB of the stuff so let's not dump it to chat. Maybe a web/javascript app, with search and edit functions? (which itself could be a script; in fact, not sure exactly why it would be better not being a script.)

I'd bet it has to do with wanting to do everything via viewer UI, similar to how it's been requested to update other prim properties via viewer UI such as particles, hover text and animated textures.

Edited October 11, 2022 by Lucia Nightfire

[Lucia Nightfire]

3 hours ago, Love Zhaoying said:

The list shown below in the Script Editor (official SL viewer).

I assume Insert is referencing the same keywords file.

[Coffee Pancake]

Viewer UI makes a feature accessible.

Gatekeeping the new secret sauce behind expert level scripters who can write there own debug tools does not help anyone or the platform as a whole.

[Qie Niangao]

24 minutes ago, Coffee Pancake said:

Viewer UI makes a feature accessible.

Gatekeeping the new secret sauce behind expert level scripters who can write there own debug tools does not help anyone or the platform as a whole.

No rule against a Linden writing an open source script; Kelly used to do it, off and on. Or a scripter.

A couple years ago, for an Experience KVP, I started a KVP browser, but my jquery skills are crap, and when I realized I'll be forever stuck with Land Scope-crippled Experiences, I abandoned it. Some of it was functional and, such as it was, it looked like this:

not that I'm volunteering or anything. 

I certainly don't mind somebody spending the time to put functionality into a viewer instead, especially in this case where at least the functionality is exposed to scripts. I only get testy about such things when the timeline extends for feature introduction because a viewer control surface was designed and implemented  first, when the actual feature could be fully functional through a simple script API. (How much sooner would we have had working, feature-complete EEP if it could have been tested through scripts first, before all that time got invested in multiple generations of UI?)

[Love Zhaoying]

Are you asking that the user be able to add/change/delete linkset KVP data from the viewer UI, or just view it?

[Coffee Pancake]

22 minutes ago, Love Zhaoying said:

Are you asking that the user be able to add/change/delete linkset KVP data from the viewer UI, or just view it?

A simple real time table view would be sufficient.

[Qie Niangao]

16 minutes ago, Love Zhaoying said:

Are you asking that the user be able to add/change/delete linkset KVP data from the viewer UI, or just view it?

FWIW, I had it in mind for the script to respond with a one-time-use URL only to "authorized" agents, but that's not perfectly secure. A viewer approach would need some additional "permissions"-like data to decide who besides the object owner should be authorized to read and/or write to the local KVP. The script loads the "Edit" functionality separately, with the idea that it could be excluded for agents only authorized for read-only access, but that would also need some server-side enforcement.

[Love Zhaoying]

24 minutes ago, Qie Niangao said:

FWIW, I had it in mind for the script to respond with a one-time-use URL only to "authorized" agents, but that's not perfectly secure. A viewer approach would need some additional "permissions"-like data to decide who besides the object owner should be authorized to read and/or write to the local KVP. The script loads the "Edit" functionality separately, with the idea that it could be excluded for agents only authorized for read-only access, but that would also need some server-side enforcement.

Maybe like textures: If you've got the UUID, you can use the texture. Only give out the UUID of the info to those with the right rights.

Whether that is the UUID of the linkset itself or..of the data..

[Gabriele Graves]

I would like to have another tab on the object properties that shows the key/values in a scrollable table, maybe allow each to be clicked on to show the full key name and value.

[Love Zhaoying]

4 minutes ago, Gabriele Graves said:

I would like to have another tab on the object properties that shows the key/values in a scrollable table, maybe allow each to be clicked on to show the full key name and value.

Now we're talking!!! I like that a lot, it's what came to mind when someone first mentioned showing the values in the UI.

[Gabriele Graves]

1 minute ago, Love Zhaoying said:

Now we're talking!!! I like that a lot, it's what came to mind when someone first mentioned showing the values in the UI.

I imagined that Coffee's post was referring to something similar and just spelled out my spring-boarded version.

That tab may have to have the values hidden if the person doesn't have permission to modify the object though.