More about keys

I've been trying to build up something that stores names of employees or similar in lists, so that I can IM them all or similar.

If I use llDetectedKey() (correctly, I'm not quite that bad) and typecast it to list and try to use llListFindList() to compare it to the list of keys I've already got it NEVER finds it. If I do it the ugly way (cycle through one at a time and compare them as strings) it works fine. That isn't too bad in some places, but in others it makes for some really ugly code.

Is this a known quirk? I've got something that works now, but I just wondered if others had noticed the problem, or if I really am being that stupid.

Instead of typecastig it as a list, insert it into one:

list employees = [buncha, keys, from, whatever, source];

touch_start(integer n)
{
     key toucher = llDetectedKey(0);
     integer ndex = llListFindList(employees, [toucher]);
     if ( ndex > 0 )
     {
          llWhisper(0, "You're already on the list!");
     }
     else
     {
          employees += toucher;
          llWhisper(0, "Welcome to the list!");
     }
}

Ah, thank you.

Can I ask if anyone knows why that works and typecasting it doesn't? But I will use this technique in future.

Well... I don't think you can typecast something as type list, since a list is a collection of other types already. The most you can do is explicitly create a list containing the variable or data that you want.

I think.

I concur.

It's not going to be type cast ... if you stuck a vector at the end, it would happily go in and smile whilst doing so. It might even say thank you, or give you present. Untested.

--Jack Lambert

Typically, the problem is in how the variable is changed when you typecast. If you look into some of my newer scripts, for example, you'll see me jumping through a lot of hoops with variable types. I didn't have to for most of it, but it was to be doublesure the script works in the future.

Simply put, though, when you want to typecast through a list, and vice versa (example: using lists from llParseString2List), you need to be wary of interchangability of variable types, but more importantly, how to get around it.

For example, llParseString2List returns a list that, amazingly, is full of strings. To get around this for all variable types, I do (variable type)llList2String(listname,num);

However, you need not do it that way. Here are some examples of how variables will work, interchangably, with typecasting before, and after, a list:

Edit: For each of the tests, I commented out the other tests. This is why you see duplicate variable declarations and references to slot 0 in the list.

// Tested all of this in world. Note variable names are photocopied, 
// so you would not get this code to compile verbatim.
list test = [];

// Works:
test += (vector)<0,0,0>; 
llSay(0,llList2String(test,0));

// Does not work:
vector testit = <0,0,0>;
test += "<1,1,1>";
testit = llList2Vector(test,0);
llSay(0,(string)testit);

// Works:
vector testit = <0,0,0>;
test += "<1,1,1>";
testit = (vector)llList2String(test,0);
llSay(0,(string)testit);

// Works:
integer testit = 0;
test += "5";
testit = llList2Integer(test,0);
llSay(0,(string)testit);

// Works:
integer testit = 0;
test += "5.0";
testit = (integer)llList2Float(test,0);
llSay(0,(string)testit);

// Works:
string testit = "This is a key";
test += testit;
key so_is_this = "This is a key";
llSay(0,(string)llListFindList(test,(list)so_is_this));

// Works:
string testit = "This is a key";
test += (list)testit;
key so_is_this = "This is a key";
llSay(0,(string)llListFindList(test,(list)so_is_this));

// Does Not Work:
string testit = "12345";
test += testit;
llSay(0,(string)llListFindList(test,(list)12345));

// Does Not Work:
integer testit = 12345;
test += testit;
llSay(0,(string)llListFindList(test,(list)12345.0));

// Works:
integer testit = 12345;
test += testit;
llSay(0,(string)llListFindList(test,(list)((integer)12345.0)));

// Works:
rotation testit = <0,0,0,0>;
test += "<1,1,1,1>";
testit = (rotation)llList2String(test,0);
llSay(0,(string)testit);

// Does not work:
rotation testit = <1,1,1,0>;
test += "<0,0,0,2>";
testit = llList2Rot(test,0);
llSay(0,(string)testit);

It's of note that vectors and rotations do not typecast properly out of a list via llList2(Type) if stored as a string. However, as a general rule, everything else seems to.

Also of note, strings and keys work interchangably with llListFindList, and for that matter, so does typecasting at each end. This makes sense.

Typecasting directly from a list to a string via llList2String also appears to be a golden medium for variables, but that may easily change.

llListFindList, however, does not work with types that are radically different, like strings and integers.

Anyone want me to Wiki this?

Hrm yeah that is interesting. I can't think of a good reason to store a vector or rotation as a string so maybe that was intentional ... unless you really are trying to store a string that looks like a vector or rotation. But you never would have done any conversion then.

--Jack Lambert

Actually...

listen(integer chan, string name, key id, string msg)
{
    // Suppose a message comes in as follows:
    msg = "<100,100,100>::<0,0,0,1>::<1,1,1>";

    list params = llParseString2List(msg,["::"],[]);
    
    // This would not work:
    // vector pos = llList2Vector(params,0);

    // This, however, would work:
    vector pos = (vector)llList2String(params,0);
    llSetPos(pos);


    // This would not work:
    // rotation rot = llList2Rot(params,1);

    // This, however, would work:
    rotation rot = (rotation)llList2String(params,1);
    llSetRot(rot);


    // This would not work:
    // vector scale = llList2Vector(params,2);

    // This, however, would work:
    vector scale = (vector)llList2String(params,2);
    llSetScale(scale);
}

Jeffrey,

Looking at your first script in this thread, you would add something to the end of the list for each of the first few tests, but would extract from position 0 each time. Might not give you the results you expect that way.

I apologize if I didn't make what I did clear. For each of the tests, I commented out the other tests. This is why you see duplicate variable declarations and references to slot 0 in the list.

Let me add that to the original post.

Ah. The += (when = would have done the same) made me think otherwise.

Nevermind then.