"Linkset Data" is coming.

[Qie Niangao]

To reiterate, this will very often contain hundreds and potentially thousands of rows. But no objection as long as the viewer UI isn't in the critical path for getting the real functionality deployed. ( I just can't help but foresee a Jira-fest of functionality requests for filters, etc., added to whatever starter UI is offered.)

 

[Gabriele Graves]

There can be up to 10,000 items potentially in an object's contents too and yet the Contents tab still displays those.  Not saying it would be ideal but at least it would be something useful and helpful for some.

[Love Zhaoying]

59 minutes ago, Gabriele Graves said:

There can be up to 10,000 items potentially in an object's contents too and yet the Contents tab still displays those.  Not saying it would be ideal but at least it would be something useful and helpful for some.

10,0000!?!? I guess that would be useful back in the "Magic Box" days.

But what is the use-case, these days, for having more than a hundred or so objects, scripts, notecards, etc. in an object?

 

[Gabriele Graves]

14 minutes ago, Love Zhaoying said:

10,0000!?!? I guess that would be useful back in the "Magic Box" days.

But what is the use-case, these days, for having more than a hundred or so objects, scripts, notecards, etc. in an object?

 

I wouldn't know.  I could theorize that there are still magic box type systems though and scene rezzers but 10K does seem extreme.  I just pulled that value from the SL limits wiki page.  Why you would have that many items is wandering off the point though.

[Audie Revnik]

Never thought I'd see the day! This will help enormously with some of my projects.

[Quistess Alpha]

3 hours ago, Gabriele Graves said:

There can be up to 10,000 items potentially in an object's contents too and yet the Contents tab still displays those.

Only if you wait for up to 10 minutes or so. . .

Putting things into and getting them back out of an object with 1000+ items in its inventory is brutal. Last I checked anyway, maybe they fixed it?

[Wulfie Reanimator]

32 minutes ago, Quistess Alpha said:

Only if you wait for up to 10 minutes or so. . .

Putting things into and getting them back out of an object with 1000+ items in its inventory is brutal. Last I checked anyway, maybe they fixed it?

More like 3 hours...

[Rick Nightingale]

Wow - A few days back, local mesh... now this... I'm  a happy devil!

 

[Gabriele Graves]

44 minutes ago, Quistess Alpha said:

Only if you wait for up to 10 minutes or so. . .

Putting things into and getting them back out of an object with 1000+ items in its inventory is brutal. Last I checked anyway, maybe they fixed it?

No disagreement here but again, the point was to show that while imperfect it's better than nothing.

[Kadah Coba]

8 hours ago, Coffee Pancake said:

A simple real time table view would be sufficient.

For what use case would you need this though?

Unless there's going to be some API for the viewer to directly access it, the latency of script relaying it to a TPV to do this would be pretty bad and likely slower than the object's scripts ability to update the store...

[Love Zhaoying]

Fun, annoying use-cases are abound!

- Bots can use it to collect data without HTTP, then send the data after TP'ing home.

- Zero-Second Orbs can use it to create ban lists without using an HTTP-based server.

 

[Vincent Nacon]

Huh... neat.

[Kadah Coba]

2 hours ago, Love Zhaoying said:

Fun, annoying use-cases are abound!

- Bots can use it to collect data without HTTP, then send the data after TP'ing home.

- Zero-Second Orbs can use it to create ban lists without using an HTTP-based server.

 

I meant what use cases for a viewer UI for realtime table view of lkvp. :p

[Coffee Pancake]

1 hour ago, Kadah Coba said:

I meant what use cases for a viewer UI for realtime table view of lkvp. 😛

Exposure of feature to users beyond the minority of elite scripters paying attention.

Ease of debugging without the need to develop debugging tools, especially useful when changing linksets.

Increases accessibility of the feature and makes wide spread adoption more likely.

[Love Zhaoying]

8 hours ago, Kadah Coba said:

