New Group LSL Calls?

I don't usually play around with Preview, but I hopped in 1.12 the other day to check out the new groups system. I must say I'm thoroughly impressed with the new system! The interface has some bugs to work out yet, but still pretty cool.

This got me thinking about my current system with Lupinia. Right now, I have two groups, Lupinia Management, which owns the land and is reserved for staff members only, and Lupinia Citizens, an open-membership group for anyone interested in events, etc. Under the new system, with its multiple levels of group roles, I could very easily merge the two into one group, making life much easier for me, and allowing the members of what used to be Lupinia Citizens to set their home to there, etc.

However, I thought of a hitch in my idea. I have a lot of scripted objects on my land (doors, vehicle barriers, privacy signs) that currently only respond to the staff group using llDetectedGroup, and I want them to stay that way.

Will there be any LSL calls added/modified to allow different roles to control group-scripted objects? Or, will there be/is there something in the group properties to correct for this? With the new group system, I see a LOT of opportunity to merge existing groups, but this would probably be a sticking point for lots of multi-group organizations.

llIsInGroupRole(key avatarkey, string groupname, string rolename);
* returns 1 if avatar is a member of group "groupname" and is in role "rolename". Rolename can be "Owner", "Everyone", or any other valid group role name.
* returns 0 otherwise.

Ooooo, sweet! Just what I was looking for, thanks for the info

What I posted above is a feature suggestion, not something LL already plan AFAIK. Though I *HOPE* they plan it... what with the idea of having group roles, and merging groups, there is even more need for this than ever - given the inadequacy and lack of fine-grained information that llSameGroup gives.

Oh

Keep pushing for them though, they're a great idea.

Being a scripter I'd hope this sort of thing would be obvious, and they'd just include the LSL functions along with the initial features. But from what I know of LL I think it's more likely they'll include it in the next release or two, after what's in preview now.

I hope you're right about it being in the next few versions, as I too would love to see scripts able to better interact with the group system.

Yp. They'd get more bang for their buck JUST adding new features via LSL calls, then using the experience of residents when updating the UI.

Even have a "script preview". Just set up the script calls and see what people do with them, and work on the UI after the functionality has been beaten around in that preview. Imagine if they'd started with this...

llSnapshot(integer flags, string snapshot_name, vector snapshot_size)
SNAPSHOT_THUMBNAIL, SNAPSHOT_FULLSCREEN, SNAPSHOT_TO_DISK, SNAPSHOT_TO_POSTCARD, SNAPSHOT_TO_INVENTORY, SNAPSHOT_DISPLAY_UI, SNAPSHOT_DISPLAY_HUD, ...

I think I can answer for the majority of the scripters in game when I say.
"Yes, please, oh please yes, that would be wonderful!"

But even withouth the three lsl orientated powers, the API you suggested would be plenty good enough for virtually all practical uses. Even if it was object group against User's current active group, same as the llSameGroup call currently is to minimise the data the sim needed to track, that would allow people so much scope and control in how they allow group members to interact with scripted objects.

I think the 'useless' flags might turn out to be useful.

Imagine this : I have a 'radio' object for my parcel that sets the parcel stream URL for my very popular venue. But every time I get or lose a DJ, I have to change the code (or, at best, a notecard in the device) saying who can use it.
Why not just give them 'useless' permission, and make the radio check users for that permission?

The same could be done with all sorts of access controls - doors, teleporters, etc.

With regard to the privacy question... personally I think the main use of checking if someone is in certain groups is banning by group. If you plan to give us banning by group as part of the land/estate tools... then we don't really need to check the groups other people are in as much, though it'd still be useful for doing things like giving everyone a 'trust score' based on the groups they are in and then using this for access control. Imagine scripts being able to total up -points for people in bad groups and +points for people in positive ones... it'd enable scripts to move away from the 'list of allowed avs' and towards a points-based system which calculates a points score for people based on their avatar's name, age, ratings, groups and so on. This points score, calculated by LSL scripts, could then be used to keep griefers out of popular events, for example, by requiring that avs be at least X days old, or have sufficient ratings, or be a member of certain groups... etc

From: Angel Fluffy

I think the 'useless' flags might turn out to be useful.

Imagine this : I have a 'radio' object for my parcel that sets the parcel stream URL for my very popular venue. But every time I get or lose a DJ, I have to change the code (or, at best, a notecard in the device) saying who can use it.

