Multiple group checker

I'm having a bit of a problem with a group situation. I am looking to trigger an event ONLY for members of a certain group. Yes, I know, llSameGroup. Well, what if I want to trigger it for GroupA OR GroupB OR GroupC? Also, i would require it to do the opposite. I would require it to do something for people outside the group, not for those with their tags set to one of the listed groups.

Make sense? Any help, please?

You will have to use a different object for each group.

Set the group of each object to the desired group, then have the script inside the object use llSameGroup to determine what to do or not do.

Unfortunately, this is presently beyond the realm of possibility for LSL. A script can only determine if an agent is wearing the same group tag that the object it is contained in is assigned to (llSameGroup or llDetectedGroup). It cannot determine if an agent is wearing the tag of an arbitrarily designated group, nor otherwise access what groups an agent is or is not a member of.

llDetectedGroup would say whether they are in the designated group and are wearing the tag.

Yes, as does llSameGroup, but my point was that "designated group" is limited to whatever group the object is assigned to, it cannot be dynamically designated via the script itself.

And Triple's suggestion of separate objects assigned to different groups will work. In fact, if individual prims are assigned to different groups, then linked, they will retain their individual groups assignments, so testing for multiple groups can be achieved via passing link messages. This is not obvious from the object edit dialog, though, since in Edit Linked Parts mode, if a child prim is selected, the Group set button is grayed out and the group of the root prim is displayed. Also, this remains true only so long as they remain rezzed, and are not taken into inventory. If they are, when re-rezzed, the entire linkset will take on the group tag assignment of the placing avatar.

And, of course, the obvious limitation of this method is that the object's owner must be a member of the group(s) to be checked... but not necessarily a permanent member. If you assign an object to a group, then leave (or are ejected from) that group, the object will retain that group assignment. (probably because the system doesn't retain a centralized list of an agent's rezzed objects, and doesn't want to track them down all over the grid when a group exit event occurs)

s'what I get for skimming, deanna said it first and better, only thing I can think to add is putting the group name on the child prims, which can then act like a mini Groupkey2name database as well..

This is the logic I had reached too. Not nice though, it is?



Now that is handy! Saves getting the receiving prim to do a laggy listen! Thanks!