I meant what use cases for a viewer UI for realtime table view of lkvp. 😛

Sorry, I was not replying to you - just making a list of additional use-cases.  (That is why I did not quote you.)

[Love Zhaoying]

6 hours ago, Coffee Pancake said:

Exposure of feature to users beyond the minority of elite scripters paying attention.

Ease of debugging without the need to develop debugging tools, especially useful when changing linksets.

Increases accessibility of the feature and makes wide spread adoption more likely.

Yes! All these reasons also would have been a good reason to include Experience KVP's in the UI!

[Kadah Coba]

Be doing some testing.

Keys and values are stored as UTF-8. That's probably ideal for most uses because ASCII only data sucks for limits with UTF-16 (which is what LSL strings use as far as I could tell). So don't try do something silly like using custom high base encoding to try squeezing more, that just uses more to store less since all the flags for UTF-8 and the deadzone blocks eat up any possible saving. LSL actually support the full ASCII charset, so I think the best that could be done was around BASE96 or something (or some cross char encoding scheme, which would be way more complicated) , not really worth the overhead verse the building in BASE64 functions.

There's no data overheard per entry. A single ASCII char key with the same for the value will cost 2bytes. Cool that's there is no "tax" for the data structure being used under-the-hood.

No noticeable additional throttles. Could hammer with 300-16000 write+read cycles per second depending on the code and it was always pretty stable latency range (see chart below). I might have to benchmark my old PSRAM library to see how that compares.

There's a time penalty/trade-off for larger value lengths. Below is chars-per-value vs write+read/s at 2k cycles  per point using max storage for the given value length.

