500 groups instead of 25 and group IM mute

I suggest that the limit on the number of groups one can be in be raised from 25 to 500 and that group chat mute be implemented along with the increase in number of groups one can be in. Group chat must also be able to be kept out of the scrolling up the screen text.

I support. This would be a very nice way to allow people to rent out mainland without having to allow a large number of people access to it

certainly yes to >25 groups. Mine are full..maybe I'm just easily lured in by clubs/groups/classes!! I guess it all creates server load though, but 25 isn't enough for me and many others!!

I would like to see both of these things happen. I don't know if they are going to let us jump from 25-500 but even a 100 groups limit would be great.

I gather that most of the reason why they limit groups is that groups represent a nontrivial amount of load on the sim. Think about it... groups are tied to the permissions system (for share with group and all of the other abilities in the new group system), and every action you take needs to be checked against ALL of your groups (not just your active one).

If you want to see an example of the level of processing groups take, try this:

1. Turn on Show Updates (control-alt-shift-U)
2. Change your active group title.
3. Watch the sim around you.

Every single thing you could see just got updated from the sim. That's because the sim had to notify your client about the rights you have on all of the objects around you, since some actions do require you to have your group title active (like editing a shared script in a shared object).

I think that when you start a data storage, processing, and transmission company, you'd best be prepared to store, process, and transmit high volumes of data.

I second that, too - more than 25 would be nice. But if it is true that every group membership adds to the load, then of course that translates into cost for LL.

A possible solution would be a small charge in addition to the group membership fee (if not free), for entering any group after your 25 are full. What say, L$10 or even L$50 couldn't possibly hurt too much? Of course, the amount would have to be determined by LL to reflect the actual cost.

The main issue with raising group count is that group information currently follows you around with the rest of your avatar information. So if you're in 25 groups, the sim you're in has to download ALL 25 groups and send the info to you, it then has to pass it on to the next sim if you leave to go somewhere else.

They really need to rethink how group info is stored and handled in general before they can just increase. I didn't see why they couldn't just have infinite (or a really big number) of groups but in light of the info following you around it becomes a bit clearer. It is however another of those things that helps to limit stress on a single machine, as once a sim has your group info, it becomes responsible for handling that info and sending it to the next sim etc, only ever communicating with the central server(s) if you change something about a group.

I don't know about 500, but even 25 is definitely not enough any more.

To avoid the DB overhead, perhaps you could have "active" and "inactive" groups. You could have a limit of 25 (or even fewer) active groups, but instead of "leaving" a group to make room you could make your membership in it "inactive". Inactive groups wouldn't be selectable in the group editor, and may not even show up on the main group list in that window. They wouldn't show up on your profile. You, naturally, wouldn't get any of the rights from membership in inactive groups. Basically, they wouldn't interact in any way that would cause database load.

The only difference between leaving a group and making it inactive is that you wouldn't have to be invited or pay again to reactivate it, and you would be visible (as inactive) to other members of the group (again, perhaps in another tab).

lol youd need the group mute before the 500 limit 0.o

Otherwise the spam would kill you!

I would go so far as to suggest making it so that you don't get to exercise any of the powers a group entitles you to unless that group is your active group. I think that might make it so that the group system scales a lot better -- although I can't be sure because I don't know enough about the system. I guess there might be problems with this, though... situations in which you need to be able to exercise powers for more than one group at the same time. Can anyone think of an example?

One thing about groups - they are designed to serve the purpose of buying land. Of the twenty five groups that I am in, only one has any land. Groups such as Scripters of Second Life, Mental Mentors, Instructors, SL Chat, etc. aren't created to buy land to put group builds on; they are created in order to chat. The system is storing information it doesn't need to have in order for the group to serve its purpose as a chat channel.

I made this post upon discovering the NMC group of sims, a good sized bunch of adjacent sims operated by the New Media Consortium. These sims are off limit to the general public. Some of them are open to a group called NMC Guests. In order to see what's going on in those sims I had to quit a group so that I could join that group.

Looking at all of my groups, only 8 actually deal with/grant some kind of land permission, 7 are interest groups or groups of friends where chat and notices are the only reason to have them, and 10 are groups that really only exist to send out notices.

I still think it makes more sense for LL to come up with a way to have a lean, slimmed down way of "grouping" that just has conference sessions and notices and nothing more.

