The Vanilla Experience (Mod) (Forge)

The Vanilla Experience (Mod) (Forge)

118k Downloads

Village Protection for Areas

X00LA opened this issue ยท 1 comments

commented

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

commented

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! โค๏ธ