Talk:LlGenerateKey

This is a real SL function now. This LSL code should be moved the LSL Script Library. Lomoco Binder 20:52, 5 April 2012 (PDT)

Maestro Linden in an office hour about half a year ago confirmed they were going to implement this function soon. It appears to be fully implemented and working properly (tested on server version 12.03.26.2521); they just haven't announced it yet. Lomoco Binder 22:05, 5 April 2012 (PDT)

It's live in the main release? (I should strip the pre-release note?) Do we know what the implementation is? (I'm going to assume they didn't implement it exactly how it was implemented in generateKey, not critical that we know how it was implemented just interesting) -- Strife ^{(talk|contribs)} 04:27, 6 April 2012 (PDT)

From testing, it seems to be a fairly simple function. It takes in no arguments, and returns a key id which is a randomly-generated (speculation) UUID. All the other stuff on this page is leftover from someone else's unrelated project that they just posted to the wrong place, as far as I can tell. Lomoco Binder 16:34, 7 April 2012 (PDT)

I've successfully tested it in several regions running the above version of the server software. Lomoco Binder 16:42, 7 April 2012 (PDT)

Great, I'll rework the article (annoying that they co-opted anther article, poke Sovereign Engineer about it) -- Strife ^{(talk|contribs)} 21:22, 7 April 2012 (PDT)

Who co-opted what? It just looked like someone ported my library function into this new article as a placeholder. Anyway, bit disappointing that there are no arguments, as the standard I prefer for UUID generation takes arguments so that two independent programs can generate the same UUID given the same values, which is handy for efficient message passing, particular in LSL. By using variables it's possible to pre-generate the key for the next message in a chain, meaning you only have to store a single key and ignore messages with other keys (or send back an error response), as opposed to having to keep a list of recent keys, which is the only option when using random generation. It means I'll probably keep using my library function anyway, so I'll probably edit its page to highlight the differences in use cases (and the tweaked versions that work best with them, since the default has object-key and script-name). It's just that it's quite a difference when you compare:

<lsl>list previousKeys = []; default {

   link_message(integer link, integer filter, string message, key id) {
       if (~llListFindList(previousKeys, [id])) // Ignore this message
       previousKeys += [id]; // New message (probably should delete some old previous keys too)
   }

}</lsl>

Compared against the pre-generated method:

<lsl>key nextKey = NULL_KEY; integer msgID = 0;

default {

   link_message(integer link, integer filter, string message, key id) {
       if ((nextKey == NULL_KEY) && (id == nextKey)) { // New message
           nextKey = generateKey(++msgID); // Pre-generate next key
       }
   }

}</lsl>

Bit over-simplified, but you get the idea. I find it dead handy to do this way as excess lists (plus the management required to use them) is a big burden, especially if a single script needs to support multiple services, potentially needing a bigger list or multiple lists.
-- Haravikk ^{(talk|contribs)} 06:07, 8 April 2012 (PDT)

They renamed your article to the new function, I reinstated it (but we lost the revision history to the new function). -- Strife ^{(talk|contribs)} 21:44, 8 April 2012 (PDT)

When I first came across this page, it was already named "LlGenerateKey." We didn't move it from some other name like generateKey (or at least I didn't). Lomoco Binder 20:47, 10 April 2012 (PDT)

Sovereign Engineer (a pseudo-linden account) -- Strife ^{(talk|contribs)} 21:21, 10 April 2012 (PDT)

It may or may not have the vulnerability of MD5 in SL... that is, it's not as random as some encryption specialists would like it to be. But it'll do nicely for a simple game.

NULL_KEY

Does anyone know if this function is capable of generating NULL_KEY, or can we safely use that as a "null" state for message processing? I'm hoping it doesn't produce NULL_KEY, as wrapping it in another function or handling null-state another way is just added complexity.
-- Haravikk ^{(talk|contribs)} 07:23, 14 August 2012 (PDT)

It is impossible for it to generate NULL_KEY. NULL_KEY is unversioned and llGenerateKey returns a versioned UUID (it was V3 but it's now V5). One of the digits is always non-zero. -- Strife ^{(talk|contribs)} 11:03, 14 August 2012 (PDT)

*facepalms* I should have known that after all the stuff I've done with UUIDs on other platforms as well. I think I'll pop that in as a note on the page though, for people who aren't familiar or who, like me, completely forget =)
-- Haravikk ^{(talk|contribs)} 11:22, 14 August 2012 (PDT)

You're not alone, the answer didn't jump right out at me either. I was thinking at first it was statistically possible for the hash to come up all zeros, and was going to say as much. It took several minutes for it to creep up on me that there are locked bits. -- Strife ^{(talk|contribs)} 14:27, 14 August 2012 (PDT)