Xiija Posted November 16, 2022 Share Posted November 16, 2022 (edited) @Kehf Nelson dunno if this helps, but it kinda shows LSD & JSON if anyone can use it ... string toucher; string toucherID; string j_obj; string result; prot() { // the JSON string j_obj = llList2Json( JSON_OBJECT, [ "Sim", llGetRegionName(), "Time", llGetTimestamp(), "Prim", llGetObjectName() , "Toucher", toucher, "ToucherID", toucherID ] ); string test = llJsonGetValue( j_obj, ["Toucher"]) ; // check val llOwnerSay("\nTOUCHER: " + test + "\n "); j_obj = llJsonSetValue( j_obj, ["Toucher"], toucher + " the Awesome !"); // update val string test2 = llJsonGetValue( j_obj, ["Toucher"]) ; llOwnerSay("new val is: " + test2); llLinksetDataWriteProtected( "JSON-1", j_obj, "json_pass"); // WRITE JSON STR TO LSD string protVal = llLinksetDataReadProtected("JSON-1", "json_pass" ); // READ LSD llOwnerSay("\nProtected (json str) VAL: \n \n" + protVal ); list json_list = llJson2List( protVal ); // LSD to LIST llOwnerSay("\nList:\n" + llList2CSV( json_list) ); // parse data for use list keys = llList2ListStrided( json_list,0,-1,2); list vals = llList2ListStrided( llDeleteSubList(json_list, 0, 0), 0,-1,2); integer n; for( n = 0; n < llGetListLength( keys ) ; ++n ) { string k = llList2String( keys, n ); string v = llList2String( vals, n ); result += k + " : " + v + "\n"; } llOwnerSay( "\nPARSED: \n" + result ); } default { state_entry() { } on_rez(integer start_param) { } touch_start(integer num) { toucher = llDetectedName(0); toucherID = llDetectedKey(0); prot(); } } Edited November 16, 2022 by Xiija 2 Link to comment Share on other sites More sharing options...
BlueXBeta Posted November 21, 2022 Share Posted November 21, 2022 is it here ? is it here ? Link to comment Share on other sites More sharing options...
Marvin Benelli Posted November 21, 2022 Share Posted November 21, 2022 No, it’s there: on the main grid 2 3 Link to comment Share on other sites More sharing options...
primerib1 Posted December 3, 2022 Share Posted December 3, 2022 A quick question: If I do a script reset (e.g., pasting a new version of my script over existing version), does that reset the LSD store as well? Link to comment Share on other sites More sharing options...
Marvin Benelli Posted December 3, 2022 Share Posted December 3, 2022 No! 1 2 Link to comment Share on other sites More sharing options...
primerib1 Posted December 3, 2022 Share Posted December 3, 2022 (edited) 13 minutes ago, Marvin Benelli said: No! Oh okay. So it's persistent even between script resets, and the only way to (quickly) empty the store is using llLinksetDataReset() ? Edit: Ugh, silly me, it's all explained in the wiki: https://wiki.secondlife.com/wiki/Category:LSL_LinksetData Edited December 3, 2022 by primerib1 1 Link to comment Share on other sites More sharing options...
Fenix Eldritch Posted December 3, 2022 Share Posted December 3, 2022 (edited) 46 minutes ago, primerib1 said: If I do a script reset (e.g., pasting a new version of my script over existing version), does that reset the LSD store as well? By itself, no. The LSD store is effectively a primitive parameter in the sense that it will persist once set and does not need a script to sustain it. Having said that, if the script in question does something that affects the datastore on startup, like calling llLinksetDataReset, then yeah that'll obviously wipe the store. Edit: as an aside, while llLinksetDataReset is them main way of clear a datastore, you could also do it by unlinking the object's original root. Technically speaking, the datastore isn't wiped: it stays with the root. So in effect, the old linkset will lose its datastore when the root object is taken out of the linkset. This isn't the case if you keep the old root and link a new root. In that scenario, the datastore is migrated to the new root (and merged if they both had a datastore). Edited December 3, 2022 by Fenix Eldritch additional thoughts 1 1 Link to comment Share on other sites More sharing options...
Kadah Coba Posted December 3, 2022 Share Posted December 3, 2022 We all missed a bug testing this back on Aditi. Rezing and attaching break if the LSD store has key(s) containing certain characters. https://jira.secondlife.com/browse/BUG-233015 2 Link to comment Share on other sites More sharing options...
primerib1 Posted December 3, 2022 Share Posted December 3, 2022 5 hours ago, Kadah Coba said: We all missed a bug testing this back on Aditi. Rezing and attaching break if the LSD store has key(s) containing certain characters. https://jira.secondlife.com/browse/BUG-233015 Can't open it. What characters? Link to comment Share on other sites More sharing options...
Wulfie Reanimator Posted December 3, 2022 Share Posted December 3, 2022 (edited) 48 minutes ago, primerib1 said: Can't open it. What characters? You can log into the Jira with your normal SL account. Here's a partial quote for convenience though: Quote An object will fail to rez or attach if its LinkSetData store has a key that contains any of the following characters: U+0001..U+0008, U+000C, U+000E..U+001F We've tested up to U+03E8. These are Unicode character codes, which can be created with llChar. Edited December 3, 2022 by Wulfie Reanimator 2 Link to comment Share on other sites More sharing options...
Lucia Nightfire Posted December 3, 2022 Author Share Posted December 3, 2022 4 minutes ago, Wulfie Reanimator said: These are Unicode character codes, which can be created with llChar. Before llChar() came along I used llEscapeURL() and a harcoded value, since it was a roll of the dice with LSLEditor failing to allow hardcoded unicode between version updates back in the day. 1 Link to comment Share on other sites More sharing options...
primerib1 Posted December 4, 2022 Share Posted December 4, 2022 15 hours ago, Wulfie Reanimator said: You can log into the Jira with your normal SL account. Here's a partial quote for convenience though: These are Unicode character codes, which can be created with llChar. Thanks! So basically, most of the "C0 Controls" block in Unicode BMP, then all is good until and including the "Combining Diacritical Marks" block in Unicode BMP. Okay then, will not (mis-)use those characters for the time being 🙂 Link to comment Share on other sites More sharing options...
Kadah Coba Posted December 5, 2022 Share Posted December 5, 2022 On 12/3/2022 at 12:12 PM, primerib1 said: Can't open it. What characters? U+0001..U+0008, U+000C, U+000E..U+001F A bunch of ASCII control characters. This affects use in values too. You can use these characters fine, but it will become unrezable, which is kinda a problem. Link to comment Share on other sites More sharing options...
primerib1 Posted December 5, 2022 Share Posted December 5, 2022 7 minutes ago, Kadah Coba said: U+0001..U+0008, U+000C, U+000E..U+001F A bunch of ASCII control characters. This affects use in values too. You can use these characters fine, but it will become unrezable, which is kinda a problem. Well if you use C0 Control characters in a string you're going to output to the display, then you're living in a state of sin and you deserve what's coming atcha 😜 (Exceptions are of course the TAB character [U+0009], the LF character [U+000A], and the CR character [U+000C] ... though I'm having a hard time understanding how or why VT [U+000B] is still applicable...) 1 Link to comment Share on other sites More sharing options...
Qie Niangao Posted December 5, 2022 Share Posted December 5, 2022 3 hours ago, primerib1 said: Well if you use C0 Control characters in a string you're going to output to the display, then you're living in a state of sin and you deserve what's coming atcha 😜 Low range llChar() keys and values are pretty indispensable. What hid this bug from early testing must have been that step of pulling the scripted object through inventory before rezzing (also indispensable but might not be done with every test). 2 Link to comment Share on other sites More sharing options...
Love Zhaoying Posted December 5, 2022 Share Posted December 5, 2022 So, ASCII / U+0007, no DINGDINGDING for you! 2 Link to comment Share on other sites More sharing options...
Anna Salyx Posted December 7, 2022 Share Posted December 7, 2022 On 12/3/2022 at 2:59 PM, Wulfie Reanimator said: You can log into the Jira with your normal SL account. Here's a partial quote for convenience though: These are Unicode character codes, which can be created with llChar. How likely will this collide with the new (ish) key pack function that MollyMews provided that use llChar and llOrd? I tested in a small set of about 12,000 keys and didn't have problems, but even a rare occurrence might be one rare too many if this is not fixeable. test was to generate a key, pack it, and store it, looping until the store ran out of space (about 2384 keys or so per run), taking a copy of the test object and then rezzing it. did this 5 times for my sample. Link to comment Share on other sites More sharing options...
primerib1 Posted December 7, 2022 Share Posted December 7, 2022 (edited) 22 minutes ago, Anna Salyx said: How likely will this collide with the new (ish) key pack function that MollyMews provided that use llChar and llOrd? I tested in a small set of about 12,000 keys and didn't have problems, but even a rare occurrence might be one rare too many if this is not fixeable. Well, MollyMews algorithm used characters in the range of [1..55295], so yeah there is quite some possibility of triggering the bug. A new packing algorithm needs to be developed to limit the characters used to be in the range of [32..55295] instead. Edit: After some thinking, I think it's kinda doable with some mathematical trickery. MollyMews' algo "steals" one bit from every 4 hex digits, so the range of value is not really [1..55295] but actually [1..32768]. That means we can add 31 to that getting a range of [32..32799] (which is still in the range of [1..55295]). On the unpacking side we can do the reverse, subtract 31 from the decoded value. EDIT 2: Okay forget everything I said above. MollyMews already added 0x20 to every stage. So the llChar() always fall in the range of [32..32799]. In conclusion: MollyMews' algorithm is safe from this bug. Edited December 7, 2022 by primerib1 2 1 Link to comment Share on other sites More sharing options...
Love Zhaoying Posted December 23, 2022 Share Posted December 23, 2022 I spent time today prepping a script (major work-in-progress) for Linkset Data, mainly organizing the data so it would have proper KVP's. I plan to use this data as both "storage" and for "inter-script" data transfer instead of using llMessageLinked(). I figure, if the data is already there in LSD..no reason to send it in linked messages. Hopefully by end of this Sunday (Christmas) I will have made major progress at least "populating" the data, and maybe change the next script to "consume" the data next week. Since I haven't tried it yet, is there anything all you experienced folks would like to warn me about with the Linkset Data functions? Link to comment Share on other sites More sharing options...
Quistess Alpha Posted December 23, 2022 Share Posted December 23, 2022 2 hours ago, Love Zhaoying said: Since I haven't tried it yet, is there anything all you experienced folks would like to warn me about with the Linkset Data functions? I'm also starting to try and use it seriously for a thing, and the only thing I'd point out is that it's minorly annoying to distinguish between a 'key with a null-string value' and a 'non-extant key'. Also as a general rule, if there's a reasonable possibility other people's scripts might exist in the same object as yours, it's good hygiene to prefix your keys with something reasonably unique. 1 1 Link to comment Share on other sites More sharing options...
Love Zhaoying Posted December 23, 2022 Share Posted December 23, 2022 6 hours ago, Quistess Alpha said: I'm also starting to try and use it seriously for a thing, and the only thing I'd point out is that it's minorly annoying to distinguish between a 'key with a null-string value' and a 'non-extant key'. Also as a general rule, if there's a reasonable possibility other people's scripts might exist in the same object as yours, it's good hygiene to prefix your keys with something reasonably unique. Luckily, my use-cases so far shouldn't be affected by either of these! Last night I remembered the RegEx feature. I won't need that for awhile. Link to comment Share on other sites More sharing options...
Love Zhaoying Posted December 23, 2022 Share Posted December 23, 2022 (edited) I'm pretty pleased, all my pre-work was correct so it only took about an hour to script writing everything to LSD and prove it got written. Hopefully, changing the "client" script goes that easily. The good news: I already have the "Keys" figured out - they are not changing from what I was using before LSD. Edited December 23, 2022 by Love Zhaoying 1 Link to comment Share on other sites More sharing options...
Quistess Alpha Posted December 23, 2022 Share Posted December 23, 2022 (edited) While working on my thing I just had a lightbulb moment: LinksetData can be used to turn any asynchronous request into a synchronous one with the help of another script (at the cost of some delay): // script A: string request = "Sensor"; llLinksetDataDelete(request); llMessageLinked(LINK_THIS,-5,request,NULL_KEY); string response; llResetTime(); do { llSleep(0.2); }while((""==(response=llLinksetDataRead(request))) && (llGetTime()<5.0)); llOwnerSay(response); //script B: link_message(integer i, string s, key k) { if("Sensor"==s) { llSensor(...); } } sensor(integer n) { list results; while(~--n) { results+=llDetectedName(n); } llLinksetDataWrite("Sensor",llList2CSV(results)); } no_sensor() // IMPORTANT, else A could end up in an infinite loop. { llLinksetDataWrite("Sensor"," "); } Of course, this isn't ideal if you can avoid it, but in some cases not having to "remember" finicky details (Ex. What am I sensoring for and why?) between events could be very handy. Edited December 23, 2022 by Quistess Alpha 1 Link to comment Share on other sites More sharing options...
Love Zhaoying Posted December 23, 2022 Share Posted December 23, 2022 1 hour ago, Quistess Alpha said: While working on my thing I just had a lightbulb moment: LinksetData can be used to turn any asynchronous request into a synchronous one with the help of another script (at the cost of some delay): // script A: string request = "Sensor"; llLinksetDataDelete(request); llMessageLinked(LINK_THIS,-5,request,NULL_KEY); string response; llResetTime(); do { llSleep(0.2); }while((""==(response=llLinksetDataRead(request))) && (llGetTime()<5.0)); llOwnerSay(response); //script B: link_message(integer i, string s, key k) { if("Sensor"==s) { llSensor(...); } } sensor(integer n) { list results; while(~--n) { results+=llDetectedName(n); } llLinksetDataWrite("Sensor",llList2CSV(results)); } no_sensor() // IMPORTANT, else A could end up in an infinite loop. { llLinksetDataWrite("Sensor"," "); } Of course, this isn't ideal if you can avoid it, but in some cases not having to "remember" finicky details (Ex. What am I sensoring for and why?) between events could be very handy. If LSD were asynchronous-only, I'd totally ignore it at this time, and maybe find a use for it later. Link to comment Share on other sites More sharing options...
Love Zhaoying Posted December 23, 2022 Share Posted December 23, 2022 One thing I didn't do yet, is clean up (remove extra tests from) my test POC LSD and see how much space it's taking. Tomorrow.. Link to comment Share on other sites More sharing options...
Recommended Posts
Please take a moment to consider if this thread is worth bumping.
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now