Various questions about IDs

I'm hoping someone can answer these for me.

1.) Is there a way to convert an avatar key or group key to a usable integer? If so, how?

2.) How does one have a script detecting the active group of an avatar sitting on an object? I can get it to work for touch events, but seem to have hit a wall with sitting.

1) All depends on how you define "usable". Keys (UUIDs) are hexadecimal string representations of a 128-bit binary number. Integers in LSL are 32 bits. So, if you mean "usable to uniquely identify an avatar", then no, there's no way to cram 128 bits into 32 bits without loss of significance and, thus, uniqueness. However, if you are looking for something which can be used as some kind of temporary key or hash, then yes, you can. Simply convert the hexadecimal string into 4 32 bit integers and XOR them together with the "^" operator.

integer GetKeyHash(key pkUUID) {
    string lsKeyWithoutDashes;
    integer liKeyHash;

    lsKeyWithoutDashes = llDumpList2String(llParseString2List((string)pkUUID,["-"],[]),"");
    liKeyHash = 
        (integer)("0x"+llGetSubString(lsKeyWithoutDashes,0,7)) ^ 
        (integer)("0x"+llGetSubString(lsKeyWithoutDashes,8,15)) ^ 
        (integer)("0x"+llGetSubString(lsKeyWithoutDashes,16,23)) ^ 
        (integer)("0x"+llGetSubString(lsKeyWithoutDashes,24,31));
    return liKeyHash;
}

2) You have to define a llSitTarget, put in a changed() event, check for CHANGED_LINK, and then use llAvatarOnSitTarget() to get the avatar's key, then use llSameGroup() to see if the avatar sitting on the object is in the same group as the object.

default {
    state_entry() {
        llSitTarget(<0.0,0.0,0.01>,ZERO_ROTATION); // put in your own non-zero offset/rotation for this
    }
    changed(integer piChanged) {
        key lkAvatar;
        if ((piChanged & CHANGED_LINK) != 0) {
            lkAvatar = llAvatarOnSitTarget();
            if (lkAvatar != NULL_KEY)
                if (llSameGroup(lkAvatar))
                    llOwnerSay("Sitter is in same group!");
                else
                    llOwnerSay("Sitter is NOT in same group!");
        }
    }
}

Talarus, you're my hero!

Don't rely on that - packing a key into 4 ints works perfectly, but using XOR to cram them into one int raises the chance of collisions far beyond anything reliable.

1)Although keys in SL are 32 bit integers(remove the dashes and you'll see) and thus can be broken down into four 8-bit integers, you can't pack an entire key into a usable integer.

2)Use llDetectedGroup(0) or llSameGroup(id)

fixed.


there are methods of compressing and representing keys that take less space but getting a key into an integer is going to lose a lot of uniqueness along the way, and depending on how keys are assigned means a very large chance of 2 or more different keys matching in one integer conversion...

at a guess you could take any set of 8 characters and convert to integer, and that should be about as good as any other method. like so...

  integer vfQuickKey( key vKeyInput ){
 	return (integer)("0x" + llGetSubString( vKeyInput, -8, -1 ));
  }
 

(yes I know that logically most standards use the front of the key for grouping, and the end of the key for uniquenes within the group, there is no guarantee that it's implemented this way, and without knowing the implementation, 'any' set of 8 is literally true... my example used the end to err on the side of tradition, and the fact that early linden keys used that method)

Precisely... UUID keys are 128 bits for a reason:
1 trillion UUIDs would have to be created every nanosecond for 10 billion years to exhaust the number of UUIDs.

It's an ungodly huge number, so, to express it as an integer, you'd have to use 4 of them together. Can't cram 128 bits into 32 any way you slice it. a 32 bit integer has about 4 billion combinations... express as above.. creating a number 1 trillion per nanosecond, you'd run out of numbers well within the first nanosecond (1/232nd of a nanosecond) if my math is right. Considering that, even with 50,000 people creating instances of objects, texture creation, notecard editing, etc, SL will not run out of UUID's ever... ok, maybe not ever, but your great, great, great, great, great grandchildren will have been dead for eons before that would happen.

Umm. That's what I said. Did you even read my post?

Some people like to hear themselves talk...uh I mean post.