Looking like its best to trade complexity of custom serialized data and use LSD (well that's unfortunate acronym) if the usage of unique keys is going to add additional data size to the application or it is worth the trade-off.

What little I've played with it tonight, I'm liking it. Its fast. It can be treated like llList2String+llString2List. Can replace some uses of link messages.

We've hoping for more script mem for a decade. This isn't quite that, but it'll likely be very handy for freeing up mem elsewhere since the low latency on LSD is (as of right now) really appealing.

We've also be wanting shared prim data. Would have been kinda happy with a new prim param type that was just a string. This is possibly better than we were wishing for. Thanks~

 

2 hours ago, Coffee Pancake said:

Exposure of feature to users beyond the minority of elite scripters paying attention.

Ease of debugging without the need to develop debugging tools, especially useful when changing linksets.

Increases accessibility of the feature and makes wide spread adoption more likely.

I'm not sure how obtuse it can seem to a new scripter when it can essentially be treated similar to llList2String() llString2List() with a single linkset global list. The main difference is strings keys instead of integer indexes, which could arguably be considered more beginner friendly.

I wouldn't mind having that, but I'll totally live without it. Mostly not sure LL would consider it worth the time to add such though.

[Coffee Pancake]

9 minutes ago, Kadah Coba said:

I'm not sure how obtuse it can seem to a new scripter when it can essentially be treated similar to llList2String() llString2List() with a single linkset global list. The main difference is strings keys instead of integer indexes, which could arguably be considered more beginner friendly.

I wouldn't mind having that, but I'll totally live without it. Mostly not sure LL would consider it worth the time to add such though.

The point is by having even a simple in viewer interface, its existence becomes known and debuging goes from "why isn't this ... " to " oh .. derp, I'm an idiot".

It's not fool proof by any means. How many scripters don't know that DEBUG_CHANNEL is a thing even though it has some popup UI they must have seen at some point.

[Love Zhaoying]

6 minutes ago, Coffee Pancake said:

How many scripters don't know that DEBUG_CHANNEL is a thing even though it has some popup UI they must have seen at some point.

I didn't know, until recently! Only knew about the popup for actual errors.

[Qie Niangao]

7 hours ago, Coffee Pancake said:

Ease of debugging without the need to develop debugging tools, especially useful when changing linksets.

For the "intended" use cases, the only people who'd care are scripters (for whom a viewer UI is pretty much gilding the lily) but the debugging case is particularly interesting for silently maintaining a record of script processing, much less intrusive than dumping it all to open (or worse, debug) chat, yet accessible to end users for bug reports.

Besides debugging, it could also be used for other communications between the script and end users, much easier and cheaper than internal http-served web reporting (although very limited, of course).

The big problem I'm not able to get my head around now is how multiple unrelated scripts from different sources can share an object's Local KVP store. I have a particular application in mind that would otherwise just reset KVP whenever it starts, but that could be disastrous for some other unknown scripts that also use KVP. And very much vice versa.

At the user group yesterday here was talk about permissions and protection of the KVP as a whole (which degraded into a typically religious cryptographic debate about a functionality that wasn't even specified yet).

It would be ideal if there were some sort of object-scope quota system that the owner could specify, to which scripts would comply. In lieu of such a thing in the implementation, could scripters devise a "voluntary" sharing protocol?

[Love Zhaoying]

I think it would be useful, if one had the correct permissions and the UUID of the linkset, to be able to call the new functions for a linkset (given the UUID), from other objects.

[Coffee Pancake]

1 minute ago, Love Zhaoying said:

I think it would be useful, if one had the correct permissions and the UUID of the linkset, to be able to call the new functions for a linkset (given the UUID), from other objects.

GRID WIDE

[Love Zhaoying]

Just now, Coffee Pancake said:

1 minute ago, Love Zhaoying said:

I think it would be useful, if one had the correct permissions and the UUID of the linkset, to be able to call the new functions for a linkset (given the UUID), from other objects.

GRID WIDE

^^ +1

[Quistess Alpha]

1 hour ago, Coffee Pancake said:

GRID WIDE

If the linkset_data event were somehow "exportable" (object B can ask to receive linksetData events from Object A) That would blow llEmail+http grid-wide solutions out of the water!

[Kadah Coba]

8 hours ago, Coffee Pancake said:

It's not fool proof by any means. How many scripters don't know that DEBUG_CHANNEL is a thing even though it has some popup UI they must have seen at some point.

I use llOwnerSay and added an option to FS to route all llOwnerSay to the object's own script panel, but not the main panel too. Its a lot better than spamming everybody with debugs while also not making your local chat completely unusable. :p

7 hours ago, Qie Niangao said:

The big problem I'm not able to get my head around now is how multiple unrelated scripts from different sources can share an object's Local KVP store. I have a particular application in mind that would otherwise just reset KVP whenever it starts, but that could be disastrous for some other unknown scripts that also use KVP. And very much vice versa.

At the user group yesterday here was talk about permissions and protection of the KVP as a whole (which degraded into a typically religious cryptographic debate about a functionality that wasn't even specified yet).

It would be ideal if there were some sort of object-scope quota system that the owner could specify, to which scripts would comply. In lieu of such a thing in the implementation, could scripters devise a "voluntary" sharing protocol?

As somebody that will link different things together when building out my region... or even as someone that would make things that could be linked later to random things by end users...

How about each object has their own LSD store, which can be accessed from other links, and maybe has some optional method to restrict access, possibly via a pin. That would resolve the issue of unwanted collisions when linking things that could have incompatibilities when they are trying to share the same LSD store, and things that can support sharing can just always use LINK_ROOT and handle the merging themselves via the on link event. If there is some issue with each object being able to have an LSD store, make a limit of how many their can be per link set and either prevent linking (preferable) or block/wipe the additional ones being added.

Edit:
Also want to add my +1 to wanting the ability to access LSD from other objects. I'm cool if its limited to within same region or similar limits for llGetObjectDetails. Grid wide would be cool, but also seems out of scope given how LSD is likely implemented and probably would require too much to implement.

Edited October 12, 2022 by Kadah Coba