Specific Group Detector

[JaslynMaia]

Hi!

So here's the situation, I'm trying to write a script that detects a specific group in particular, that ISN'T the object's group and was wondering if there's a way to do this? I'm renting land that isnt group deedable, so the alternative isnt an option unfortunately.

The script included is what im working on at the moment, is there away for llDetectedGroup (0) to detect this particular group: secondlife:///app/group/f87e55b4-c1c5-06b9-b590-d77594b989c0/about?

Also for some reason this script has a syntax error at the else statement I cant seem to figure out, please help!

Quote

default
{ // Triggered when objects (including avatars) collide with the object containing this script
    collision_start(integer nd)
    {
        while(nd)
        { // Cycle through the detected keys of those objects that collided this time checking if each is the owner.
            if(llDetectedGroup(0));
                llSetStatus(STATUS_PHANTOM, TRUE); // Become un-solid
            else
                llSay(0, "Please have your group tag on to use the lounge");
        }
    }
    collision_end(integer nd)
    {
        if(llGetStatus(STATUS_PHANTOM)) // If the object is un-solid
            llSetStatus(STATUS_PHANTOM, FALSE); // Set the object solid.
    }
}

 

[Rolig Loon]

Second question first ... The problem isn't with the else ; it's the unwanted semicolon at the end of if (llDetectedGroup(0)); To avoid that problem in the future (or at least minimize it), get in the habit of always putting curly brackets { } around the scope of the commands in your conditional block, even if they aren't technically necessary..

Now the first question ...  You could try asking for llList2Key( llGetObjectDetails(object_key,[OBJECT_GROUP]),0)  and then comparing that with "f87e55b4-c1c5-06b9-b590-d77594b989c0"

Edited May 2, 2021 by Rolig Loon

[Love Zhaoying]

1 hour ago, JaslynMaia said:

