"Linkset Data" is coming.

[Love Zhaoying]

13 minutes ago, Wulfie Reanimator said:

Changes made to attachments are not committed until they are detached

Not even if you log off?

[Frionil Fang]

Just now, Love Zhaoying said:

Not even if you log off?

A graceful log off includes detaching everything. A crash may not.

[Wulfie Reanimator]

23 minutes ago, Wulfie Reanimator said:

Changes made to attachments are not committed until they are detached, so when you crash hard enough (not just logging out or getting disconnected), the normal "save on unrez" process doesn't take place.

You can, for example, change the texture on an attachment and then make copy the inventory item you're currently wearing. The copy you've just created won't have the changed texture, it's a copy of the attachment before you put it on (including script state).

It should follow that LSD will behave exactly the same.

I just had to go and test it, I was too curious. Using this script:

default
{
    state_entry()
    {
        llLinksetDataWrite("key", "value");
    }

    touch_start(integer total_number)
    {
        llOwnerSay((string)[llLinksetDataRead("key")]);
    }
}

I can create LSD in Mauve (beta grid) and wear it, then move to Dore (a non-LSD sim) and make a copy of the object I'm still wearing (after verifying that the data is gone), and come back to Mauve.

When I detach the "broken" object and wear the copy I created in Dore, the data is as it should be.

This isn't any big revelation (or even relevant after LSD is fully deployed to main grid), just a neat confirmation.

Edited November 8, 2022 by Wulfie Reanimator

[Love Zhaoying]

Just now, Wulfie Reanimator said:

I just had to go and test it, I was too curious. Using this script:

default
{
    state_entry()
    {
        llLinksetDataWrite("key", "value");
    }

    touch_start(integer total_number)
    {
        llOwnerSay((string)[llLinksetDataRead("key")]);
    }
}

I can create LSD in Mauve (beta grid) and wear it, then move to Dore (a non-LSD sim) and make a copy of the object I'm still wearing (after verifying that the data is gone), and come back to Mauve.

When I detach the "broken" object and wear the copy I created in Dore, the data is as it should be.

That makes much more sense.

[Atomic Infinity]

I am curious to know what happens to any data recently set if you have a teleport failure.

Just yesterday I was adjusting a scripted HUD and forgot to detach / re-attach before teleporting to a location for testing it. The teleport failed requiring a forced log off / re-log. The latest script changes had not been preserved.

Would the LSD data be missing from the tele fail, like the script edits?

[Wulfie Reanimator]

3 minutes ago, Atomic Infinity said:

I am curious to know what happens to any data recently set if you have a teleport failure.

Just yesterday I was adjusting a scripted HUD and forgot to detach / re-attach before teleporting to a location for testing it. The teleport failed requiring a forced log off / re-log. The latest script changes had not been preserved.

Would the LSD data be missing from the tele fail, like the script edits?

