Need help with Group Detection

[prince Zackerly]

So i was working on collapsible bridge idea aside of every thing which luckily going well, i have added a feature to use group detection so if person wearing same group tag as the group key which i have assigned in script its lets you go through other wise its collapse, but am failing on such attempt  i tried several approaches but not get any success so far what i have got in to is the object properties group if its match with user group tag its lets you go through just a simplified script for test i can share,

what am expecting is to detect the user group if same as the group key also if its get detected once  and passed or failed and user change the group tag its update  please do share your suggestion to solve this mystery

 

key groupKey = "555212fa-dd0a-1960-e694-1da1e6c9a798";

// Define two flags: groupMode and gCollapsing
integer groupMode = TRUE;
integer gCollapsing = FALSE;

default
{
    collision_start(integer num_detected)
    {
        if (llDetectedType(0) & AGENT && !gCollapsing)
        {
            if (groupMode == TRUE & llDetectedGroup(llSameGroup(groupKey)))
            {
                 // If in the same group
                 llSay(0, " You are in the same group!");
            }
            else
                {
                    // If not in the same group
                    llSay(0, "Failed! You are not in the same group.");
                }
        }
    }
}

[Floyd Sack]

llDetectedType(0) & AGENT  should be

 

llDetectedType(0) == AGENT 

I'm I'm mobile so not tested. Give it a try. 

 

Sorry for a short reply. 

[prince Zackerly]

no worry i will test it thought i was trying to filter the collision detect only with agents and as its collapsing bridge so i use flag so its not trigger the timer twice when more then one user is crossing the bridge

edits its not work how ever with old approach if i set the group on my object properties and wear same group tag its work but not match with my key in script

Edited October 21, 2023 by prince Zackerly

[Frionil Fang]

You're using llDetectedGroup(n) and llSameGroup(k) in an inverted way.

llSameGroup returns TRUE if the object/avatar/group*with key k has the same group as the object the script is in. You're always just checking your scripted object against belonging to the group, and presumably get TRUE.

llDetectedGroup returns the key of the group detected object/avatar number n has. In other words, you're doing llDetectedGroup(TRUE) in your code, which probably is not going to do what you expect.

Fix: Flip the order, get the group key first, then check SameGroup on it: if(groupMode == TRUE & llSameGroup(llDetectedGroup(0))

 

[Qie Niangao]

2 hours ago, Frionil Fang said:

llDetectedGroup returns the key of the group detected object/avatar number n has.

I don't think that's how llDetectedGroup works, though; it returns an integer and is otherwise pretty llSameGroup-adjacent. You may be thinking of OBJECT_GROUP which doesn't work on avatars (but does work on avatar attachments, which you can get from llGetAttachedList(), which has some edge-case caveats but may be adequate for this application).

[ETA: It's also possible to stick with one or the other, llSameGroup() or llDetectedGroup(), if the script can run in a prim set to the group of interest. This can require an extra step if on land with auto-return for a different group, but different prims in a linkset can be set to different groups (which may seem surprising at first), and auto-return only cares about the root prim's group setting.]

Edited October 22, 2023 by Qie Niangao

[Love Zhaoying]

I never looked at the differences too closely before.

https://wiki.secondlife.com/wiki/LlDetectedGroup

Quote: 

Returns an integer that is TRUE if the detected object or agent has the same active group as the prim containing the script. Otherwise FALSE is returned.

• integer number–Index of detection information

number does not support negative indexes.Returns FALSE if number is out of range.

https://wiki.secondlife.com/wiki/LlSameGroup

Quote:

Returns a boolean (an integer) that is TRUE if uuid and the prim the script is in are of the same group, otherwise FALSE.

• keyuuid–group, avatar or prim UUID that is in the same region

This function compares the group-uuid of the prim containing the script to that of the group-uuid of what uuid describes. It answers these two questions:

"Is the script's prim in the same group as uuid?"

ETA: I noticed that "llSameGroup()" does not include the language "SAME group"..

Edited October 22, 2023 by Love Zhaoying

[Frionil Fang]

3 hours ago, Qie Niangao said:

I don't think that's how llDetectedGroup works, though; it returns an integer and is otherwise pretty llSameGroup-adjacent. You may be thinking of OBJECT_GROUP which doesn't work on avatars (but does work on avatar attachments, which you can get from llGetAttachedList(), which has some edge-case caveats but may be adequate for this application).

Oops, yeah, my bad, should've actually taken time to double check but I was on the way out of the door.

Basically boils down to the correct form being "if(groupMode && llDetectedGroup(0))" or "if(groupMode && llSameGroup(llDetectedKey(0)))".

[prince Zackerly]

that does make sens i will go through that order and thanks for your advice

[prince Zackerly]

Quote

 

list groups = ["uuid_here"];

string get_group(key id) {
    key group;
    list worn = llGetAttachedList(id);
    integer i = 0;
    while(i < llGetListLength(worn)) {
        group = llList2Key(llGetObjectDetails(llList2Key(worn,i),[OBJECT_GROUP]),0);
        if(group != NULL_KEY) return (string)group;
        ++i;
    }
    return NULL_KEY;
}
integer check_group(key id) {
    if(llGetListLength(groups) == 0) return 0 ;
    if((llListFindList(groups,[get_group(id)]) > -1) && (llGetListLength(groups))) return 1;
    else return 0;
}

default
{
    state_entry() {
    }

    collision_start(integer n) {
        key id = llDetectedKey(0);
        if(check_group(id)) llSay(0,llKey2Name(id) + " is in the right group");
        else llSay(0,llKey2Name(id) + " is not in the right group");
    }
}

 

so its works this way and i guess the only possible way which i have found with help of you and my friend Chrissy

[Quistess Alpha]

7 hours ago, prince Zackerly said:

its works this way

Indeed, if you have multiple groups you need to keep track of, then llSameGroup and llDetectedGroup won't help.

If you're not overly concerned about 'real' security, you could instead use group tags ( llGetObjectDetails(ID,[OBJECT_GROUP_TAG]) ), and just honor system that it's too much effort for someone to make the same group tag in a different group. That would avoid the (extremely rare) situation where the attachment check method fails because someone isn't wearing any attachments, and allow different roles in the same group to have access or not independently.

Edited October 23, 2023 by Quistess Alpha

[Wulfie Reanimator]

18 hours ago, Quistess Alpha said:

llGetObjectDetails(ID,[OBJECT_GROUP_TAG]) )

