On a land deeded on Group B I want to expel non-members of Group A

[RoloTomari]

Hello everyone,

I have a land which is deeded to group A which is the staff group. I also have a Group B which is the members group. So I would like to check for people on my land and if they are not a member of this group B they should be teleported at the separate landing I have. Is there a way to do that?

So far I've seen security systems that will check membership only for the group the land is deeded to. Not for a different one. Also all I have seen either expel out of the parcel or tp the users home, whereas I want to tp them to specific location, the landing.

Any ideas or products out there that could do this? 

Thanks you all,

Rolo

 

 

[Rolig Loon]

You could rez two prims.  Set one to group A and the other to group B.  Write a script for prim A that checks if ( llSameGroup( llDetectedKey(0) ) ).  If the result is TRUE, the detected person is a member of Group A, so do Group A stuff.  If the answer is FALSE, however, tell the script to send the detected UUID to a script in prim B, which does exactly the same thing.  If the script in prim B determines that the detected person is in Group B, teleport the person to a new landing point.  

There are two major problems with this method.......

First, the scripts will only be able to tell you which group a person belongs to if he happens to be wearing the group tag for Group A or Group B at the time.  If the person belongs to one of those groups but is not wearing a tag, the scripts will always return FALSE.  There is no way around that unless you maintain two whitelists of group members' UUIDs and do your checks against the whitelists instead of using llSameGroup.  That's an easy workaround, but it means that you have to keep the whitelists up to date.

The second big problem is that you can't teleport a person without his permission unless you use llTeleportAgent, and that function will only work if (1) it is teleporting the owner of the script or (2) the script is in an Experience and the teleportee has accepted the Experience.  There's no way around that one.

[RoloTomari]

38 minutes ago, Rolig Loon said:

You could rez two prims.  Set one to group A and the other to group B.  Write a script for prim A that checks if ( llSameGroup( llDetectedKey(0) ) ).  If the result is TRUE, the detected person is a member of Group A, so do Group A stuff.  If the answer is FALSE, however, tell the script to send the detected UUID to a script in prim B, which does exactly the same thing.  If the script in prim B determines that the detected person is in Group B, teleport the person to a new landing point.  

There are two major problems with this method.......

First, the scripts will only be able to tell you which group a person belongs to if he happens to be wearing the group tag for Group A or Group B at the time.  If the person belongs to one of those groups but is not wearing a tag, the scripts will always return FALSE.  There is no way around that unless you maintain two whitelists of group members' UUIDs and do your checks against the whitelists instead of using llSameGroup.  That's an easy workaround, but it means that you have to keep the whitelists up to date.

The second big problem is that you can't teleport a person without his permission unless you use llTeleportAgent, and that function will only work if (1) it is teleporting the owner of the script or (2) the script is in an Experience and the teleportee has accepted the Experience.  There's no way around that one.

Thank you very much for your reply! I will give it a try! 

[Rolig Loon]

11 minutes ago, RoloTomari said:

Thank you very much for your reply! I will give it a try! 

Good luck.  

Actually, there is a roundabout way to get around the second problem that I mentioned earlier.  It involves expecting each member of both groups to wear a special scripted badge (which could either be a visible "badge" or other attachment or could be a HUD). By definition, because the badge is attached to the person, it is automatically set to the person's group. So....

Write a script for your parcel that senses anyone who enters and sends out a "PING!" message to the person (  llRegionSayTo( llDetectedKey(0), secret channel, "PING!") ).  That message is received by a script in the person's badge which then uses llTeleportAgent to teleport the person to the appropriate landing spot.  The llTeleportAgent function will work in anyone's badge, even without an Experience, because it will always teleport the owner of the scripted object.  So, all you have to do is make the badge for Group A people teleport them to a different spot than the badge for Group B people.  This system will work even if a person doesn't happen to be wearing a group tag at the moment, because the badge is never checking llSameGroup; it's just telling people with badges where to go.  And, of course, if a person isn't wearing any badge at all, you can use the main script to send them home or just eject them.  

Edited March 11, 2021 by Rolig Loon
Cleaner wording

[RoloTomari]

12 hours ago, Rolig Loon said:

Good luck.  

Actually, there is a roundabout way to get around the second problem that I mentioned earlier.  It involves expecting each member of both groups to wear a special scripted badge (which could either be a visible "badge" or other attachment or could be a HUD). By definition, because the badge is attached to the person, it is automatically set to the person's group. So....

Write a script for your parcel that senses anyone who enters and sends out a "PING!" message to the person (  llRegionSayTo( llDetectedKey(0), secret channel, "PING!") ).  That message is received by a script in the person's badge which then uses llTeleportAgent to teleport the person to the appropriate landing spot.  The llTeleportAgent function will work in anyone's badge, even without an Experience, because it will always teleport the owner of the scripted object.  So, all you have to do is make the badge for Group A people teleport them to a different spot than the badge for Group B people.  This system will work even if a person doesn't happen to be wearing a group tag at the moment, because the badge is never checking llSameGroup; it's just telling people with badges where to go.  And, of course, if a person isn't wearing any badge at all, you can use the main script to send them home or just eject them.  