Yes, LSD would be gone. TP failures cause attachments to not save. (When it happens, you're no longer connected to any sim which could handle your attachments.) It's extremely annoying.

[Anna Salyx]

2 hours ago, Wulfie Reanimator said:

Changes made to attachments are not committed until they are detached, so when you crash hard enough (not just logging out or getting disconnected), the normal "save on unrez" process doesn't take place.

I understand academically how/why it a happens but I can't really understand the "why" of it.  Certainly a region change should be enough to trigger an unsaved state commit. I get it if i crash on teleport right after changing something that things will revert. But if I've hoppiting and boppiting around the grid for a dozen or more regions certainly somewhere along the way a unsaved changes commit should be triggered (in my mind on the first successful region change).  I also get it if doing unsaved commits on a timed schedule might not be desirable, but why not on teleport? I mean it's functionally a detach/reattach event since things can 'fall off' during the processes. 

(and yes, I'm sure there is probably a good reason, but i can grumble about the general unfairness and hostility of if all just the same).

[Kadah Coba]

6 hours ago, Wulfie Reanimator said:

Changes made to attachments are not committed until they are detached, so when you crash hard enough (not just logging out or getting disconnected), the normal "save on unrez" process doesn't take place.

You can, for example, change the texture on an attachment and then make copy the inventory item you're currently wearing. The copy you've just created won't have the changed texture, it's a copy of the attachment before you put it on (including script state).

It should follow that LSD will behave exactly the same.

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)

3 hours ago, Anna Salyx said:

I understand academically how/why it a happens but I can't really understand the "why" of it.  Certainly a region change should be enough to trigger an unsaved state commit. I get it if i crash on teleport right after changing something that things will revert. But if I've hoppiting and boppiting around the grid for a dozen or more regions certainly somewhere along the way a unsaved changes commit should be triggered (in my mind on the first successful region change).  I also get it if doing unsaved commits on a timed schedule might not be desirable, but why not on teleport? I mean it's functionally a detach/reattach event since things can 'fall off' during the processes. 

(and yes, I'm sure there is probably a good reason, but i can grumble about the general unfairness and hostility of if all just the same).

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.

[Kadah Coba]

On 11/6/2022 at 1:34 PM, WolfGang Senizen said:

Depending on the whole external accessing of LSD this might not be so necessary, but a function I'd like to see would be
 

llRezObjectWithData(object,pos,vel,rot,param, ["key1","val1","key2","val2"]);

 

Would be useful to rez a configured object, rather than the current, rez, wait for event, and handle messages to pump config into rezzed item.

Also, that maybe read write and delete should have been overloaded with a list instead of adding protected versions of the functions, allowing for easy future expansion without more functions requiring multiple variations, e.g.

llLinksetDataWrite(key, value, [LSD_PASS,"secret", LSD_PUBLIC, TRUE]);

The same for read/delete obviously... (though some options may not apply for all)

Instead of exponentially more new functions in the future.... with the current scheme if the scope were to be increased.

llLinksetDataWrite(key, value);
llLinksetDataWritePublic(key, value);
llLinksetDataWriteProtected(key, value, pass);
llLinksetDataWriteProtectedPublic(key, value, pass);

Could also be further expanded to accept a parameter like LSD_TARGET_ID to allow reading a remote object in the future, with or without pins or whatever is decided (but pins seem superfluous to me given we have passwords already), though some form of secondary functions for that may be more on form with the key being the first proper argument, not a parameter in the list.

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.

[Love Zhaoying]

28 minutes ago, Kadah Coba said:

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 backup scripts from my WIP HUD to inventory folders after every few changes, then rename the script to reflect the new version number, etc. So, even if something happens to the WIP HUD where I script and test, the script is still saved to inventory.

(Plus, I save the script to my PC and back up each version to the cloud as I go.)

So..I should be safe. 

Back to LSD: Does this mean that saving the object with LSD to inventory helps ensure the LSD isn't lost? 
 

[Wulfie Reanimator]

9 hours ago, Love Zhaoying said:

Back to LSD: Does this mean that saving the object with LSD to inventory helps ensure the LSD isn't lost? 

Yes, inventory items are safe in all situations. 🙂

[Innula Zenovka]

I'm a latecomer to this, and I've not been keeping up with the thread, so apologies if this was covered earlier.

Am I correct in interpreting the last few posts to mean that, after I've put an item into my inventory/into a rezzer, each copy of it that I then rez, either manually or from the rezzer, will inherit its initial linkset data from the original inventory copy?

Where can I play with linkset data?   On which of the RC sandboxes does it work, or whereabouts on Aditi, please?

 

[Love Zhaoying]

7 hours ago, Wulfie Reanimator said:

Yes, inventory items are safe in all situations. 🙂

One thing I found interesting about this is, if you make multiple copes in Inventory of your object with LSD, then that LSD will be copied multiple times in the Linden databases!!

 

31 minutes ago, Innula Zenovka said:

I'm a latecomer to this, and I've not been keeping up with the thread, so apologies if this was covered earlier.

Am I correct in interpreting the last few posts to mean that, after I've put an item into my inventory/into a rezzer, each copy of it that I then rez, either manually or from the rezzer, will inherit its initial linkset data from the original inventory copy?

Where can I play with linkset data?   On which of the RC sandboxes does it work, or whereabouts on Aditi, please?

 

I see posts that say "Mauve", on the Beta Grid.  (I have not tried  it, just reading/writing about it.)

ETA: I see posts that say LSD is working "again" on the RC regions.  Sorry I missed that. 

Edited November 9, 2022 by Love Zhaoying

[Wulfie Reanimator]

1 hour ago, Innula Zenovka said:

Where can I play with linkset data?   On which of the RC sandboxes does it work, or whereabouts on Aditi, please?

One of these sims on Aditi (not main grid, that was a typo) should work, I've only been in Mauve myself:

https://community.secondlife.com/forums/topic/492419-linksetdata-fuction-testing/#comment-2523298

 

1 hour ago, Innula Zenovka said:

I'm a latecomer to this, and I've not been keeping up with the thread, so apologies if this was covered earlier.

Am I correct in interpreting the last few posts to mean that, after I've put an item into my inventory/into a rezzer, each copy of it that I then rez, either manually or from the rezzer, will inherit its initial linkset data from the original inventory copy?

Yes, linkset data is a completely regular prim property so it has the same behavior we're all used to. When something is an inventory item (either your avatar's inventory, or an object's contents), it's just a reference to a unique asset.

Once you rez an object, that instance is a new copy, separate from the inventory item (or the real asset it refers to). Any modifications you make to the rezzed copy will not affect the inventory item or other rezzed copies of it.

 

1 hour ago, Love Zhaoying said:

One thing I found interesting about this is, if you make multiple copes in Inventory of your object with LSD, then that LSD will be copied multiple times in the Linden databases!!

Making a copy of the inventory item (not rezzing it, just creating duplicates of the same item within your inventory) won't create new assets or cause linkset data to be duplicated, all of those inventory items are referring to the same asset. (And that's not an issue since, as soon as you rez one, that rezzed copy begins its own life.)

Assets are basically* immutable if that's an easier concept to think about.

 

Edited November 9, 2022 by Wulfie Reanimator

[Anna Salyx]

2 hours ago, Innula Zenovka said:

Where can I play with linkset data?   On which of the RC sandboxes does it work, or whereabouts on Aditi, please?

 

I don't think there is one or other RC channel that is getting it. I was under the impression it's both.  But, I do know it's back on the main grid RC BlueSteel.  (That's the RC my land is on (unless something has changed in the past few years since they stopped actually reporting it)).