Why not just give them 'useless' permission, and make the radio check users for that permission?



The same could be done with all sorts of access controls - doors, teleporters, etc.



With regard to the privacy question... personally I think the main use of checking if someone is in certain groups is banning by group. If you plan to give us banning by group as part of the land/estate tools... then we don't really need to check the groups other people are in as much, though it'd still be useful for doing things like giving everyone a 'trust score' based on the groups they are in and then using this for access control. Imagine scripts being able to total up -points for people in bad groups and +points for people in positive ones... it'd enable scripts to move away from the 'list of allowed avs' and towards a points-based system which calculates a points score for people based on their avatar's name, age, ratings, groups and so on. This points score, calculated by LSL scripts, could then be used to keep griefers out of popular events, for example, by requiring that avs be at least X days old, or have sufficient ratings, or be a member of certain groups... etc



I was just thinking something like this, maybe have the resident rate the groups that he thinks of as positive + and rate the groups that he thinks as negative-. I.e. llRateGroup: Lsl Haters - (made up Lsl function spur of the moment)

llRateGroup: Lsl Lovers +

or

llRateGroup: Lsl Haters -11

llRateGroup: Lsl Lovers +56 (number added to total number score)

------------------------



I think we may have something here. Then, if the person is in said group it will return what the score is to the main part of the script and calculate, if not in said group, it will return a 0. Once summed up, the total score will be master-rated by the script as "good or bad"- or w/e the resident specifies. Great Idea, maybe a proposal for it?

Too prone to being gamed. Avatars used to have exactly that system. There used to be a bonus stipend for positive ratings. They removed the bonus payments and the negative ratings sometime last year.

I think such functionality would be extremely useful. The group (in the social sense rather than SL sense) that I am involved with require 6 (or maybe even more) groups currently to manage our affairs. With 1.12 as it stands now we could probably get rid of 1 or 2 groups but a function that could check role functionality could probably enabled us to get to 2 or 3 groups.

If there's any way this functionality could be put into 1.12, please please try

The logical best would be if the number of LSL_POWER's was the same as the number of allowed roles in a group. Say 8 roles were allowed there would be LSL_POWER_0 - LSL_POWER_7 the person assigned to creating roles for the group could assign 1 power to each role then assuming the number of allowed roles(or LSL_POWERS) doesn't exceed 32 the function integer llGetLSLGroupPowers(key Agent)(the group would be assumed to be either the group the object was owned by OR set to) would work.

And please if you impliment ANYTHING that allows scripts to check group membership like this would. Impliment invite mute both muting all group invites and invites from specific groups. Very few clubs are polite enough not to scan the room and send an invite to everyone not wearing a group tag.

No, the suggested interface was that there would be a constant for each POWER that existed, and that, in addition to those, there would be three extra POWERS that could be assigned to members that didn't allow them to actually do anything in world, but could ALSO be tested for by the call - effectively, three additional "can interact with script type A/B/C" powers.

There are already more than 32 powers, so the bitfield option is out.

Not a problem - with all the fuss on the forums lately, I can imagine why you focus on making sure what you have is bug-free rather than adding new things.

Do we need to be able to look up if a Resident is in a certain role in a certain group? No, but it is very useful to do so. I don't understand the privacy question either : avatars can see all of a user's groups except the invisible ones, so why not let scripts do the same? It just automates what already happens.
Having said that, the main use for seeing someone's groups in LSL scripts is to ban by group. I hear that banning by group is already in the works, so it's probably better to just give us that until someone comes up with a more useful function for llIsInGroupRole...

I'll stop pressing the llIsInGroupRole function though - I recognise that LL has very limited development resources and that you have to focus on the most important and useful things first.

Do we need 'power' actions in groups which are used for access checks by LSL scripts? No, we don't *need* them but they would be very, very nice. They could make it possible to merge a lot of groups which exist solely for permissions, and get away from the annoyance of having to change your active group to use certain scripted objects. They'd be convenient, useful and reduce the number of groups in the DB by allowing group merges.
So yeah, LSL_POWER_1, LSL_POWER_2 and LSL_POWER_3 would definately be a good idea.

It's a little frustrating that we can't OR the permissions, but not really that bad as I imagine AND will get used for permissions much more than OR will, anyway. Besides, if it's a function that returns in reasonable time without using dataserver, it'll be easy to just use || in LSL script to achieve the same thing.

Thank you Kelly for considering these ideas