llDetectedGroup

Man are we ever limited in what LSL can tell us about groups, eh?

Ideally, I'd like to be able to grab the text of the active group tag on a person's head -- since it's publicly visible anyway, can't be any great secret. But I know that's not possible, so moving on with a sigh...

llDetectedGroup

where does it have to happen physically?

by that I mean, say you have an elevator that goes to 4 floors. You have a call button on each floor that when pressed emails the elevator saying yoohoo, you're wanted.

Can I have the call button, say, pass to the elevator the AV ID of the person who touched it, and have the llDetectedGroup(i) thing happening in the elevator, so I just have to maintain the code in one place. Or, do I have to put code such as below (which is from this forum, this forum is the best!) in each and every button and have the llDetectedGroup(i) happen at the button with the results passed to the elevator.

The example from this forum defined i as integer, which makes me suspect it might not work with a passed AV Key, as I think I understand from elsewhere that Key is basically a glorified string.


touch(integer total_number) {

string GroupMemberStatus;

integer i;
for ( i = 0 ; i < total_number ; ++i ) {
if ( llDetectedGroup(i) && ! llSameGroup(NULL_KEY) ) {
GroupMemberStatus = "Yes";
}
else {
GroupMemberStatus = "No";
}
}


}

Try llSameGroup().
http://lslwiki.net/lslwiki/wakka.php?wakka=llSameGroup

You need to use llSameGroup(id) instead of llDetectedGroup to do it that way. I haven't tried it, but it should work.

This just illustrates the difference between the two calls. llDetectedGroup takes the detection number of the agent that triggered the touch event. That number is specific to that particular invocation of the event handler. llSameGroup takes a key.


There are a number of things wrong with this snippet, one serious. The serious problem is that it really only sets the GroupMemberStatus for the last agent in the set of agents detected. So if multiple agents happen to touch at the same time, which could happen in a laggy sim, you have no idea which agent the answer corresponds to.

The less serious issues are performance related. For your purposes, touch_start or touch_end is probably better than touch. And the check for llSameGroup(NULL_KEY) isn't going to change in general, and hence shouldn't be done inside this event handler which gets called multiple times. However, I'm not sure if the changed event will detect a change in the active group of an object, so it's possible this is the only safe way to do the test. I'm sure someone else can address that issue.

Not sure where this stands at the moment, but a couple gratuitous comments, fwiw:

It's a style question, I suppose, but personally I'd leave the group logic in the call buttons, unless I had some other need to pass the avatar's key to the elevator car itself. In addition to avoiding passing around that key, this approach would only say something to activate the elevator car's script when there's something for it to do.

I agree that touch_start() or touch_end() would be better than touch(), but I'd lose the for loop and just use the 0th detected agent. Although it's theoretically possible to get multiple touches in the same event, it just doesn't happen even under lag--and in this situation, worst case, somebody in the wrong group would be the 0th, and somebody in the right group would have to touch again. If one were really compelled to handle that condition, it should probably be a do-while loop that exits on the condition of the first group match it finds.

>> Qie: It's a style question, I suppose, but personally I'd leave the group logic in the call buttons, unless I had some other need to pass the avatar's key to the elevator car itself. In addition to avoiding passing around that key, this approach would only say something to activate the elevator car's script when there's something for it to do.

Hi Qie, and thanks everybody for all the responses! wow, so fast!

Qie, I'm using a notecard in which the owner can say who has rights to use the elevator. It's appealing to me to just have to maintain one notecard in one central place -- e.g. the elevator itself. Rather than having to maintain the access information both in the elevator and a bunch of different buttons. I know me. I'll be in a hurry several times when adding someone to an access list, and forget to do it in a notecard one place or another. If it's just in one place, I can handle that, grin. At home I use the Paskis key system for my doors and tps, in which system you just maintain an access notecard in one "key looking object" which then updates all the doors and tps, and I love it -- SL is often mad and sometimes I'm lucky to get the 30 seconds just to do the update in that one place. If I had to do it in each door, no one would ever get in, lol.

So if I can send the AV ID to the elevator itself and evaluate it there via llSamegroup, that would be kewl. It's appealing to not message the elevator unless I have to, as you say, but I have to send the elevator the AV's actual name anyway, cause the list of names who have access in addition to the group is stored in the elevator notecard.

Alternatively, I suppose I could make a key like Paskis does, and have that key somehow communicate the contents of the access list to all the relevant objects like he does, so that each button evaluates access permissions but yet the user only has to maintain that list in one place, but I don't know how to do that.

Ok, I think that's a good enough reason!

If one really wanted to, there are several ways to make the contents of that notecard known to the call buttons when updated (triggered by CHANGED_INVENTORY). One would be llGiveInventory--but with hairiness to clean up the old notecards; another would be llEmail--which is slow, but has infinite range; and the one I'd choose would be some chat variant (llRegionSay, llShout, or llSay, depending on the range of this elevator ). But frankly, I wouldn't bother with it either.

One suggestion: as long as you'll be passing llDetectedKey(), you may as well pass llDetectedName() at the same time, to save a step in matching against the notecard entries (assuming those will be names, not keys).