Customer Claimed that...

...their Omega Teleporter was able to recognize TWO different groups inside the script.

Her claim was that it belonged to a 'land owner' group and was set to that...but that she could have any random person a of a 'staff' group use the teleporter's group level permissions.

She claimed that there was no 'set-up' of a group by adding names to a category or anything of the like...that the Omega Teleporter truly recognized a group it had no association with and gave them special permissions.

I'm very familiar with llDetectedGroup() and llSameGroup() and have just now read the WIKI entries on them AGAIN...just in case I missed something...

...it is my impression that those commands can ONLY detect if the avatar has a group active that is also currently the object's "Set..." group.

In other words...I always thought an object could only ever recognize ONE group...the group it was "Set..." to.

This customer claims that an object can recognize MORE than one group, just by adding the group name to a notecard...

Help me out here? And anyone familiar with the Omega Teleport and able to tell me if this lady is telling the truth?

I don't believe she means SL groups. Omega Concern Teleporters recognize classes of users, which they call "groups". From the notecard:

"Groups are defined as follows:

Public: This is everyone you haven't banned from using the teleport via the access card.
Group: This is everyone who is in the same group as the group the object is set to. It doesn't need to be deeded to the group.
Guest: This is everyone you placed the names of into the access card, at least those without the all-banning # mark in front of their name.
Owner: This is you. Only you will see the destinations listed with this flag."

So you are correct, it only recognizes people from one SL group. However it does allow other users in different classes to use it.

Interestingly enough, I just discovered a hack to actually detect whether someone is a member of one of two (or more) different SL groups. It turns out that you can have a child prim in a link set be set to a group different than the root prim, and that llSameGroup() and llDetectedGroup() will reflect the fact that it's set to another group. So you can create one prim set to group A, and one prim set to group B, and link A to B. Then place scripts in both that check group membership and communicate via link messages. It's a hack, but it does work... until you pick the object up.

Now that's very interesting Lex...somethin' I should play with. It's too bad you can't 'llSetGroup()' for an object...then it could really be a fun hack.

Darien...I had a long discussion with the lady regarding exactly what you quoted to me. It's why I finally gave up--exasperated--and came here to ask people. I kept telling her that that's the way things were set up and she proclaimed over and over and over again that it wasn't...and that the teleporter indeed recognized groups 'magically'.

Her claim was that if I had a group named "MyGroup" and a group named "LandGroup" that she could put the teleporter down...set it to "LandGroup"...and then...on her permissions notecard type something like:


Group:MyGroup:<vectors and all that>

...and the teleporter would be restricted to MyGroup...not the "LandGroup" that the teleporter was set to.

She proclaimed repeatedly that there was no setup for "MyGroup" and that the teleporter just magically recognized it because it was an SL Group.

Anyway...that's why I brought it up here...I was having a heart attack about missing some new and amazing feature.

hehe, well some people live in their own version of reality, even in SL, which is kind of ironic when you think about it...

and yes, Lex, that hack is a nifty trick. (files that away for future consideration)

I have no idea if the teleporters in question have the feature she mentions, I'm guessing no, but it should be noted that what she says is within the realm of what is possible, if one really wanted it bad enough.

Basically, the group would have to be one where anyone can see the membership list, and then the LSL script would need to make an HTTPRequest to a backend that returned to it a list of the group's members. And the limitation of the group needing it's membership list public could be worked around, if the backend can login to SL using an account that's one of the members.

At this point, though, we're talking about backend servers running CGI or ASP with .Net/Mono support and libsecondlife; seems like a hell of a lot of work just to avoid typing a few names into a notecard.

yes, I use the teleporters, and I can guarantee they don't do what she claims.

Hehe.. Yeah, we've been using that little trick in some of our vendors for a while. It works good unless somehow the prim group settings get changed (re-rezzing will do it, as it forces all prims to belong to your current group). Trouble is, it's not good for high-volume vendors, since it requires link messages to operate.