ProtectionAreas (built-in)

[xoft]

This plugin lets VIP users define areas of the world where only specified users are allowed to build and dig.

An area is defined by the VIP by using a Wand item (by default, a stick with a meta 1) by left-clicking and right-clicking in two opposite corners of the area, then issuing a /protection add command. Multiple users can be allowed in a single area. There is no hardcoded limit on the number of areas or the number of players allowed in a single area. Areas can overlap; in such a case, if a user is allowed in any one of the overlapping areas, they are allowed to build / dig.

The protected areas are stored in an SQLite database in a file "ProtectionAreas.sqlite" that is created next to the Cuberite executable. The plugin has its configuration options stored in a "ProtectionAreas.ini" file.

Configuration
The configuration is stored in the ProtectionAreas.ini file next to the Cuberite executable in a regular manner.

The wand item can be specified in the configuration. By default, a stick with meta 1 is used, but any valid item can be used. Stored in the [ProtectionAreas].WandItem value.

If there is no area, players can be either allowed to interact freely or not at all, based on the setting in the [ProtectionAreas].AllowInteractNoArea value. Accepted values are 0 and 1.

Commands

General

• /protection add - adds a new protected area using wand
  Permission required: protection.add
  The following parameter combinations are recognized:
  /protection add UserName1 [UserName2 ...]
  
  /protection addc - adds a new protected area with explicitly specified coordinates
  Permission required: protection.add
  The following parameter combinations are recognized:
  /protection addc x1 z1 x2 z2 UserName1 [UserName2 ...]
  
  /protection del - deletes the specified area.
  Permission required: protection.del
  The following parameter combinations are recognized:
  /protection del AreaID
  
  /protection list - lists all areas in the specified place
  Permission required: protection.list
  The following parameter combinations are recognized:
  /protection list - lists all areas that contain the block last clicked with a Wand
  /protection list x z - lists all areas that contain the specified block coords
  
  /protection user add - adds the specified users to the allowed users in the specified area
  Permission required: protection.user.add
  The following parameter combinations are recognized:
  /protection user add AreaID UserName1 [UserName2 ...]
  
  /protection user list - lists all the allowed users for the specified area
  Permission required: protection.user.list
  The following parameter combinations are recognized:
  /protection user list AreaID
  
  /protection user remove - removes the specified users from the allowed users in the specified area
  Permission required: protection.user.remove
  The following parameter combinations are recognized:
  /protection user remove AreaID UserName1 [UserName2 ...]
  
  /protection user strip - removes the user from all areas in this world
  Permission required: protection.user.strip
  The following parameter combinations are recognized:
  /protection user strip UserName
  
  /protection wand - gives the Wand item
  Permission required: protection.wand
  

Download
The plugin is included in the base Cuberite installation. It can also be downloaded from the GitHub repository at https://github.com/mc-server/ProtectionAreas

[xoft]

Updated the description for the new version.

[Antonio]

I would like to suggest few more commands for this plugin.

protection delown - it only allows you to remove areas that you created. This way the users with only this permission are not allowed to remove someone else's. The owner of the area should be the one that created it in the first place.

protection listown - it only lists the areas you own

protection user addown - add user to your region

protection user listown - list users from your area

protection user removeown - remove user from your area

[xoft]

The plugin currently has no notion of "area owner". There's just a list of "allowed users", all equal. And the expected usage is that an admin creates a protected area for someone else, regular users are not expected to have protection-adding rights. So the commands that you're suggesting need to be re-thinked. Either we put an equation "owner = anyone allowed", then anyone allowed to build in an area would be able to add other players etc. Or we drop the "owner" bit altogether, in which case only the "listown" subcommand makes any sense.

[Antonio]

I understand that doesn't have this option but i think my suggestion was logical because the "protection del" command is made obviously for the admin but if someone wants to give 1 group this option, they can abuse it.

So i suggested this because i would like to make a group of members that can add areas themselves. This would be much easier for the admin, it doesn't have to go at each user place to create him protected area. It seems totally logical that there should be area owner.

[xoft]

I'm afraid I don't quite understand the model you're trying to describe.
If you give everyone the permission to create areas, then you can as well have no protection at all - if anyone wants to build anywhere, they just create a new area for themselves there. (note that in the current implementation the areas may intersect). You obviously don't want that, so you choose a group of people who receive the protection.add permission (usually these are called Protectors, if i recall), these can then create protection for others; yet because the permissions are separate, they needn't (but can) be allowed remove the protection. You can have another group of people called Deprotectors who can only remove protection; you can of course have people who belong to both groups, thus being able to both add and remove protection.
If this is not the model you want, could you describe yours in more detail? Name the groups, and write exactly what they should be able to do and what they shouldn't be able to do.

[Antonio]

Alright. Here is my model. If someone creates an area using the permission "protection add" they should be the owner of the area by default. By making the "Protector" the owner of the area that he/she created, using the permissions "delown,listown etc." can only manipulate his own area. The Protector cannot remove or manipulate someone else's area if he doesn't have non-own permissions "del,list etc." .

The non-own permissions "del,list etc." should be set automatically for the admin/operator, and "delown,listown etc." permissions for specific group that someone wishes to create (VIP, donators, etc).

[xoft]

That makes sense, I finally understood
And it could be actually done without creating new subcommands - for example the del subcommand could be issued by either the protectors or the admins, but if someone was deleting an area that they didn't own, an extra permission would be checked. So the permission protection.del.own would enable to delete own areas, and protection.del.any would enable to delete any area, both with the same command. Is that reasonable?

[Antonio]

Yes, the commands can stay the same. It is reasonable.

[Taugeshtu]

Xoft, can we have this plugin as a library for protection as well? I think it would be much better if we would have one really nice, versatile, fast and well-polished plugin for protections, so that we can base other plugins on it. I personally would like to write a Towny-like protection system, and I would love to base it on protection areas.

Also, could you explain why you chose storing .ini and .sqlite in MCS root folder?
It seems to me that plugins are better off storing all their junk in their respective folders, so that I can move the folder out somewhere without much of a pain.