Hi Rolig! I appreciate your replies. I was just about to try these when I actually found a few security systems that will do the work I was looking for. They are kinda built in the way you describe above. Basically its security systems with two components. The scanning component (set to Group B) and the ejection component (deeded to Group A, which is the group the land is deeded to also). This way, the ejection components has the necessary permissions to kick unauthorized users and the  scanning component can send the group info of another group to be checked for.

This seems to work now, otherwise I will revert back to your method. but thank you for your time.

[Qie Niangao]

1 hour ago, RoloTomari said:

This seems to work now

I'm a little confused. First, anything based on in-world scripts can't tell Group membership, only which Group an avatar has active at the time. I guess I'm surprised this satisfies the objective, but if so, that's great. (The alternatives here aren't great. One is to augment LSL scripts using a bot to scrape Group membership. The other is to redefine the problem to not use SL Groups at all, replacing that with something like Rolig suggests with different factions wearing different scripted "badges" of some sort.)

Second, I'm surprised that ejection is adequate to the objective, not requiring an explicit teleport. Earlier I was going to ask whether this happens to be a full region, and if so, suggest defining a small separate parcel for ejected avatars to land. But if I understand correctly, ejection puts the "Group B" users back at the landing point; I wouldn't have guessed it would do that. (Does it?)

Just in passing, another way for a script to determine an avatar's active group is to find the OBJECT_GROUP of stuff in llGetAttachedList() -- assuming they're wearing any non-HUD attachments worn from inventory (as opposed to "Put on" as a ground-rezzed object). Again, though, this is only to find the active group.

[Prokofy Neva]

16 hours ago, Rolig Loon said:

You could rez two prims.  Set one to group A and the other to group B.  Write a script for prim A that checks if ( llSameGroup( llDetectedKey(0) ) ).  If the result is TRUE, the detected person is a member of Group A, so do Group A stuff.  If the answer is FALSE, however, tell the script to send the detected UUID to a script in prim B, which does exactly the same thing.  If the script in prim B determines that the detected person is in Group B, teleport the person to a new landing point.  

There are two major problems with this method.......

First, the scripts will only be able to tell you which group a person belongs to if he happens to be wearing the group tag for Group A or Group B at the time.  If the person belongs to one of those groups but is not wearing a tag, the scripts will always return FALSE.  There is no way around that unless you maintain two whitelists of group members' UUIDs and do your checks against the whitelists instead of using llSameGroup.  That's an easy workaround, but it means that you have to keep the whitelists up to date.

The second big problem is that you can't teleport a person without his permission unless you use llTeleportAgent, and that function will only work if (1) it is teleporting the owner of the script or (2) the script is in an Experience and the teleportee has accepted the Experience.  There's no way around that one.

I think you could only do this with Experience, and you can try to get customers use to Experience, and some merchants and landlords are doing this successfully, their customers are really motivated to accept that scary-looking drop-down screen that looks like it might be a tram to Hell, and hope for the best.

I have several experiences that I try to get customers to use to move from one rental area to another, let's say if they are skipping around viewing rentals, but people just hate clicking on Experience. So I use the portal script which pulls up the map.

There used to be a map of the world...

nm

[Rolig Loon]

6 hours ago, Prokofy Neva said:

I think you could only do this with Experience

No actually, as I pointed out in my second reply, the badge method does not require an Experience because llTeleportAgent will always work for the owner of the scripted item.  It's perfect for making personal teleport units that don't open map view or require any permissions. As you create badges, set a different TP target for each group badge.  The script then listens for the "PING!" signal from the parcel's security system and sends the badge owner to the whatever destination is hard-coded into that badge.  The security system could do a second check to see whether a detected person has moved a second later.  If not, the person may be presumed to have no badge at all, so the system uses llTeleportAgentHome to toss him out of the area ignominiously.

 

Edited March 12, 2021 by Rolig Loon

[RoloTomari]

On 3/12/2021 at 4:03 PM, Qie Niangao said:

I'm a little confused. First, anything based on in-world scripts can't tell Group membership, only which Group an avatar has active at the time. I guess I'm surprised this satisfies the objective, but if so, that's great. (The alternatives here aren't great. One is to augment LSL scripts using a bot to scrape Group membership. The other is to redefine the problem to not use SL Groups at all, replacing that with something like Rolig suggests with different factions wearing different scripted "badges" of some sort.)

Second, I'm surprised that ejection is adequate to the objective, not requiring an explicit teleport. Earlier I was going to ask whether this happens to be a full region, and if so, suggest defining a small separate parcel for ejected avatars to land. But if I understand correctly, ejection puts the "Group B" users back at the landing point; I wouldn't have guessed it would do that. (Does it?)

Just in passing, another way for a script to determine an avatar's active group is to find the OBJECT_GROUP of stuff in llGetAttachedList() -- assuming they're wearing any non-HUD attachments worn from inventory (as opposed to "Put on" as a ground-rezzed object). Again, though, this is only to find the active group.

Hi Qie, I appreciate you spending time to reply so let me clarify a couple of points. When I talked about the group membership I was referring to the settings of the security system, where you can set the allowed users to a group only. In fact it doesn't check group membership but active tag, you are right. So I am happy to have people wear the group tag always and therefore check they are members of the group. 

You are also right about the ejection destination. I am not able to teleport them were I want. But either eject them or tp them to their home. I still haven't been able to find a solution to this. But my primary focus was being able to control that only members of the group can stay on the land. So its certainly not ideal, but gets the job done for now.

Thank you for your suggestions.