while(nd)
        { /

Isn't the while() loop going to loop forever if (nd==TRUE) since nd is not changed in the loop?

[Rolig Loon]

Good point.

[Chic Aeon]

Just wanted to mention that a big event for the male folks tried using something like this a few months ago and it was a disaster with lots of folks (Chic waves hands madly) NEVER getting things to work even with the correct group tag on.  So PLEASE TEST YOUR FINAL SCRIPT EXTENSIVELY and with various people.   :D.  

 

 

[Rolig Loon]

That, too, is a good point.  In fact, I would recommend that you use llGetObjectDetails(object_key,[OBJECT_GROUP]) on some attachment that an avatar is wearing instead of using it on the avatar herself, for that reason.  Just use llGetAttachedList(avatar_UUID) and then grab the first key in the list .  Attachments will always have the group that the avatar has active.  

[Chic Aeon]

28 minutes ago, Rolig Loon said:

That, too, is a good point.  In fact, I would recommend that you use llGetObjectDetails(object_key,[OBJECT_GROUP]) on some attachment that an avatar is wearing instead of using it on the avatar herself, for that reason.  Just use llGetAttachedList(avatar_UUID) and then grab the first key in the list .  Attachments will always have the group that the avatar has active.  

We all know I am not a script person (well we should by now) but according to comments on that thread with of course I can't find but maybe someone else remembers) I "think" the script folks decided that was part of the issue. So maybe since this IS about scripts someone that was on that thread  can add some info.  The very ODD thing was that some folks in the group could get the gifts and others could not.  Even my alt could but I could not and on the same group tag. If I remember correctly "sometimes" it would give the item the first time but then never again?  I have pretty much wiped it from my memory as it was a very painful experience and not one that had me wanting to shop there again in the future :D. 

 

Hence my TEST TEST TEST advice.  I don't think anyone ever came up with an answer, but again -- blocked much of that out of my head purposefully. WAY too much time spent trying to figure out why it wouldn't work.  I definitely wore ATTACHMENTS and definitely had the correct group active (even left and joined again a couple of times. Others with the same tag could get deliveries. Some of us (not just me) could not.  We WERE moving to the cloud then so that "could" have been part of the issue.  

 

 

 

[Rolig Loon]

1 minute ago, Chic Aeon said:

Hence my TEST TEST TEST advice.

That's always good advice, no matter what you are creating.  Creators tend to design for normal conditions and to think only of the most obvious ways that things can go wrong.  It's almost axiomatic that the things that trip you up will be the things that you didn't anticipate.  Especially for anything that is likely to be used by a large number of people in a variety of weird conditions, it's wise to have more than one really talented (and nasty) person try to break your creation before you release it.

[Mollymews]

7 hours ago, JaslynMaia said:

Hi!

So here's the situation, I'm trying to write a script that detects a specific group in particular, that ISN'T the object's group and was wondering if there's a way to do this? I'm renting land that isnt group deedable, so the alternative isnt an option unfortunately.

The script included is what im working on at the moment, is there away for llDetectedGroup (0) to detect this particular group: secondlife:///app/group/f87e55b4-c1c5-06b9-b590-d77594b989c0/about?

 

if you are renting a parcel which is deeded to the landlord's group then a way is to use two (or more) linked prims (a linkset)

set the link prim to your group and set the root prim to the landlord's group, then link them together. The root prim (being same group as parcel) will prevent the linkset from being returned

put the collision script in your linked prim.  llDetectedGroup() will compare the group tag of the detected avatar to the group of your prim

script example:
 

collision_start(integer n)
{
   while(~--n)  // --n >= 0
   {
       if (llDetectedGroup(n))
       {
          // person is in our group so do something with them

       }
   }
}

 

a caveat: When we take the linkset into inventory and re-rez then we have to unlink the newly-rezzed, reset the prim groups as above, then re-link

[Lucia Nightfire]

15 hours ago, Rolig Loon said:

Attachments will always have the group that the avatar has active.  

Unless it's a temp attachment and the user hasn't changed their group after it attached.

By "temp", I mean attached via llAttachToAvatarTemp().

Edited May 3, 2021 by Lucia Nightfire

[bobsknief Orsini]

Rez a other box... set that one to the group... and then ask that box if samegroup() using a say and listener.

[Qie Niangao]

On 5/2/2021 at 3:31 PM, Rolig Loon said:

Attachments will always have the group that the avatar has active.  

Besides @Lucia Nightfire temp-attach case (which I didn't know about), this assumes they have any attachments at all (which is pretty safe assumption) and the object wasn't attached by wearing it "from the ground" instead of from Inventory.

4 hours ago, bobsknief Orsini said:

Rez a other box... set that one to the group... and then ask that box if samegroup() using a say and listener.

Yeah, I think this is kinda what @Mollymews meant to suggest (I'm not seeing an advantage to llDetectedGroup over llSameGroup to check the same group), except she also suggests linking that other box to one set to the land group, thus preventing auto-return from poofing it. It's moderately tricky that a linkset can have parts that belong to multiple groups.

On 5/2/2021 at 3:09 PM, Chic Aeon said:

Just wanted to mention that a big event for the male folks tried using something like this a few months ago and it was a disaster with lots of folks (Chic waves hands madly) NEVER getting things to work even with the correct group tag on.  So PLEASE TEST YOUR FINAL SCRIPT EXTENSIVELY and with various people.   :D.  

I wish I remembered the thread better, but I do remember trying to find an alt who'd fail. Pretty sure this was happening at Mancave, in case that narrows the search.

[ETA: Found the thread: 

but not seeing a real solution in there. It seems to have been isolated to a Firestorm bug/mystery feature, so whatever it was could be lurking still, although since we never saw the script, we don't actually know how to avoid it, short of telling everyone to stop using Firestorm.]

 

Edited May 6, 2021 by Qie Niangao

[Mollymews]

1 hour ago, Qie Niangao said:

Yeah, I think this is kinda what @Mollymews meant to suggest (I'm not seeing an advantage to llDetectedGroup over llSameGroup to check the same group)

 

i used llDetectedGroup in the example as OP script was using collision to trigger the check, and llDetected* were written with these kinds of events in mind. You are right tho, it could be done with llSameGroup also in the collision event

[Chic Aeon]

4 hours ago, Qie Niangao said:

but not seeing a real solution in there. It seems to have been isolated to a Firestorm bug/mystery feature, so whatever it was could be lurking still, although since we never saw the script, we don't actually know how to avoid it, short of telling everyone to stop using Firestorm.]

BUT my alt got the gifts using Firestorm so can't be completely a client issue I am thinking. AND since 75 percent of so of the population uses Firestorm it would definitely have to be a hit or miss thing with something else in the mix too :D.  But yes, you found that thread and no, we never solved this mystery. 

[LittleMe Jewell]

4 hours ago, Qie Niangao said:

this assumes they have any attachments at all (which is pretty safe assumption)

Not necessarily - at an Event, that is.  I almost always go to events wearing a full body alpha and no attachments.  Given all of the other invisible people I see, I am not alone in the 'full alpha' behavior (though other folks might still have attachments on).

Edited May 6, 2021 by LittleMe Jewell

[VirtualKitten]

Um sorry i have skim read this thread apologies if its solved, but   why are you using collision and not some form of Sensor for agents in area similar to a security ball. contact me in world and i will give you one that does not require deeding as am sure mine is not in my house.

[Rolig Loon]

4 minutes ago, VirtualKitten said:

Um sorry i have skim read this thread apologies if its solved, but   why are you using collision and not some form of Sensor for agents in area similar to a security ball.

From the context the OP described, it sounds like she's not interested in detecting people in the area.  She wants to know whether a specific person who collides with her object is in the group with UUID = "e55b4-c1c5-06b9-b590-d77594b989c0".  The answer is easy if you can set the object to that group and then use llSameGroup or llDetectedGroup, but she was looking for a general solution that would work when the scripted object is not set to the group.