LSL Bug -> Keys from Link Messages in Dialogs

Found an interesting bug (and more importantly, a work around) the other day I thought I'd share with you all.

Dialogs in SL require lists of strings to generate their buttons. However, a key from the link_message event, typecast to string and added as a button, generates the wrong type error. Event when saving the typecast key to a string variable first.

The code below is an example of this error:

default
{
    state_entry()
    {
        llMessageLinked(LINK_SET, 0, "", "test");
    }

    link_message(integer sender_num, integer num, string str, key id)
    {
        list buttons = [(string)id];
        llDialog(llGetOwner(), "Test Message", buttons, 0);
    }
}

This ofcourse annoyed me no end, as I tried all matter of things to get it working. In the end, I found a simple workaround (however, would ofcourse be best to avoid where possible as it needlessly adds to the script (ie, the bug needs fixing)).

default
{
    state_entry()
    {
        llMessageLinked(LINK_SET, 0, "", "test");
    }

    link_message(integer sender_num, integer num, string str, key id)
    {
        list buttons = llList2String([id], 0);
        llDialog(llGetOwner(), "Test Message", buttons, 0);
    }
}

I'm sure this is just a random, stray bug, that not many people are gonna come across, but thats the fix should people want it. Instead of typecasting the key to a string, use llList2String to get the result. Also, just to point out, I've only come across this with the key passed through the link_message event, other keys seem to work absolutely fine with it.

Two questions: is this actually a key you're sending, or just a piece of text that you've cast to key to send through the key parameter of the link message? And can you show us the error you get?

This one might be good for putting on the SL issue tracker: http://jira.secondlife.com

Either, basically anything carried in that key doesn't seem to work. Its an odd bug, as it typecasts to a string (as I can store it in strings), but if I put it in a list (even after storing it in a string) it throws up a type error.

Aaaanyways, turns out the 'broken' example I posted isn't broken at all. The actual broken version has:

list buttons;
buttons += (string)id;

With the fix being:

list buttons;
buttons += llList2String(id, 0);

Though another fix is using:

list buttons;
buttons += [(string)id];



So mistake on my behalf really. Just need to have the square brackets (turning it into a list first) to fix it, even though it doesn't need it in other events. Its a weird behavior...

The event works fine, I pass keys around via link messages all the time, never had it fail once. However, in every example you've posted, there's been some other error in it (e.g. treating the result of llList2String as if it were a list). Clean up the other bugs in the code, and I suspect you'll see the erratic behavior disappear, as the problems are there, and unrelated to the message passing. Alas, it is true, when code is buggy, the error messages LSL generates are often cryptic, bizarre, and sometimes just plain wrong. When you see an LSL error, know you're doing something wrong, but don't jump to any conclusions regarding what too quickly.

I'm not sure what you are doing, but the above won't compile if id is a key.

I've found problems using the (string)key typecast method as well. It seems to works sometimes, not others. But I found that if you create a string variable, it works. Wish I could test it, but at work now:

string s = (string)id;
buttons += ;