OBJECT_GROUP works even better, without risk of spoofing!

Edited October 24, 2023 by Wulfie Reanimator

[Quistess Alpha]

4 hours ago, Wulfie Reanimator said:

OBJECT_GROUP works even better, without risk of spoofing!

Given that most avatars are wearing at least one non-HUD attachment (OBJECT_GROUP returns NULL_KEY when used on the avatar itself) , I'd say its false negative case is much less likely than OBJECT_GROUP_TAG 's 'spoofability'. The main reason I brought it up is because I've often forgotten it exists (there's no independent function for it) and it seemed like the OP's application (a bridge) needed security more for roleplay purposes than for actually keeping people out; maybe an opposing organization using forged road passes could lead to some interesting scenarios :P.

[Qie Niangao]

FWIW, I swear there used to be a condition where objects worn from ground (rather than attached from inventory) would be set to groups other than the wearer's active group, but I couldn't replicate that behavior, so I may have forgotten what the quirk was, specifically.

[Love Zhaoying]

6 minutes ago, Qie Niangao said:

FWIW, I swear there used to be a condition where objects worn from ground (rather than attached from inventory) would be set to groups other than the wearer's active group, but I couldn't replicate that behavior, so I may have forgotten what the quirk was, specifically.

Maybe a temp attachment scenario?

[Qie Niangao]

2 hours ago, Love Zhaoying said:

Maybe a temp attachment scenario?

That would make sense, but I didn't see it in my test (the first thing I tried because it was so easy to do) but I also couldn't find anything with "Put On…" from a rezzed-on-ground thing which is what I think I remember doing before. The jira is full of weirdness on this general subject so it appears to have changed behavior in recent years.

[primerib1]

To get a group I always try to get the first attachment on the agent, and check that attachment's group.

The last attachment may be a temporary attachment and thus exhibits the group strangeness.

Edit:

Check my script for "access level" here: https://community.secondlife.com/forums/topic/495597-a-smorgasbord-of-script-snippets/#comment-2555731

Edited November 6, 2023 by primerib1

[Crono Schism]

On 10/21/2023 at 5:49 PM, prince Zackerly said:

So i was working on collapsible bridge idea aside of every thing which luckily going well, i have added a feature to use group detection so if person wearing same group tag as the group key which i have assigned in script its lets you go through other wise its collapse, but am failing on such attempt  i tried several approaches but not get any success so far what i have got in to is the object properties group if its match with user group tag its lets you go through just a simplified script for test i can share,

what am expecting is to detect the user group if same as the group key also if its get detected once  and passed or failed and user change the group tag its update  please do share your suggestion to solve this mystery

 

key groupKey = "555212fa-dd0a-1960-e694-1da1e6c9a798";

// Define two flags: groupMode and gCollapsing
integer groupMode = TRUE;
integer gCollapsing = FALSE;

default
{
    collision_start(integer num_detected)
    {
        if (llDetectedType(0) & AGENT && !gCollapsing)
        {
            if (groupMode == TRUE & llDetectedGroup(llSameGroup(groupKey)))
            {
                 // If in the same group
                 llSay(0, " You are in the same group!");
            }
            else
                {
                    // If not in the same group
                    llSay(0, "Failed! You are not in the same group.");
                }
        }
    }
}

