Orb recommendations

[Jono Lanfier]

Just wondering if anyone can recommend a security orb that does the following:

Allows members of  a particular group onto a sim even if the orb is deeded to another group and allows them on even if they are simply a member and dont have that group title activated

 

Many thanks in advance if anyone knows an orb that does that.

 

[Nova Convair]

The only option a script has is: Check if the detected avatar wears the same group tag as the scripted object itself.

So what you have in mind is not possible.

- The avatars need to wear the required group tag.

- To check for multiple groups you need to have one object per group for the check.

- Only other possibility is to run a whitelist, but that means to ignore SL's groups and run your own system.

 

[steph Arnott]

In addition to Nova's post. The asset server can not access anyones group list (well not for public use is more accurate) and for good reasons. When a data request on an agent or object is called a list of parameters is accessed useing the UUID asset file (legacy name, second name, age, etc, active group). When you activate a group tag, you effectivly switch that asset on. The asset server and sim server are two different servers.

Sorry about the very simplistic explaination as wrote it to give a general idea of what happens.

Maybe someone else can put that in a better way than i have.

[Qwalyphi Korpov]

---

Nova Convair wrote:

The only option a script has is: Check if the detected avatar wears the same group tag as the scripted object itself.

So what you have in mind is not possible.

- The avatars need to wear the required group tag.

- To check for multiple groups you need to have one object per group for the check.

- Only other possibility is to run a whitelist, but that means to ignore SL's groups and run your own system.

 

---

There is another, only slightly more complicated, possibility:

• The avatar needs to activate the required group
• The avatar needs to wear an attachment which will respond to chat from the "Orb"

When the Orb detects an avatar it can llRegionSayTo the avatar on a channel the required attachment listens to.

If the Orb receives a response from the attachment it can then use llGetObjectDetails to obtain the group UUID of the attachment.

Check the attachment UUID for a match with the required group UUID.

[Nova Convair]

---

Qwalyphi Korpov wrote:

There is another, only slightly more complicated, possibility:

• The avatar needs to activate the required group
• The avatar needs to wear an attachment which will respond to chat from the "Orb"

When the Orb detects an avatar it can llRegionSayTo the avatar on a channel the required attachment listens to.

If the Orb receives a response from the attachment it can then use llGetObjectDetails to obtain the group UUID of the attachment.

Check the attachment UUID for a match with the required group UUID.

---

Yes, kind of passport. But it's not that easy - you need to add an activation/deactivation mechanism or you will not be able to kick someone out. So you end up with a whitelist server.

[steph Arnott]

Then one may as well just turn the orb off.

[Qwalyphi Korpov]

---

Nova Convair wrote:

---

Qwalyphi Korpov wrote:

There is another, only slightly more complicated, possibility:

• The avatar needs to activate the required group
• The avatar needs to wear an attachment which will respond to chat from the "Orb"

When the Orb detects an avatar it can llRegionSayTo the avatar on a channel the required attachment listens to.

If the Orb receives a response from the attachment it can then use llGetObjectDetails to obtain the group UUID of the attachment.

Check the attachment UUID for a match with the required group UUID.

---

Yes, kind of passport. But it's not that easy - you need to add an activation/deactivation mechanism or you will not be able to kick someone out. So you end up with a whitelist server.

---

An Orb owned by the land owner has authority to kick someone out.   That orb can chat to any AV on the channel the required attachment listens to.  An AVs attachments can listen to chat directed to the AV they are attached to.  So... I don't see any whitelist server here.

edit to add:  An attachment's group is set to the active group of the AV it is attached to. 

AV group UUID == Attachment group UUID.

[Qwalyphi Korpov]

---

steph Arnott wrote:

Then one may as well just turn the orb off.

---

bite me.

[steph Arnott]

Well whats the point? May as well just use either the orb which the OP is trying to get around or use the parcel white and black list. The parcel white list makes more sense as it takes what 30 to 60 seconds to add their name. The sim server puts a barrier around the parcel for those not listed any way so would hang beyond the limit. I do not use orbs any more, they are unreliable and more hassle than they are worth.

