GuardCore

WorldGuard's use flag is all-or-nothing. That is the whole problem.

/rg flag spawn use deny

You just locked the doors and the furnaces and the crafting tables and the anvils and the barrels. There is no way to separate them, and there never has been. Most servers work around it by carving a sub-region around every crafting table — dozens of entries in /rg list that nobody remembers creating.

GuardCore splits that one flag into thirteen:

/rg flag spawn guardcore-use-doors deny
/rg flag spawn guardcore-use-barrels deny

Doors and barrels locked. Crafting tables, anvils and furnaces still public. One region.

---

And when a region flag is still too coarse

The flags above are per-region. GuardCore also does per-block:

Deny use-doors across a whole town, then mark the three doors that should still open.

Deny use across spawn, set chest-use-exception allow, then mark the two barrels players may take from.

Right-click with the wand. That is the whole workflow.

Every exception is scoped. It records the region it was created in and stops applying the moment the block no longer resolves to that region. Resize the region, delete it, rename it — the exception goes quiet by itself. You never leave an unexplained hole behind in whatever protection replaces it.

---

The flags

Interaction — the use split (13, all default allow) trapdoors · doors · furnaces (and smokers, blast furnaces) · crafting tables · anvils · stonecutters · smithing tables · grindstones · looms · cartography tables · brewing stands · enchanting tables · barrels

Vehicles (4) — place boats · use boats · place minecarts · use minecarts. Splitting place from use is the point: a transport hub can let players ride the minecarts it provides without letting them drop their own on the rails. And a boat is still the classic way over a spawn wall.

Movement (1) — use elytra. The other classic way over a wall, and it needs nothing placed.

Entities (2) — allow pets, for a no-pets lobby; and a mob-cleanup marker other plugins can honour.

The exception gate (1) — chest-use-exception.

Which blocks fall in which family is configuration, not code: a name-based map with *_SUFFIX wildcards, so a block Minecraft adds next month gets assigned in YAML rather than in a plugin update.

---

What you are not getting

A buyer deserves this up front. GuardCore adds granularity to use. It does not replace anything.

There is no pvp flag, no entry, no exit, no chest-access, no mob-spawning, no block-break, no block-place, no build. WorldGuard's versions of those are years older, far more widely deployed, and better tested than anything this plugin would write. Re-implementing them would mean two plugins fighting over the same events.

It is not a claim plugin, not an anti-grief plugin, and not a replacement for WorldGuard — which is a permanent hard dependency. The bundled docs include a full "which flag to reach for" table.

---

Installing it changes nothing

GuardCore acts only on a value you explicitly wrote on a region. A location no region covers, and a region that never mentions a flag, are both left completely alone. Drop the jar in, restart, and your server behaves exactly as it did — until you set a flag.

That is the only acceptable first impression for something that sits on PlayerInteractEvent.

---

It plays well with everything else

No plugin on your server needs to know GuardCore exists. Enforcement is ordinary, cancellable Bukkit events — nothing more. GuardCore calls no other plugin's API, has no hooks, and has nothing for another author to implement.

• Claim plugins: both cancel the same events, whichever denies first wins. Two independent "no" votes produce one "no". Nothing to configure.
• Area-mining tools: they act one block at a time through real events, so per-block rules apply to them exactly as they do to a manual swing.
• Pet plugins: pets are spawned through CreatureSpawnEvent. allow-pets deny cancels the spawn — no soft dependency, no integration to write.

The one listener that makes protection looser — the per-block exception override — is fenced in by five conditions, and it never overrides a denial it cannot attribute to WorldGuard. If a claim plugin cancelled the interaction, GuardCore leaves it exactly as it found it, because it has no way to know what that plugin was protecting. The dangerous escape hatch ships off, and one config line disables the whole mechanism.

There is an optional read-only query service on Bukkit's ServicesManager for a plugin that wants to ask before it acts. No API jar, and nothing should add GuardCore to its pom.xml.

---

Also worth knowing

• Flags register in onLoad(), which is the only time WorldGuard accepts them. Get this wrong and a flag plugin ships silently broken; GuardCore gets it right, reports every flag that did not make it, and makes any failed flag behave as allow rather than as an unexplained denial.
• A configurable flag prefix, with legacy prefixes. Migrating from an older setup? Set prefix: cc, legacy-prefixes: [communitycore] and every existing region keeps working — GuardCore reuses the name your data already has rather than renaming anything.
• Per-family opt-out. Twenty extra entries in /rg flag tab completion is a real cost. A family you switch off is not registered at all.
• Bulk flag sync with a dry run. Setting one flag on two hundred regions by hand is why servers give up on fine-grained flags. One command, and --dry-run reports exactly what would change.
• /guardcore where — which region resolves at your feet, its priority, and every flag's effective value. This is the command that turns "the flag is set and the door still will not open" into a ten-second answer.
• Atomic writes. The one file GuardCore owns is written temp-then-move. A half-written exception list would be a silent protection hole.
• Bilingual out of the box. English and Dutch ship complete, including the wand's name and lore. No player-facing text is hardcoded.
• Permission-driven, never rank-driven. A global bypass plus one node per family. No rank name anywhere in the plugin.
• Three modules, each switchable, each refusing to half-start when a dependency is off.

---

Commands

Command	What it does
/guardcore where	which region resolves here, and every flag's value
/guardcore flags	every flag, whether it registered, under which name
/guardcore exceptions <list|tp|remove>	manage per-block exceptions
/guardcore sync <world> <source> <target> <allow|deny> [--dry-run]	bulk flag edit
/guardcore <status|reload>	status and a live reload
/gcexception <add|remove|info|wand>	mark the block you are looking at

Full command, permission and flag reference in the bundled docs/.

---

Requirements

• Paper 1.21 or newer
• Java 21 or newer
• WorldGuard 7 — required, and the only dependency

Spigot and Folia are not supported. Install WorldGuard first, and install GuardCore with the server stopped: flags can only be registered during start-up.

---