Try this
 

key groupKey = "555212fa-dd0a-1960-e694-1da1e6c9a798";
integer gCollapsing = FALSE;

default
{
    collision_start(integer num_detected)
    {
        // Loop through all detected avatars
        for (integer i = 0; i < num_detected; ++i)
        {
            key detectedKey = llDetectedKey(i);
            
            // Check if the detected avatar is an agent and not collapsing
            if ((llDetectedType(i) & AGENT) && !gCollapsing)
            {
                // Check if the detected avatar is in the same group as the groupKey
                if (llSameGroup(detectedKey) && llGetAgentGroup(detectedKey) == groupKey)
                {
                    // If in the same group
                    llSay(0, "You are in the same group!");
                }
                else
                {
                    // If not in the same group
                    llSay(0, "Failed! You are not in the same group.");
                }
            }
        }
    }
}

 

[Wulfie Reanimator]

11 minutes ago, Crono Schism said:

Try this

ChatGPT?

[Crono Schism]

1 minute ago, Wulfie Reanimator said:

ChatGPT?

AI but not chatgpt. Using a custom agent trained off LSL data that i've been fiddling with for awhile. Started with full guides for all things LSL but some of the methods were a bit deprecated so been trying to teach it newer methods from the wiki. Hasn't not found a solution yet. Problem with chatgpt is it guesses too much and is unethnical.

[Love Zhaoying]

6 minutes ago, Wulfie Reanimator said:

ChatGPT?

How'd you guess looking at the code that it wasn't hand-written? It did not jump out at me.

 

[Wulfie Reanimator]

2 minutes ago, Love Zhaoying said:

How'd you guess looking at the code that it wasn't hand-written? It did not jump out at me.

A human (even one that wasn't good at scripting) would not write this:

// Check if the detected avatar is in the same group as the groupKey
if (llSameGroup(detectedKey) && llGetAgentGroup(detectedKey) == groupKey)

 

[Crono Schism]

3 minutes ago, Wulfie Reanimator said:

A human (even one that wasn't good at scripting) would not write this:

// Check if the detected avatar is in the same group as the groupKey
if (llSameGroup(detectedKey) && llGetAgentGroup(detectedKey) == groupKey)

 

That's not true. I started my coding experience in SQL years ago before getting into full stack development. My biggest issue was my memory is garbage at a younger age due to always being in a hurry. I learned to put nodes all over my code as well as add checks on top of checks (and even getting away from over nesting due to thinks like resharper linting does) Like I said this agent is a wip. Currently trying to remove anything deprecated. Also trying to train it to ask for clarification instead of making guesses. (Which it shouldn't do now)

Edited November 9, 2023 by Crono Schism

[Love Zhaoying]

5 minutes ago, Wulfie Reanimator said:

A human (even one that wasn't good at scripting) would not write this:

// Check if the detected avatar is in the same group as the groupKey
if (llSameGroup(detectedKey) && llGetAgentGroup(detectedKey) == groupKey)

 

Good catch. I guess it depends on the OOP, I'd add the extra parenthesis even if I thought that I knew for certain whether && was > or < than ==!

Irony, I just "finished" adding the full Precedence to my LSL Parser. (And didn't remember where && vs. == are even after you pointed it out. Because I'd always add those extra parenthesis!)

[Wulfie Reanimator]

9 minutes ago, Crono Schism said:

That's not true. I started my coding experience in SQL years ago before getting into full stack development. My biggest issue was my memory is garbage at a younger age due to always being in a hurry. I learned to put nodes all over my code as well as add checks on top of checks (and even getting away from over nesting due to thinks like resharper linting does)

I can totally believe that, I've been (am) a really shoddy coder too! The script just has an AI-smell about it, especially after I saw that line.

It's one thing to make a silly/redundant/impossible check. It's one thing to use an imaginary function-call. It's one thing to add extra comments on every line of logic. It's a whole other thing to do all of those things at once, with otherwise very good coding style (implying a reasonable level of understanding), and confidently present it just as "try this one." 😋

Edited November 9, 2023 by Wulfie Reanimator

[Crono Schism]

2 minutes ago, Wulfie Reanimator said:

I can totally believe that, I've been (am) a really shoddy coder too! The script just has an AI-smell about it, especially after I saw that line.

It's one thing to make a silly/redundant/impossible check. It's one thing to use an imaginary function-call. It's one thing to add extra comments on every line of logic. It's a whole other thing to do all of those things at once, with otherwise very good coding style (implying a reasonable level of understanding), and confidently present it just as "try this one." 😋

lol i completely agree, once i finish this agent I want to share it but I'm thinking I would have to get permission from Linden Labs first to see if it's ok.