Minecraft Plugin Idea: Exclusion Zones for Coreprotect

readme.md

Coreprotect Exclusion Zones Plugin Idea

This is just a mockup. As of writing this this plugin does not exist.

This plugin provides a way to exclude areas from coreprotects various logging methods. Cou can define multiple sets of 2 coordinates and locations inbetween will be excluded from coreprotect logging. There is a command to add areas to the config file. By default all actions except chat, session, click, and command are excluded. It also supports worldguard regions and Griefprevention claims. (These 3 types of areas will be referred to as zones, regions and claims respectively)

#config.yml

enable-worldguard-support: true
enable-griefprevention-support: true
verbose-logging: true

rebuild-cache-on-edit: false
# If the zone cache should be rebuild whenever a flag is added/removed.
rebuild-cache-on-region-resize: true
# If the zone cache should be rebuild whenever a worldguard region is resized/removed/added.
rebuild-cache-on-claim-edit: true
# If the zone cache should be rebuild whenever a griefprevention claim is resized/removed/added.

default-exclusions-for-new-zones:
  - block 	    #blocks placed/broken
  - +block 	    #blocks placed
  - -block 	    #blocks broken
#  - chat 	    #messages sent in chat
#  - click     	#player interactions
#  - command 	#commands used
  - container 	#items taken from or put in chests
  - +container 	#items put in chests
  - -container 	#items taken from chests
  - inventory 	#items added or removed from player inventories
  - +inventory 	#items added to player inventories
  - -inventory 	#items removed from player inventories
  - item 	    #items dropped, thrown, picked up, deposited, or withdrawn by players
  - +item     	#items picked up or withdrawn by players
  - -item 	    #items dropped, thrown, or deposited by players
  - kill 	    #mobs/animals killed
#  - session 	#player logins/logouts
#  - +session 	#player logins
#  - -session 	#player logouts
  - sign 	    #messages written on signs

new-areas-enabled-by-default: true
new-areas-ignore-y-by-default: false

#DO NOT EDIT!
area-counter: 1
 
exclusion-zones:
  1:
    #This is an example zone.
    enabled: false
    world: 'world'
    ignore-y-level: true #This means the y-level will be ignored and treated as the highest and lowest block in the dimension.
    x1: 120
    y1: -63
    z1: 320
    x2: 160
    y2: 155
    z2: 400
    excluded-actions:
      - block
      - +block
      - -block
      - container
      - +container
      - -container
      - inventory
      - +inventory
      - -inventory
      - item
      - +item
      - -item
      - kill
      - sign

I am not sure how hard it is to actually implement the plus and minus action seperately. If either only the generic, or only the plus minus action explictily are implemented that is fine.

Commands

/exclusions new zone <x1> <y1> <z1> <x2> <y2> <z2> [block|+block|-block|chat|click|command|container|+container|-container|inventory|+inventory|-inventory|item|+item|-item|kill|session|+session|-session|sign]

/exclusions new fromselection [block|+block|-block|chat|click|command|container|+container|-container|inventory|+inventory|-inventory|item|+item|-item|kill|session|+session|-session|sign] Uses the current world edit selection to create an nex exclusion zone.

/exclusions flags add|remove [block|+block|-block|chat|click|command|container|+container|-container|inventory|+inventory|-inventory|item|+item|-item|kill|session|+session|-session|sign] [#claim|#region|#zone] The feedback should make it very clear that tis action is then NO LONGER tracked since we are dealing with double negatives a lot in the cmd syntax

/exclusions enable|disable|delete|ignore-y-on|ignore-y-off [#claim|#region|#zone] Confirmation messag that it will remove the zone. Or remove all exclusion flags if it is a claim or region.

/exclusions flags list [#claim|#region|#zone]

/exclusions reload #reloads zone data and rebuilds caches

/exclusions prune #checks for orphaned claim data and removes it

If there are 2 zones overlapping for some reason the command will fail and ask you to specify if you want to target the claim, the woldguard region or the native zone with #claim, #region, or #zone.

For regions this would just hook into worldguard flags. Every action should have a flag like -exclude-co-block and -disable-all-exclusions-flags

For Griefprevention in the past I created fake player in the trustlist to store data prefixed with a dot. This could either be 1 fake player entry per set flag (.exclude-co-block) but this would allow players to exclude their claims from logging. A better system would be to try and find the claim ID and store the flags somewhere else in a seperate file and then read them out. This system would also need to remove empty entries in case we remove all exclusion from a claim and if a claim itself is removed to prevent orphanaged data.

Premissions

exclusions.reload exclusions.prune

exclusions.create.claim exclusions.create.region exclusions.create.zone

exclusions.delete.claim.own exclusions.delete.region.own exclusions.delete.zone.own

exclusions.delete.claim.other exclusions.delete.region.other exclusions.delete.zone.other

exclusions.enable.claim.own exclusions.enable.region.own exclusions.enable.zone.own

exclusions.enable.claim.other exclusions.enable.region.other exclusions.enable.zone.other

exclusions.disable.claim.own exclusions.disable.region.own exclusions.disable.zone.own

exclusions.disable.claim.other exclusions.disable.region.other exclusions.disable.zone.other

exclusions.list.claim.own exclusions.list.region.own exclusions.list.zone.own

exclusions.list.claim.other exclusions.list.region.other exclusions.list.zone.other

In the follwoing block is an example for all possible actions and wildcard.

exclusion.add.region.own.block exclusion.remove.region.own.block exclusion.add.region.other.block exclusion.remove.region.other.block

exclusions.alwayslog.block #Players actions bypass the exclusions. their actions will always be logged. (Useful for players that are ne wor received warnings)

On load all exclusions zones should probably cached. Resizing a claim or a region should also trigger an update to the cache. Ideally the cache should do some deduplication/optimzaton to for overlapping areas. I do not know what the best approach is here. A seperate cached list of zones for every action? If possible the events that co tracks should be excluded in batches when the queue is saved to the database. Checking every event the moment it occurs is probably more taxing. The main point of the plugin is to reduce storage space on disk by excluding protectd areas with farms that create a lot of logging entries.

If 2 areas overlap and one of them has an exclusions that is excluded.

The verbose logging should record how long it took to filter each batch of data submitted to the datbase and how many entires were filtered.

All text feedback should be stored as a configurable string in the config.

Possible roadmap for the future

• Include the plugins lands, griefdefender and plotsquared.
• Add more nuanced per player exclusions.
• Detecting chunks were an action happens a lot in a specific time and start excluding it (auto farm migitation. Raid farms create a lot of data...)
• More specific filters for zones in the config like "exclude-source: #redstone"
• More detail logging and notifications especially with aut farm migitation if implemented. ("Zone info: 113717 actions have been excluded from this region. 5244 in this chunk in the last hour", "arm detected: Chunk -310,-19 will temporarily exclude block events", etc)