Add area groups

[Miner48er]

Add assigning areas to groups to enable easier faster and easier group projects setup

[ShadowNinja]

What do you mean by this? If you set up a group project you normally protect the entire area that the group will be working on and add sub-areas for each of the individuals. Can you describe in what cases this would be useful and how such a system would work?

[LazyJ]

I haven't chatted with Miner48er about this yet so I can only guess based on some prior conversations with him and our server's moderators.

I think what Miner is referring to is a way to assign player names to a group that can then be used to add all those players to the protected area without having to enter their names one-by-one each time.

This is a feature that would be beneficial to build teams. Players who regularly collaborate with specific other players on multiple projects. With a group function, any one of those players could start a project and then set the protection to a group that their playername is associated with.

For example:

shadowpawn84 picks out an area for a collaborative project. The build will be a classical-looking inn, called "Coupeville Inn". Since the inn is in an area where the build standards are a little higher, shadowpawn84 wants to use his team of master builders, the "MadMods", instead of his team of apprentice builders. He sets the Area positions 1 and 2, then enters:

/set_group_owner MadMods Coupeville Inn

The group "MadMods" could be established by:

/area_group_add <group_name> <playername>, <playername>, <playername>, etc., etc,.

/area_group_add MadMods klappspaten,ubuntuyou

To add LazyJ to the MadMods group

/area_group_add MadMods LazyJ

To remove a group entirely you must be either an admin or the group founder:

/area_group_remove <group_name>

To remove a player (or players) from a group you must be either an admin or the group founder.:

/area_group_remove <group_name> <playername>, <playername>

Turns out LazyJ really is lazy and a terrible builder so shadowpawn84 removes him from the MadMods group

/area_group_remove MadMods LazyJ

To see a list of groups:

/area_group_list

To see the list of a group's members:

/area_group_list MadMods

To see what groups a player has membership to:

/area_group_member ubuntuyou

Hopefully this is what Miner was referring to. ;)

[Miner48er]

thx that's a great way of explaining it.

[Miner48er]

Grouping multiple areas would be a nice feature too

[Sur3]

Could it be possible to use privs as groups, so I say I assign the area to everyone with a specific priv?

[S-S-X]

I think there was already something like this with factions mod, create faction add players to it and make area open for faction.

[TEbinger]

This is a great idea und would look much better when You have areas for multiple players. In the mod edutest https://content.minetest.net/packages/zeuner/edutest/ You can create an manipulate groups. Maybe You could find a solution together with zeuner https://github.com/zeuner to assign areas to defined groups in edutest.

[zeuner]

@S-S-X Indeed there seems to be some support for groups of players using the "playerfactions" mod (see https://github.com/minetest-mods/areas/blob/master/README.md ). But the "playerfactions" repository as referenced from here seems to be gone. And so is the repository referenced from the corresponding thread in the Minetest forum.

Also, the factions mods I have seen do not only expose group functionality, but they also define some or another policy for how players enter and leave groups. In my opinion, users of the "areas" mod should not be forced to adopt any such policy just to have group support in areas.

My suggestion would be to have areas optionally depend on a group/factions mod that merely contains an API, but does not dictate a policy. Then, any mod implements some group functionality could depend on that API mod, and have areas group support by doing so.

If the "playerfactions" repo being gone means the mod got abandoned, the API mod might even be called "playerfactions", then "areas" might not even have to be changed.

[zeuner]

@ShadowNinja Actually, EDUtest currently does it the way you described and implements some kind of group support by defining sub-areas for all the group members. True group support in areas would still have some advantages:

• Group access to already defined areas might automatically extend to new group members, and be gone when players are removed from the group
• For larger groups, having all the individual player names on the HUD can get quite unwieldy

[S-S-X]

@zeuner https://github.com/mt-mods/playerfactions Also: https://github.com/minetest-mods/areas/commit/aca830fd2298980758e09908087a9f5f74dff93f Also: https://github.com/mt-mods/playerfactions/issues/1

[zeuner]

@S-S-X Great, thanks. The github repo works for me.

The repos on leagueh.xyz and subdomains that I can find on the forum and even the closed issue you referenced don't. Nor does the one that can be found at https://github.com/minetest-mods/areas/blame/master/README.md#L12 . Maybe README.md should point to the github repo until there is a stable alternative. The way it is, it is bound to be rather frustrating for anyone who looks for group support and trusts the areas documentation.

I will look what it takes to harmonize the group functionality from playerfactions and edutest. I think it would be better if areas didn't need to have multiple group support implementations.