
Village Protection for Areas
X00LA opened this issue ยท 1 comments
Information
Minecraft version: 1.21.x
Modloader: Fabric
Mod name: Areas or new mod (Village Protect) ๐ค
Feature description
Could you integrate a feature into Areas where we could toggle in the config if we want to protect the Villages from griefing in the predefined radius?
It should protect all blocks and containers as well as the villagers.
A list of containers in the configuration where we could define which containers and/or blocks the player can interact/break with would also be nice.
Something like this:
// should Areas protect your villages from griefing
// this will protect all blocks and villagers from players
// by default this feature is off
areas_protect: false,
// define what containers are interactable and what not
interactable_containers: {
minecraft:chest: true,
minecraft:barrel: true,
minecraft:workbench: false,
and so on...
}
// define what blocks are breakable
// insert here the blocks that can be broken by players divided by comma
// [minecraft:dirt, minecraft:stone]
breakable_blocks: []
Admins should always be able to interact with all blocks and containers.
Maybe adding some permissions could help to define who and what can be done by the permission holder.
- areas.protect.admin = admin permission
- areas.protect.builder = can break and add blocks, interact with and place containers, can't harm villagers
- areas.protect.interact = gives the player the right to interact with containers and villagers
That's all I can think of at the moment.
Thnx
Hey!
I appreciate the suggestion! While I'd love to add all features submitted on the issue-tracker, I've got to prioritize working on them due to having limited time. In order to see which features users would like to see most, I've created https://serilum.com/mods/requests, which shows a table with all feature request submitted.
I'm aware that this is not the reaction you were looking for, but the reality is that I can't keep up with the demand. I try to do as much as I can.
Users are able to upvote requests by reacting to the first issue comment on this GitHub page with one of the ๐ ๐ ๐ โค๏ธ ๐ ๐ emoji's. The request with the most unique reactions, will be shown at the top. You can of course add the reactions yourself too, but don't have to :). The author of the feature is already counted as +1.
I won't only focus on popular features in the upcoming years, but it does help with prioritizing. I'll probably work on a combination of popular and interesting/needed/fun submissions.
I'll close this issue with "not planned" as a way to separate an open feature request from an actual completed issue. This does not actually mean it's not planned! Incompatibilities and bug reports will still remain open.
When the feature is implemented, I'll again post a comment and close it as "completed".
Thank you for taking the time to submit the suggestion! โค๏ธ