[Kehf Nelson]

1. I know the correct answer to my "When?" question here is something like: "I'll be ready when it's ready..."

But what's the "best guess" to when LSD will work grid wide?  Mid 2023? 

2. How much faster or slower are we thinking LSD will be compared to Desc strings on "settings" linked prims?  

3. How bad of an idea would it be to use LSD for link_set object communication vs link_message for larger strings/data?

4. Feature Creep, don't suppose we could get a llDumpLinkSetDataToJSON() and llParseJSONtoLinkSetData() too? 

 

 

---> Shameless Plug https://github.com/knscripting/Simple-KVP-Node-for-Secondlife

 

[Anna Salyx]

1 hour ago, Kehf Nelson said:

1. I know the correct answer to my "When?" question here is something like: "I'll be ready when it's ready..."

But what's the "best guess" to when LSD will work grid wide?  Mid 2023? 

2. How much faster or slower are we thinking LSD will be compared to Desc strings on "settings" linked prims?  

3. How bad of an idea would it be to use LSD for link_set object communication vs link_message for larger strings/data?

4. Feature Creep, don't suppose we could get a llDumpLinkSetDataToJSON() and llParseJSONtoLinkSetData() too? 

 

 

---> Shameless Plug https://github.com/knscripting/Simple-KVP-Node-for-Secondlife

 

1)  The time line given last week was

• LSD to RC channels
• Following week LSD to general release

But as LSD got bounced due to an (probably) unrelated issue and was re-released again to the RC channels this week. Since there has been no communication otherwise, I'm willing to assume that the original timeline is still accurate.  RC this week > general next week.  Providing there isn't a show stopper uncovered of course.   But admittedly that's a pure guess on my part.

2) Reading and writing seems to be quite zippy, so I'm not sure there is an appreciable difference between the two.

3) I don't think it'd be a bad idea at all if you want a more persistent message ore are not wanting to construct and then parse/ break up longer string that'd might be used currently via  link_message.  Rather than construct a string,  pass is as a message, break it apart in the receiving script and store into local variables, just store a set of LSD values that can be retrieved 'at leisure' by the scripts that might need them. But I also think there's going to be place for both methods depending on need and application. 

4) is for bigger brains than me.

[Love Zhaoying]

2 hours ago, Kehf Nelson said:

4. Feature Creep, don't suppose we could get a llDumpLinkSetDataToJSON() and llParseJSONtoLinkSetData() too? 

I plan to use it to STORE JSON. 😉 

[Gayngel]

[Kadah Coba]

On 11/10/2022 at 11:45 AM, Kehf Nelson said:

1. I know the correct answer to my "When?" question here is something like: "I'll be ready when it's ready..."

But what's the "best guess" to when LSD will work grid wide?  Mid 2023? 

2. How much faster or slower are we thinking LSD will be compared to Desc strings on "settings" linked prims?  

3. How bad of an idea would it be to use LSD for link_set object communication vs link_message for larger strings/data?

4. Feature Creep, don't suppose we could get a llDumpLinkSetDataToJSON() and llParseJSONtoLinkSetData() too? 

---> Shameless Plug https://github.com/knscripting/Simple-KVP-Node-for-Secondlife

 

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

[Anna Salyx]

On 11/10/2022 at 1:45 PM, Kehf Nelson said:

3. How bad of an idea would it be to use LSD for link_set object communication vs link_message for larger strings/data?

Follow-up.  I found this on one Inara Pey's recent-ish (as of this post) blog entries.

Quote

