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)