A partial step to what you're looking for would be for llDetectedGroup to return true regardless if the agent's matching group is active or not. Right now llDetectedGroup only returns TRUE only if the agent's active group is the same as the object the script is in. This could probably still be abused, but would be much more difficult.

This is needed, for the ability to ban groups from an area.

Call is fascist if you will, but the majority of serious griefers that attack my sandbox are members of b\tards. It would be much simpler to just auto eject all members of that group, and explain that it is because they are members of a known griefing group.

Currently, we need to create and set to group dozens of vendor / inventory giver objects and require that the group members wear the appropriate group tag to use them.

This is, to say the least, so awkward and foolish that the grief we get from mistakes made by group members is getting pretty bad.

I agree that knowing all the groups someone is in (except invisible groups) would have lots of useful applications, e.g:

• Being able to treat group members differently than non-members, without having to get everyone (say, at a club) to use the club title all the time. This would be great, especially for newbies who aren't sure how to change title.
• Being able to treat members of certain groups differently. Obviously, banning by group is one application, but there are others. Affiliated clubs may choose to treat members of each other's groups specially, for example. Scripts that are designed to work for one group may give custom errors if a similar but related group is used. This could finally be a way of fixing all those scripts which require a particular group to be active.

I think this proposal is a good idea, but I don't think it will help much with banning by group.
The reasons are :
1) There is no way for LSL scripts to interface with the estate ban list yet, so this system won't be able to work automatically on islands, which is where many of the places that get the most griefing are. The most it could do would be to set parcel bans. As parcel bans don't stop griefers going to the next parcel and crashing the sim, spamming the sim with particles, etc, they're pretty useless. Thus, adding LSL calls to detect peoples' groups wouldn't be much help to all the places on islands which really do need more help.
2) Being able to sense members of invisible groups would be a privacy violation. However, if this feature was implemented most true griefer groups would go invisible to avoid being banned, thus rendering the system useless. Thus if you allow this function to sense membership of invisible groups, you violate privacy. Yet if you don't, it won't be very useful for ban-setting purposes.

Don't get me wrong. I like this proposal overall. Being able to tell all the (visible) groups someone is in via LSL would have useful applications for clubs, etc. Even if it wouldn't be very useful for banning, that doesn't matter. Not everything is about bans, y'know.

If you want to ban people by group, I would highly suggest :
1) Lobbying for the estate ban list to be scriptable. (SVC-244)
2) Lobbying for group keys included on the parcel and estate ban lists to be considered as bans against all group members. (I can't find the JIRA link to this, can anyone help me out?)

Not saying this proposal is a bad idea. Just saying... I don't think it is a good way of doing bans by group. It helps, but it is more useful as a general scripting tool, I think.

if ( llGroupMember( avkey, btardgroup ) ) // Works whether group is Active or Not!!!
{
// code to eject potential miscreant from parcel
}
else if ( llGroupMember( avkey, myclubgroup ) )
{
// code give group member a special prize
}
else
{
llSay(0,"Join our Club Group for member benefits!");
}

All that it does is return TRUE or FALSE if a person is a member of the group you're concerned about, whether active or not. It doesn't tell you all the groups you're in. You don't then have to parse the list with your script, either.

Don't get me wrong, I could totally use something better than what we have, and projects I've worked on in the past just couldn't function as simply as we liked because I could only compare the touching avie's active group. All I wanted to know is if they were a member of the one particular group, and I couldn't care less if they were members of anything else.

Often people use groups as a way to use an object, but the script int he object says they are not in the group unless the group is active. Using a function like this will let the person have any group active but still be detected as a membor of the group.

The function should work for both agents and objects. The usefullness of this becomes apparent if we are also given the requested " list llReturnObject( list [ key Object_or_Agent ] ) " function.

It will need a " key llGetMyGroup() " function to get the objects group. Sure there is already a hack to do this, but it should be an official function, not a side effect of another one. We all know how people love to JIRA size effects to break them.

Darling

Mr. Nolan's suggestion is probably also the best because its implementation is fairly similar to existing functions, it really differs only in the need to specify a group rather than simply having the object use its own group as reference.

However, I think it should have one more limitation, in that it ought to require that the avatar specified must be in the same region. This way it can still be used when someone teleports in, or when they touch an object, but can't be used as a fishing expedition along the lines of "hey, why don't I run a check and see if John Doe is in any of these groups". Well, they could still do that if he was in the same region, I suppose, but at least they couldn't just do it randomly at any time.

After all, even with Mr. Nolan's suggestion, there is still the privacy issue that it would be giving you information as to whether or not the avatar was in a specific group. While it's probably not a huge deal since you would have to have the script specifically check that particular group, I do think that ensuring that it is as limited as possible while still being functional is probably the best idea.

As for implementing it on estates, I agree with Angel that it would be helpful if the script could add to the estate ban list, but absent that, at least using llTeleportHome() should prevent them from being able to do much damage.

1) It does NOT list groups the Resident has marked as hidden, period. Not even the active group.

2) It is limited to use on Residents within the same sim. (Or within a 96m distance if in an adjacent sim, a la llGetObjectDetails())

If it functioned like that it would simply be a way that script could access information already viewable by other residents anyway. (Profiles list group names, after all)