[Rolig Loon]

You are probably right that orbs are more trouble than they are worth a lot of the time, Steph, but it is quite easy to script a reliable one.  Qwalyphi's "passport" method is a pretty common solution to the OP's problem.  It serves a slightly different purpose than a whitelist, which will check a visitor's UUID against a list of pre-approved accounts.  The "passport" attachment doesn't care what your UUID is, but it does care whether you are showing the group tag when you enter.  It doesn't require the group owner/manager to maintain a current whitelist either --- a real annoyance -- since it will recognize any group member who carries it.

If you visited Linden Lab's winter regions while they were still up, you may have noticed that Premium members were wearing exactly that sort of attachment so that they could operate special kiosks to use fancier skimobiles than the rest of us common folk.

[Qie Niangao]

I think the OP was specifically asking about using an orb, not trying to get around it. In any case, the scripting problem remains valid.

I don't really see a way (other than using a bot) to get around the visitors needing to have the group active. As Qwal says, an attachment's group tends to be that of the avatar. (Not quite always, though. An object attached with llAttachToAvatar or by "Put On" while rezzed in-world retains its group while attached, until the agent changes active groups. Apparently this doesn't work for llAttachToAvatarTemp, though.)

Something that might actually be useful: a child prim retains its group setting when linked to a root in another group, so it can test llSameGroup() for a group different from the root. I doubt this would work for group-deeded objects, though, so this wouldn't help much with group-owned land, because all the heavy security functions need to be in scripts owned by the landowner (i.e., in group-deeded objects if on group-owned land).

If we want to test by looking at the group setting of attachments, we no longer need to chat at them first; we can get a list of them (except HUDs) with llGetAttachedList(). If an avatar is wearing stuff set to the desired group (according to llGetObjectDetails as Qwal suggests), and if nothing set to that group gives away or attaches rezzed-in-world objects set to that group, I think we can conclude the avatar has that group active.

[Qwalyphi Korpov]

I was not aware of those exceptions when attached while rezzed in-world or llGetAttachedList.  Thanks Qie.

 

edit:  Hmmmm.... my usual path into the list of functions doesn't list llGetAttachedList.



Found it though.

It's always something.

[Jono Lanfier]

Many thanks everyone, your input was much appreciated.  I'l go away and rethink what im trying to do,

[steph Arnott]

The lsl function page seems to gets updated when someone can be bothered. one would think that if one was going to the effort of creating a new function page then updateing the functions list would be the next logical step in the procedure. Can only assume LL have no procedures or if they do, no one follows them.

[Rolig Loon]

llGetAttachedList was introduced with server release 15.09.14.305056 last September. The LSL wiki is maintained by SL residents, primarily through the tireless volunteer efforts of Strife Onizuka, not by Linden Lab. It is not easy to keep a complex wiki up to date.  Strife deserves a lot of the credit for making it our most valuable scripting resource.

 

[steph Arnott]

Was not aware it by independants, makes me wonder what LL actually does do.

Any how i thank this Strife Onizuka and others.

[Qwalyphi Korpov]

---

Rolig Loon wrote:

llGetAttachedList

was introduced with server release 15.09.14.305056 last September. The LSL wiki is maintained by SL residents, primarily through the tireless volunteer efforts of Strife Onizuka, not by Linden Lab. It is not easy to keep a complex wiki up to date.  Strife deserves a lot of the credit for making it our most valuable scripting resource.

 

---

I looked at the page to see if I could update/fix it.   After reading the discussion page it's clear I shouldn't touch it.  Could be it's the result of some wiki software issues.  The function does appear later in the "G" group list.

[Rolig Loon]

Yeah, there are parts of the wiki that Strife has locked because there was a spate of malicious changes a year or two ago. The formatting templates are also locked, I believe, in order to maintain a consistent organizational style in the wiki. I don't understand more than that, except that there have been occasional software issues in the past as well.  I just know that there are sections that any of us can update easily (like the Examples) and other sections (like Caveats) that are protected.  I have made small changes from time to time but am glad to leave larger structural updates to someone wiser.