v18.3.5: opt-in PvP and PvE combat trust for claims

GriefPrevention3D v18.3.5

Wiki: https://github.com/castledking/GriefPrevention3D/wiki

Overview

This release adds two new claim trust types — PvP trust and PvE trust — that give claim owners per-player, per-claim consent over combat. They exist because wind charges, mace smash knockback, and the knockback protection introduced in v18.3.x made "who is allowed to shove whom" a real question, and neither of the existing answers was right:

• Container trust was the only thing gating animal knockback/damage, so handing someone chest access also handed them the right to yeet your horses across the pen;
• Access trust was the only early-allow for player-vs-player knockback, which conflated "can press buttons" with "may fight here".

Both new types are opt-in server features, disabled by default. With both flags off this release behaves exactly like v18.3.4 — no new commands appear, no protection rules change.

Configuration

GriefPrevention:
  Claims:
    AllowPvPTrust: false   # enables /pvptrust, PvP trust checks, and PvP trust in /trustlist
    AllowPvETrust: false   # enables /pvetrust, PvE trust checks, and PvE trust in /trustlist

The two flags are independent: a PvP server can enable only AllowPvPTrust, a PvE server only AllowPvETrust. /gpreload applies flag changes immediately — see Hot reload below.

What each trust type does when enabled

Unchanged on purpose:

• armor stands, item frames, and paintings still require Build trust (destruction, not combat);
• hostile monsters are never protected;
• self-knockback (wind charge jumping at your own feet) never required trust and still doesn't;
• PvP safe zones and fresh-spawn immunity are evaluated above the new trust checks, so spawn protection cannot be trusted away;
• buttons, levers, and doors triggered by explosions (wind charge flicks) remain an Access-trust question, not a combat one.

When a flag turns on, the legacy level stops covering that target entirely: enabling AllowPvETrust means container-trusted players can open chests but can no longer hurt or knock back creatures unless separately granted PvE trust. Enabling AllowPvPTrust means Access trust no longer acts as the player-combat early-allow. Because the flags default to off, no existing claim changes behavior until an admin asks for it.

Standalone by design

PvP/PvE trusts sit outside the normal implication hierarchy in both directions:

Owner/Edit -> Manage -> Build -> Container -> Access   (implies everything below it)
PvP, PvE                                            .  (implied by nothing, imply nothing)

Granting /trust <player> (build) does not silently hand out combat rights after an admin flips the flag on, and granting /pvptrust never grants access to anything else. Combat trust is stored in its own per-claim sets rather than the interaction trust map, so granting container trust after pvp trust cannot overwrite it, and vice versa.

Inheritance matches every other trust level: first-child subdivisions inherit parent grants, nested subdivisions do not, and a subdivision can block an inherited grant with a deny entry (#pvp / #pve suffixes).

Commands

/pvptrust <player>                      standalone; permission griefprevention.pvptrust
/pvetrust <player>                      standalone; permission griefprevention.pvetrust
/claim trust <player> pvp|pve           typed grant through the unified interface
/claim trust permission <node> pvp|pve  permission-node grant
/aclaim trust permission <node> pvp|pve same, administrative form
/untrust <player>                       revokes combat trust along with everything else

Notes:

• griefprevention.pvptrust and griefprevention.pvetrust default to allowed and are children of griefprevention.claims, mirroring /accesstrust and /containertrust.
• Permission-node identifiers ([your.node]) and public work exactly as they do for other trust levels.
• Tab completion for the trust-type argument reads the config live, so pvp/pve suggestions appear and disappear with /gpreload.
• /trustlist lists PvP-trusted players in red and PvE-trusted players in aqua, with a legend entry for each — but only while the matching flag is enabled, so servers that never opted in see the exact same output as before.

Enforcement details

The knockback protection handlers branch on the flags at event time:

• handleKnockbackPlayer requires an explicit PvP grant where it previously accepted Access;
• handleKnockbackEntity requires PvE instead of Container for protected creatures.

Everything downstream of those gates (safe-zone messaging, fresh-spawn immunity, rate-limited errors, /gpdebug knockback tracing) is untouched. Debug output now names the specific rule that fired, e.g. denied: attacker X lacks PvP trust in defender's claim N.

Storage

No migration is required or performed; the feature ships inert.

• Flat file claims gain optional PvP Trusted / PvE Trusted list keys. Older plugin versions ignore them; older files load unchanged.
• The database schema moves from version 12 to 13. Startup adds two nullable TEXT columns via JDBC metadata inspection (the MySQL-safe path used for the denied column), then rewrites claims once.
• The platform-neutral gp3d-core claim codec carries both sets through document encode/decode, so Paper ↔ Fabric claim moves preserve combat trust losslessly. Grants persist even while their feature flag is disabled, so toggling a flag off and back on never loses anyone's trust.

Also in this release

• Neighbor trust (/neighbortrust, /distancetrust, allowAllNeighbors) persistence was hardened on both Bukkit and Fabric, including manual-neighbor survival across flat-file migration.
• Upstream merge: interacting with an untamed horse no longer clears its equipment (#2624).