Support for av-owning OR group-owning of scripted object?

I've been trying to think of a way to do this, but it appears that LSL may not have the capability I'm looking for.

I want to make an object that works as follows: if owned by an individual, it can only be activated by that av, BUT if owned by a group, it can be activated by anyone in that group. llSameGroup and llDetectedGroup seem to work well, except that if the object is not group-owned and an av does not have a group active, the object and av are considered to be in the same "group". And there doesn't seem to be any way for the object to tell whether it's owned by an individual or a group.

Any ideas? I'm surprised LSL is so lacking in this area.

try llSameGroup(NULL_KEY), I dont know if it will work, but it might be able to tell you if the object is 'group-less'

-Adam

Your best bet would probably be to use llRequestAgentData to get the name of the owner, with an integer toggle in the dataserver event designed to set "single-owner" mode, then corroborate that with the results of llSameGroup.

The dataserver event will only trigger if llRequestAgentData is passed the key of an actual agent. You can do something like, "if (owner_name == """ and so on. It's kind of messy, but it should work.

I'm not as good at group behavior as I'd like, but some strange responses to llGetOwner have led me to believe its return might help you.

Basically, in writing a script for a friend of mine, he told me that some functions using llGetOwner "weren't working" when he deeded it to group. My guess is it's returning either NULL_KEY or the group key, but again, I have not done enough testing with this.

If this is unresolved later, I'll have a look when I can log in.

Tried it. It behaves the same whether it's group-owned or not.


If an object is group-owned, llGetOwner returns the group key.

It follows, then, that you could use llRequestAgentData like Catherine described above. The dataserver event would only be called if llGetOwner happens to be an agent, and would happily remove the "no group" problem.

Alternately, if you know the group ID, you could just hardcode this functionality.

It's gonna be for sale to the public, so I wouldn't be able to hardcode it. I guess I could use llRequestAgentData then, but... ick. It just seems like such a convoluted solution to such a simple problem.

Welcome to my world.

yah check wiki they should have a script for it just make two seperate ones one for group and owner

Er... is this one suggestion or two?

First of all, what script are you referring to? I checked the wiki script library, and I don't see anything relating to this.

Secondly, making two different versions isn't a good idea. If an individual were to own the group version, anyone without a group activated would be able to use it.

if llGetOwner returns the group key for group owned objects, can't the end user set group ownership?

set = works for the group using llGetOwner
unset = works only for the owner using llGetOwner

I've never tried it for sale items, but I've set group, without sharing, and used llSameGroup to differentiate between (limited) group available commands, and (extended) owner available commands in listen filtering a visit list.

conversely is there a way to get the "none" group key?
if a detected group of "none" isn't NULL_KEY, why not just hard code the key for "none" ?
if it's not null it must be some other default right?

if( ( llGetOwner() == id ) && !( llSameGroup( key_group_none ) )

or some such?

ok so I'm stuck on how to get the group key....

just thinking out loud, can't get on atm to test any of it.

The problem here is there's a missing link between llGetOwner and discovering if that id is from a group or an individual person.



Finding if it's from a person is simple enough:

if(llGetOwner() == llDetectedKey(0))
// do stuff

But how would you figure out if they were the same group? One might try something like this:

if(llDetectedGroup(0) == llGetOwner())
// do stuff

Unfortunately, it doesn't work that way. llDetectedGroup returns an integer TRUE or FALSE depending on what group the owner and detected person are in. It does not return a group key, and for that matter, finding a group key edgewise is difficult.

That's the problem, in my opinion. llDetectedGroup should return the group key; the fact it returns an integer goes against the way the other detected commands work. There was discussion about this before, I believe.

Anyway, the short of that is you still need a way to figure out how the object is set. The simplest way is to llRequestAgentData the owner of the object and go from there... but as Beatfox mentioned, that's really bass ackwards compared to how it "should" work.

I think I've got a better handle on it...

for instance only the "owner can activate by touch"

if you test for owner, it disagrees withe the av key touching it when it's deeded to the group

if you test for same group, if the group is set to none, anyone can activate....

p.i.t.a.

ok how about testing to see if the group has permission to mod it? dunno if it's any more useful but....

integer is_group_object = FALSE;
if ( llGetObjectPermMask( MASK_GROUP ) & PERM_MODIFY){ 
//or any other appropriate permission, used mod because you need it to share
    is_group_object = TRUE;
}
else{
    is_group_object = FALSE;
}

if ( ( llGetOwner() == id ) || ( ( is_group_object == TRUE) && ( llSameGroup(id) == TRUE ) ) ){
    // do stuff like activate
}

EDIT: you may want to retest to see if the group has permisions still, since share can be revoked, and also because it'll report the inital state (false) if the script isn't otherwise updated or reset. (and fixed both the integar name and the accidental redeclaration, thank you Jeffrey Gomez =) (well I thought I did)

has the benefit of also working on share (instead of deed), and you can set it to anyone by setting share with "none)" group set. this would also allow you to set special commands for the owner, that aren't accessable to the group if you wanted.

assuming you want to automate it... of course you could just read a setting from a notecard.

Hm. Now that's a very good idea. The Perm Mask returns TRUE when shared with group or deeded that way. It returns FALSE if not.

I knew we had to be overlooking something.

PS: Integer name needs fixing, but that's a decent idea of the working code.

For more information:
http://secondlife.com/badgeo/wakka.php?wakka=llGetObjectPermMask

thanks for the catch Jeffery, edited to fix =)