All scripts in the object can access the data stored in the LSD – and the fact that any in the object can, and can modify the data in a linkset is a complete game changer. One of the causes of simulator-side lag is the volume of “Script Events per Second” (“eps”) it has to manage.

 ... Currently, many objects in SL (vehicles being a good example) relay [sic] on link message events: the control scripts in the root of the object which send messages to the scripts in other prims in the object, which have to listen for them; so if the object has 10 links all listening for messages from the root – that’s 10 script events. Using LSD could eliminate those link messages entirely, helping us remove some of the load from the simulator!

--(author) NeoBokrug Elytis

that's just a small extract from a larger essay on LSD which was an interesting read.  So, to better answer #3: I would say that it's not a bad idea at all, and on the surface, it seems to be a very good idea to start transitioning away from link_messages to using LSD for inter script communication.  However, as I think about it, if we simply just replace the current message_linked event with the new linkset_data event then any savings mentioned above would be a wash overall.  At least in some cases where immediate consideration of data changes is concerned (like vehicles).  But, other situations where data is more situationally used in conjunction with other events, instead of having to have each script test and see if that data is relevant to it every time there is an update, if the subscripts just need to check for a stored value when it's actually needed, then I can see that having an overall benefit in the end.

that's all I had, but I found it an interesting read and touched on what had been asked, so figured I'd share.

[Xiija]

@Kehf Nelson

I have tested JSON, and it works fine, but cannot post an example because

SL suxorz   .. i can't get into aditi, and the items i make on beta grid

do not transfer to the normal grid ?

will try later

Edited November 12, 2022 by Xiija

[Wulfie Reanimator]

5 hours ago, Anna Salyx said:

Quote

All scripts in the object can access the data stored in the LSD – and the fact that any in the object can, and can modify the data in a linkset is a complete game changer. One of the causes of simulator-side lag is the volume of “Script Events per Second” (“eps”) it has to manage.

 ... Currently, many objects in SL (vehicles being a good example) relay [sic] on link message events: the control scripts in the root of the object which send messages to the scripts in other prims in the object, which have to listen for them; so if the object has 10 links all listening for messages from the root – that’s 10 script events. Using LSD could eliminate those link messages entirely, helping us remove some of the load from the simulator!

--(author) NeoBokrug Elytis

that's just a small extract from a larger essay on LSD which was an interesting read.  So, to better answer #3: I would say that it's not a bad idea at all, and on the surface, it seems to be a very good idea to start transitioning away from link_messages to using LSD for inter script communication.  However, as I think about it, if we simply just replace the current message_linked event with the new linkset_data event then any savings mentioned above would be a wash overall.  At least in some cases where immediate consideration of data changes is concerned (like vehicles).  But, other situations where data is more situationally used in conjunction with other events, instead of having to have each script test and see if that data is relevant to it every time there is an update, if the subscripts just need to check for a stored value when it's actually needed, then I can see that having an overall benefit in the end.

I'm unsure if LSD would be the solution to reducing script events, but it could be.

On one hand, if there are 10 scripts tracking changes in LSD, changing any key would cause 10 events (since they all get notified of that same key changing). While with link messages, you could spread each script to a different prim and send a targeted message to just that script (1 event vs 10).

On the other hand, you could just omit the linkset_data event entirely and each script will just call llLinksetDataRead on the key they're interested in. That way there's zero events while every script is using the latest LSD value the moment they need it... assuming that no issues or side-effects crop up with performance when used on a larger scale.

It's gonna be interesting to see how things pan out if/when people start using this feature.

Edited November 12, 2022 by Wulfie Reanimator

[Anna Salyx]

12 minutes ago, Wulfie Reanimator said:

I'm unsure if LSD would be the solution to reducing script events, since if there are 10 scripts tracking changes in LSD, changing any key would cause 10 events (since they all get notified of that same key changing). With link messages, you could spread each script to a different prim and send a targeted message to just that script (1 event vs 10).

On the other hand you could just omit the linkset_data event entirely, and each script will just call llLinksetDataRead on the key they're interested in, and that way there's zero events while every script is using the latest LSD value the moment they need it. This assumes that no issues or side-effects crop up with performance when used on a larger scale.

It's gonna be interesting to see how things pan out if/when people start using this feature.

it's going to be situational to be sure and how the scripts the are set up.  I'll probably never call the dataset_event myself and instead like you just exampled relying on other existing events (timers mostly) to get data updates as needed. I won't say I'll never use them. but I can see my use of message_linked events usage dropping quite a bit since I won't have to be "manually" passing data between scripts.  In any case the persistence of data and that fact that it's not going to take heap space is a changer.

Edited November 12, 2022 by Anna Salyx

[Fenix Eldritch]

LinksetData has arrived!