That basic idea should already be applied really but as I understand it it isn't. The only group you actually need to have the permissions info for is your active one (under the current system rather than re your suggestion), I see no reason why other group perms would need downloaded by the sim or the client. Really when you log-in all that the sim needs is the perms for your active group, meanwhile your client just needs to download a list of group names you are in (if it hasn't got it cached already). Then when you view a group's info it can download the rest, caching that too and fetching a timestamp for the last time a group update occurred (at which point it just dls the changed parts be it new/altered/removed members or an announcement etc).
Basically groups should behave like inventory, which only downloads when you open inventory, and which seems to be cached (I don't see it downloading every time at least). Meanwhile the sim just grabs your active group, and then any groups you wish to view as required.

That way you could have a billion groups and it won't add any overhead except the first time you download the list of group names (and nothing else).

In many cases you can't already, but what about access to land? You shouldn't need to change your group title to the group owner of the land you've set home in before you teleport home, not to mention... what happens if you're a member of two groups with adjacent parcels in different groups?

Now, personally, I'm all in favor of making access controls as annoying as possible for people who use them so that people won't use them unnecessarily, but I really doubt Linden Labs would agree.

Perhaps you could send messages to "suspended" groups, and get messages from them, so you'd only need to leave groups that control permissions "live", and only the messaging code and group editor would need to look at suspended groups.

Also, what about deeding objects to a group? You can change what group an object belongs to without changing your active group.

As I understand it, there's a big issue with the scaling up of the world population and groups/friends. Everything else, sims, asset server etc, can just scale up linearly with the number of people there are. They are "local" problems, in the sense that the solution involves only a small part of the grid.

Groups and friends lists are different, because processes there potentially require data that is distributed over the entire grid, and things go order n^2 rather than order n.

Hmm, iirc the only way you can restrict land access is by whole group or by user key. So in that case the avatar's group membership can be queried, the sim shouldn't need anything else. To speed this up the client can simply use it's list of keys to assume it can enter the land, meanwhile the sim decides if it's going to let you keep going or kick you back to the border again.


The perms can be requested when that change occurs. Changing an object's group again can be queried as needed, with the client able to assume the change occurred (since it knows which groups you are in already).

That is *precisely* where the N^2 effect comes in. The sim has to know *all* the groups that *all* the avatars in the sim are in, that *any* object or parcel in the group is in.

That. Is. What. Already. Happens.

That. Is. What. Already. Happens.

Group info is passed around with the rest of your avatar info, hence the limit on them in the first place. What I'm saying is that the sim doesn't need to download any info unless you try to enter a restricted parcel, while it's fetching this info the client can just let you wander in (assuming the parcel is restricted using a group key you belong to).
This way the client is the only thing that cares about ALL the groups you are in (and even then, only names and keys), meanwhile the sim only cares if you're in a group when you do something that actually requires that information.
It would also require less overall info as it's just a boolean case of "Is avatar X in group Y" to whichever server or group of servers are concerned with the particular group. The data can still be cached and handed around with the avatar, but only info that has actually been used. So if you're in a billion groups but only 5 ever needed to be checked, then only five groups of info go around with you.

Ah, see, now there's the counterexample I was looking for. I guess that means my idea won't work.

Which you can do 35 times a second, and it's the *sim*, not the *client* that moves you into the parcel. The client smooths out your motion between updates from the sim, but that's all it does.

The sim also needs to know what rights you have in every parcel on the sim, and in neighboring sims, out to your select distance, to allow or deny building or editing terrain or whatever out to that limit. And, again, it's the sim that does this.

Changing things so that the sim only needs to carry around part of the information is going to cause all kinds of bugs and exploits while it's working things out. being able to "suspend" groups, and not including "suspended" groups in this package of data, is easier to understand and implement and much less likely to cause problems.

Having started to become a merchant, I find I have to join a group every time I open a stall in a new location so that the stall doesn't get returned. You can end up needing a lot of groups that way ...

We definitely need more than 25 groups, but 500 I suspect is overkill. I'd be happy with 50, probably, but can see some folks using 100. BUT -- we definitely need a way to differentiate between groups with permission data that matters and groups that exist only for chat or business notices. And it would certainly be nice for the system to just know if we're in a group with permissions and not have to remember to re-activate a group every time we want to rez a piece of furniture in a rented home.

And while we're at it, can we get a dropdown list that shows all our possible group titles at once, so we can select the best one for the occasion?