Group Access

[ThorChaffe]

Some users are not understanding what Group Access means.
Today they don't know it means they will be unable to change group.
Maybe they don't even know it means that the active group's members will have access (because not everyone reads manuals).

I suggest to change this such that when the access is set up, the current group of the wearer is detected. Offer that group, or that they enter the UUID of another group, or (if the wearer is not the one using the menus) of the menu user, or finally of a chosen person standing nearby. Be generous and offer currently land group, too. The reason to not use the wearers group always is that there are cases where the wearer is not allowed to a be member of the controlling group.

When someone clicks the collar, to get their active group ID, checks the group of the first object they wear. If they wear no objects at all, possibly send a message then they must wear an in-world attachment for group detection to work.

integer clicker_has_the_selected_access_group_active(key clicker, key selected_group_with_access)
{
  list att = llGetAttachedList(clicker);
  // no in world attachments, or not in the sim (happens).
  if (att == []) return FALSE; 
  key firstatt = llList2Key(att, 0);
  if (firstatt == NULL_KEY) return FALSE;
  list det = llGetObjectDetails(firstadd, [OBJECT_GROUP]);
  if (det == []) return FALSE;
  key gid = llList2Key(det, 0);
  if (gid != selected_group_with_access) return FALSE;
  return TRUE;
}

[ThorChaffe]

I forgot to say, that adding the approach above, negates the need to keep the user locked in a certain group.
Good for the economy too. Shopping with shop tags is sometimes needed :-)

[Medea-Destiny]

This is in progress for 8.5