Difference between revisions of "Category talk:LSL Key"
Jump to navigation
Jump to search
Feyn Graves (talk | contribs) |
|||
Line 10: | Line 10: | ||
::::It's the 'variant' field, see 4.1.1/4.4 of the RFC. [[User:Masakazu Kojima|Masakazu Kojima]] 14:10, 24 May 2009 (UTC) | ::::It's the 'variant' field, see 4.1.1/4.4 of the RFC. [[User:Masakazu Kojima|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}}. -- '''[[User:Strife_Onizuka|Strife]]''' <sup><small>([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]])</small></sup> 18:56, 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}}. -- '''[[User:Strife_Onizuka|Strife]]''' <sup><small>([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]])</small></sup> 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? | |||
[[User:Feyn Graves|Feyn Graves]] 11:51, 25 August 2009 (UTC) |
Revision as of 03:51, 25 August 2009
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)
- It's the 'variant' field, see 4.1.1/4.4 of the RFC. Masakazu Kojima 14:10, 24 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)
- 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)
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)