Jump to content

Orb recommendations


Jono Lanfier
 Share

You are about to reply to a thread that has been inactive for 2511 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

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.

 

Link to comment
Share on other sites

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.

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites


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.

Link to comment
Share on other sites


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.

Link to comment
Share on other sites


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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

 

Link to comment
Share on other sites


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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 2511 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...