Jump to content

"Linkset Data" is coming.


Lucia Nightfire
 Share

You are about to reply to a thread that has been inactive for 238 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

@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 by Xiija
  • Thanks 2
Link to comment
Share on other sites

  • 2 weeks later...
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 by Fenix Eldritch
additional thoughts
  • Like 1
  • Thanks 1
Link to comment
Share on other sites

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 by Wulfie Reanimator
  • Thanks 2
Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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

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.  xD

Link to comment
Share on other sites

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.  xD

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...)

  • Haha 1
Link to comment
Share on other sites

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).

  • Like 2
Link to comment
Share on other sites

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

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 by primerib1
  • Like 2
  • Thanks 1
Link to comment
Share on other sites

  • 3 weeks later...

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

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.

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

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

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 by Love Zhaoying
  • Like 1
Link to comment
Share on other sites

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 by Quistess Alpha
  • Thanks 1
Link to comment
Share on other sites

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

You are about to reply to a thread that has been inactive for 238 days.

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
 Share

×
×
  • Create New...