Stupid Group System

"You cannot join The Happening, because you are already a member of the maximum allowed number of groups (15)."

Gee thanks, group system, thanks a lot.

Could be worse - remember when we could only have 5?

Then again Bill Gates said something totally retarded about how much memory a computer needs too

Shit, only five? That's so sad.
I can still remember 10 and how little that was. For a time i couldn't fill the 15, but now I could use some extra room for new groups to.

Yup. Annoying as all get out. I have to juggle one space for all such happenings as The Happening. Tiresome.

If we could bring the Group System to life, then we could torture it to death slowly. That would be nice.

This is one of the prices we pay for unlimited inventory and unlimited alts. Limited resources must be balanced and all the important people have made themselves very very clear in saying that they will all quit if our inventories are capped.

Please explain how these are related.

We don't get unlimited alts so far as I can tell.

True, we can only have five accounts on one credit card. How many accounts is that per average player? I suppose the best argumentative response is "I only have one credit card so that must be the average."

Alt accounts generate inventory records just like main accounts do. I know people with as many as three alts that each carry twice the inventory than I have on Khamon. My couple of alts carry little to no inventory btw; my small contribution to the effort.

Premise A: Group records, due to their many-to-many nature generate an excessive number of hits to the asset system every time a group is referrenced in profile, land management, IM et cetera. Those hit are about to dramatically increase in number as group communication and inventory tools are improved.

Premise B: The same asset system that manages all of our group related data also manages all of our inventory records. An obvious physical limit exists here; however, we're afforded the capability of creating, storing and referencing as many of these records as we please. This is an absolute requirement. Discussions about capping inventory numbers have always ended in a few people threatening to quit.

Conclusion: LL have decided to cater to our possesive nature and let us keep our unlimited inventories. People who abuse the system naturally lose half their belongings occassionally through standard database errors anyway. But other limitations have to be placed on the asset system in order to afford us this pleasure. The group limit is one such consession.

Now if you ask people "would you rather have fifty group slots and be limited to fifteen-thousand non-stacked inventory items," they might find that a reasonable proposal. If you can get them to agree to it, you're a better person than I.

That makes no sense at all.

A group membership requires storing a single UUID, 128 bits. Only one group membership (the active group) has to be in memory at a time: you can't check against inactive groups so there is no ongoing access to the asset system for non-active group memberships.

So, for the cost of a single uncompressed 64x64 alpha texture in the database you could store your membership info for 1024 groups (128 bits in your database entry and 128 bits in the group's database entry for each group, divided into 64*64*32=131072 bits). That means that if ALL 40 of the agents logged into a sim at once have all 1024 groups populated, the sim would have to cache a total of 655k of data from the asset server. That's half as much as a single 512x512 alpha texture.

The group limit is a policy limit, to keep the number of groups an agent is in small enough for the player to keep track of. It's got nothing to do with hardware resources.

Okay, maybe you can make sense of the following quotes for me:

from the second meeting

Robin Linden: First, looking at general characteristics (size and number allowed)
...
Eloise Pasteur: You said in phase 1 raise number of groups? Roughly how high are you thinking?
Kamael Xevious: That's what I mean and hallelujah!
Robin Linden: I'm not sure yet Eloise...it depends on what the devs tell me with respect to the database hit

from the third meeting

Robin Linden: Jana I want to increase the number of groups.
Robin Linden: However it's a hit to the database so the question is how many to allow.

from the fourth meeting

Robin Linden: Groups are database intensive

I suppose anytime you open a person's profile it causes the system to look up data for all the groups a person is in.

So change the profile display so that it doesn't show group membership until you specifically request that info.

Yeah that's one example. Right now they simply tack sixteen group fields onto our profile, easy to update, easy to display. If they related us to any number of groups with a bridged table, the system would have to load, sort and search the entire table every time someone viewed a profile. Taking the group listing out of the profile would work to solve this problem, but would only solve this one instance of group data access.

I interpret this as "there's some really bad design decisions in the way groups have been implemented, and we made the business decision not to fix them."

There's nothing in-game that needs to know what groups an avatar is in, except for the active group. You don't need to know that for broadcasts to a group, or any other group operations, because you're always either checking the avatar's active group or the group's looking at the list of avatars in it.

The only things that need to look at the groups an avatar is in are the user interfaces: the profile, and the user's own group editor. The profile can be solved by moving groups to a separate tab, and the user's group editor can be efficiently cached by the client.

Are you suggesting that there is a static array of 15 group info records actually stored in the profile data structure instead of a list of group identifiers, with the data being looked up as needed?

Dear god, if so, what a foolish decision that was.

Yeah we used to talk about this stuff but finally just gave up.

I supppose you wouldn't want a fixed size list of group identifiers stored in the profile either. Instead you'd have a separate database with a record for each avatar key and group key pair, and separate database for the groups.

That's something along the lines of what you meant in the thread you linked to when you said "things such as group affiliations have to be normalized into their own table."

Perhaps the profile data structures could be repurposed? Open the system up to let third party sites manage group membership lists, with the ability to send data inworld?

I can't even get accepted into an SL volunteer group other than the one I am already in because I am grouped up. Sheesh.