Category talk:LSL Key

Characteristics

I just got the info that it is easily spottable if a key is from an agent or not.
My key is 42bae93c-7fbd-4e02-a34e-6ea982e9f92a.
Any agent key seems to have the marked 4 at this place in the key. I'm sure that there are other hints for "object", "notecard", "texture"... Does anyone know? If so, plz add it to the article =)
Greetz, Zai Lynch^{(talk|contribs)} 22:24, 28 June 2008 (PDT)

Appendix: I just created multiple objects to find similarities. One of these objects had a 4 in the same spot. So I tested multiple agents in the w-hat database but couldn't find any with a different value then 4 in this spot so far. Seems to be: Any agent must has this value, other keys can have this value too. --Zai Lynch^{(talk|contribs)} 22:51, 28 June 2008 (PDT)

You will find that the "4" in that position indicates that they are using Version 4 of the UUID format as specified in RFC-4122. -- Strife Onizuka 03:27, 29 June 2008 (PDT)

Kinda late, but not all avatars have a 4 there. Some old stats: http://w-hat.com/keydistribution.txt (notice also the 20th character). -- Masakazu Kojima 23:13, 17 May 2009 (UTC)

If object UUID's used a different range I would say it was intentional but they don't, I wonder if assets use a different range? Someone should tell LL their UUID generator is buggy (it has two dead bits, one stuck on (bit 67), the other stuck off (bit 66)). -- Strife ^{(talk|contribs)} 08:50, 18 May 2009 (UTC)

It's the 'variant' field, see 4.1.1/4.4 of the RFC. Masakazu Kojima 14:10, 24 May 2009 (UTC)

omg the RFC does a bad job of describing that. Good thing the wikipedia article has been updated since I commented last June (The python documentation is pretty good). I'd love to see the names (and ages) of those accounts which don't fit the v4 of RFC-4122. -- Strife ^{(talk|contribs)} 18:56, 24 May 2009 (UTC)

Comparison of Keys not working right

I just did this: <lsl> //snip

   state_entry(){
       key request_key =llGetNotecardLine(llGetInventoryName(INVENTORY_NOTECARD,0),gLine);
       llOwnerSay("Request sent, request_key is "+(string)request_key);
   }
   dataserver(key query_id, string data){
       if(query_id == request_key){
           llOwnerSay("received reply, request_key matches: "+(string)query_id);
           // Do something
       }else{
           llOwnerSay("received reply, but it's not ours: "+(string)query_id);
       }
   }

//snip </lsl> Now here's the reply I got:

[4:37]  Object: Request sent, request_key is 305a0774-0e24-4037-884b-f3052ed337e9
[4:37]  Object: received reply, but it's not ours: 305a0774-0e24-4037-884b-f3052ed337e9

How am I supposed to work around that? Feyn Graves 11:51, 25 August 2009 (UTC)

You are going to kick yourself. You are redeclaring 'request_key' in the state_entry. You aren't storing the value to the global variable, but to the local variable. Remove 'key' from in front of 'request_key' on the first line of your state entry. No worries, happens to the best of us. -- Strife ^{(talk|contribs)} 13:18, 25 August 2009 (UTC)

<lsl> //snip

   state_entry(){
       request_key = llGetNotecardLine(llGetInventoryName(INVENTORY_NOTECARD,0),gLine);
       llOwnerSay("Request sent, request_key is "+(string)request_key);
   }
   dataserver(key query_id, string data){
       if(query_id == request_key){
           llOwnerSay("received reply, request_key matches: "+(string)query_id);
           // Do something
       }else{
           llOwnerSay("received reply, but it's not ours: "+(string)query_id);
       }
   }

//snip </lsl>