ВЕРСИИ (174)

# GriefPrevention3D v19.0.1 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki Back up `GriefPreventionData` before updating. ## Fabric: inactive players' claims expire Fabric used to ignore `Claims.Expiration`. It now cleans up claims as the plugin does, so abandoned claims no longer pile up on long-running servers. - **`Claims.Expiration.AllClaims.DaysInactive`** (60 days by default) deletes all of a player's claims once they have been away that long. - **`Claims.Expiration.ChestClaimDays`** (7 days by default) deletes a player's only claim sooner, if it is no bigger than a new player's claim (`Claims.AutomaticNewPlayerClaimsRadius`, 4 by default, a 9×9 claim). With Fabric's default minimum area of 100 blocks, few claims are that small. - As on the plugin, one claim owner is checked every `Advanced.ClaimExpirationCheckRate` seconds (60 by default), going round every owner in turn. These players keep their claims: - anyone online; - anyone with at least `ExceptWhenOwnerHasTotalClaimBlocks` claim blocks (10000 by default), or at least `ExceptWhenOwnerHasBonusClaimBlocks` bonus blocks (5000 by default); - anyone with **`griefprevention.dontexpire`**. `griefprevention.dontexpire` works with LuckPerms even while the player is offline: their LuckPerms data is loaded for the check and released afterwards, so a grant on a group they belong to counts too. Without LuckPerms, server operators are exempt, which is the permission's default. If the check fails, the claims stay. Expired claims are deleted without the `AbandonReturnRatio` penalty, and each one is written to the server log. Other Fabric mods can keep a claim from expiring through the new `ClaimExpirationCallback`, as plugins can with `ClaimExpirationEvent`. ### When the first claims can expire Fabric learns when players were last online from `GriefPreventionData/LastSeen.yml`, which started recording in 18.4.7 (26 September 2026). Players not seen since then keep their claims, as the plugin keeps the claims of players without a last-played time. With the default 60 days, no claim can expire before late November 2026. ### New command | Command | Permission | What it does | |---|---|---| | `/checkclaimexpiry [player]` (`/claimcheckexpiry`, `/aclaim checkexpiry`) | `griefprevention.checkclaimexpiry` | Shows when the owner of the claim you stand in was last seen, when their claims expire, and what keeps them | Checking another player by name also takes `griefprevention.admin.checkclaimexpiry`, which only operators have by default, as on the plugin. ## Spigot and Paper - **Indonesian messages.** Set `GriefPrevention.Locale` to `id_ID`, or let `PerPlayerLocale` pick it for players whose client is set to Bahasa Indonesia. - bStats now reports the server software by its name (for example Paper or Purpur), from upstream GriefPrevention (#2667). ## Config New Fabric `config.yml` keys, matching the plugin. They are added to existing files on startup without changing anything you have set, and `/gpreload` rereads them: ```yaml GriefPrevention: Claims: AutomaticNewPlayerClaimsRadius: 4 Expiration: ChestClaimDays: 7 AllClaims: DaysInactive: 60 ExceptWhenOwnerHasTotalClaimBlocks: 10000 ExceptWhenOwnerHasBonusClaimBlocks: 5000 Advanced: ClaimExpirationCheckRate: 60 ``` ## Upgrade notes - **Expiration is on by default on Fabric**, as on the plugin. To keep every claim, set both `DaysInactive` and `ChestClaimDays` to `0`. - If a Fabric expiration setting cannot be read, expiration turns off and the error is logged, instead of falling back to the defaults. - `Claims.Expiration.UnusedClaimDays` and `AutomaticNatureRestoration` are not on Fabric yet. Both need restore nature, which Fabric does not have. Both versions still ship in one `GriefPrevention3D.jar`: 1.8 through the latest release on Spigot, Paper, Purpur and Folia, and 1.21.2 through 1.21.11 and 26.1 through 26.3 on Fabric.

# GriefPrevention3D v19.0.0 **Now a stable build.** One universal JAR runs as a Bukkit plugin and as a Fabric dedicated-server mod. Fabric requires Fabric API. Back up `GriefPreventionData` before updating. ## Fabric claims and commands - **Create and manage claims.** Basic and administrative claims, 2D and 3D subdivisions, claim lookup, abandonment, trust, trust lists, and staff claim management are available through the same command aliases and permission nodes as the plugin. Fabric has no economy integration, so paid claim transfers are refused unless the player has the free-transfer permission. - **Shaped claims.** Enable `GriefPrevention.Claims.AllowShapedClaims`, then use `/shapedclaims` (alias `/shapedclaim` or `/claim mode shaped`). With the golden shovel, right-click the outline's corners in order and click the first corner again to close it. The live path and finished claim both show corner nibs and boundary markers. Clicking an existing 2D claim boundary starts a reshape. - **Extend claims.** `/extendclaim <numberOfBlocks>` (aliases `/expandclaim` and `/resizeclaim`) extends or shrinks the most specific claim at your location, or the claim selected with the shovel nib. It supports 2D and 3D claims, subdivisions, and shaped outlines. - **Inspect claims.** The configured investigation tool (`STICK` by default) shows the claim at the targeted block; sneak-use it to visualize nearby claims. The golden shovel displays claim boundaries and supports claim selection. - **Resize with the scroll wheel.** `/scrollresize` previews a claim or subdivision while scrolling and applies the change on right-click. Looking down selects the bottom face of a 3D subdivision. A selected corner is range-gated to avoid a corner click registering through to a farther block. Shaped claims are disabled by default. `AllowShapedSubClaims` also defaults to `false`; `ShapedMinimumWidth` and `ShapedMinimumArea` control their size rules. `Allow3DSubdivisions` defaults to `true`. These settings are read from the existing `config.yml` and added on startup when missing. ## Claim protection - Explosions respect the configured land-claim and surface explosion protections, including protected entities. - Starting or extending a raid requires build trust in the raid-center claim, or in the triggering player's claim when the raid center is unclaimed. `Claims.RaidTriggersRequireBuildTrust` defaults to `true`. ## Compatibility and packaging - One Modrinth release lists Bukkit, Folia, Paper, Purpur, Spigot, and Fabric, using this combined changelog. - Fabric supports Minecraft 1.21.2–1.21.11 and 26.1–26.3 on dedicated servers. Bukkit-family support starts at Minecraft 1.8. - Modrinth stores one game-version list for all loaders on a release, so this listing advertises the Fabric targets. Bukkit support for older Minecraft releases remains available through Spigot and the universal JAR. - The universal JAR is about 2.2 MB, below the 5 MB target. ## Upgrade notes No claim migration is needed. Existing settings remain in place; new config keys are added with the defaults above.

# GriefPrevention3D v18.4.14 — Fabric (experimental beta) **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki **Roadmap:** [platforms/fabric-common/ROADMAP.md](https://github.com/castledking/GriefPrevention3D/blob/master/platforms/fabric-common/ROADMAP.md) > **Still a beta, dedicated-server-only build.** Back up `GriefPreventionData` before updating. Requires Fabric > API; LuckPerms is optional but recommended. ## Overview Two changes land on Fabric. Minecraft 26.3's cushions, which arrived without any claim protection, are now protected like other decorations, and the new per-player glow toggle from the Paper side comes to Fabric as `/claimglow` and `/gpglow`. ## New commands | Command | Permission | What it does | |---|---|---| | `/claimglow` (`/claim glow`) | `griefprevention.glow` | Toggles glowing claim borders for this player | | `/gpglow` | `griefprevention.debug` | Toggles the global visualization glow setting | Both permissions default to `true` and `op` respectively, as on Paper. `/claimglow` only does anything while `VisualizationGlow` is on in `config.yml`. ## Cushion protection Cushions (26.3+) are entities, not blocks, so nothing protected them: any player could place or break one inside a claim, and a fishing rod could pull one out. They are now treated like armor stands and item frames: - **Melee and arrows.** Stopped before the hit lands, as with other build-protected entities. - **Snowballs and eggs.** These call `Entity.hurt()` directly and bypass the melee hook, so a separate mixin on the cushion's own damage handling catches them. - **Fishing rods.** Reeling a claimed cushion in takes container trust. - **Sitting.** Right-clicking a cushion to sit on it is allowed for everyone, matching `Claims.PreventCushionMount` (default false) on Paper. Cushions only exist on 26.3, so older releases see no change. ## Glow toggle - `/claimglow [on|off]` flips the player's own glow setting, stored in their `PlayerData/<uuid>` record alongside the accrued and bonus claim blocks. It persists across restarts. - `/gpglow [on|off]` flips the global `VisualizationGlow` config key. It is always available to admins. - The Fabric visualization now checks both the global setting and the player's, so a player who turned glow off for themselves stops seeing glowing outlines even while the server-wide setting stays on. Toggling either setting refreshes any visualization the player currently has drawn. ## Upgrade notes - Player data files gain a fifth line (`glowEnabled`, defaulting to `true`) the first time they are rewritten. Old four-line records keep working and default to glow on, as on Paper. - `VisualizationGlow` in `config.yml` is unchanged and still defaults to `false`. ## Not on Fabric yet The roadmap lists the protections still to come. Shaped claims, merging claims, `/siege`, `/extendclaim`, restore nature, buying or selling claim blocks and charging fees remain Paper-only.

# GriefPrevention3D v18.4.14 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## Fixes - **Claimed cushions can no longer be broken by untrusted players** ([#13](https://github.com/castledking/GriefPrevention3D/issues/13)). A cushion is an entity, not a block, so the block protection that covers everything else never applied to it. On top of that, it is a non-living entity: a hit on one raises no damage event at all, so the creature protection that covers armor stands and item frames never saw it either. All of these now need build trust in the cushion's claim: - **Paper / Purpur / Folia.** Melee, arrows, snowballs, eggs and fire all go through the cushion's break event now. Reeling one in with a fishing rod takes container trust, as with armor stands. - **Fabric.** Melee and arrows are stopped before the hit lands, and a new mixin on the cushion's own damage handling stops snowballs and eggs, which bypass the melee hook. Sitting on a cushion in a claim you can't build in is still allowed, matching `Claims.PreventCushionMount` (default false) on Paper. Reeling one in takes container trust. - **Both.** `EntityDamageHandler` no longer carries a dead `CUSHION` entry that could never fire. Cushions only exist on Minecraft 26.3 and later, so older servers are unaffected. ## New features - **Per-player glow toggle for claim visualizations.** `/claimglow` (or `/claim glow`) lets each player turn the glowing outline on or off for themselves, independently of the server-wide `VisualizationGlow` setting. The setting persists across restarts in the player data file. `/gpglow` lets an administrator flip the global setting at runtime; it is always available, while `/claimglow` only works while the global setting is on. - Paper: `/claimglow [on|off]` (`griefprevention.glow`), `/gpglow [on|off]` (`griefprevention.debug`). - Fabric: the same two commands, registered through the alias system. - Toggling either setting refreshes any visualization the player currently has drawn, so the change shows up immediately. ## Upgrade notes Nothing to migrate. The player data file gains a fifth line (`glowEnabled`, defaulting to `true`) the first time a player's data is rewritten; old four-line records keep working and default to glow on. The `VisualizationGlow` config key is unchanged. Both versions still ship in one `GriefPrevention3D.jar`: 1.8 through the latest release on Spigot, Paper, Purpur and Folia, and 1.21.2 through 1.21.11 and 26.1 through 26.3 on Fabric.

# GriefPrevention3D v18.4.13 — Fabric (experimental beta) **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki **Roadmap:** [platforms/fabric-common/ROADMAP.md](https://github.com/castledking/GriefPrevention3D/blob/master/platforms/fabric-common/ROADMAP.md) > **Still a beta, dedicated-server-only build.** Back up `GriefPreventionData` before updating. Requires Fabric > API; LuckPerms is optional but recommended. ## Overview Three more Paper commands come to Fabric. `/scrollresize` resizes a claim with the mouse wheel, `/trapped` gets a player out of a claim they can't build in, and `/claim alerts` warns owners when a piston or fluid is stopped at their claim's border. Six protections come with them: ender pearls and chorus fruit, lightning fires, fishing rods, sand cannons, sword sweeps and Minecraft 26.2's sulfur cubes. The same `GriefPrevention3D.jar` still runs on Fabric 1.21.2 through 1.21.11 and 26.1 through 26.3, and as a Spigot/Paper plugin. ## New commands | Command | Permission | What it does | |---|---|---| | `/scrollresize` (`/claim scrollresize`, `/sr`, `/src`) | `griefprevention.scrollresize` | Resizes a claim or subdivision with the mouse wheel | | `/trapped` (`/claim trapped`) | `griefprevention.trapped` | Moves you out of a claim you can't build in | | `/claim alerts [on\|off]` | `griefprevention.claimalerts` | Border alerts for the claim you're standing in | | `/claimtogglealerts [on\|off]` | `griefprevention.toggleclaimalerts` | Border alerts for all your claims | All four permissions default to `true`, as on Paper. ### /scrollresize - Hold the golden shovel and stand in a claim or subdivision, or select one of its corners with the shovel first. Then run `/scrollresize`. Look at a side of the claim and scroll up to push that side away from you, or down to pull it toward you. - While you scroll, the new outline is drawn along with the claims around it. The claim's size and the claim blocks you'd have left show above the hotbar. If the new outline overlaps another claim or costs more blocks than you have, you're told right away. - Right-click to apply. The resize goes through the same checks as resizing with the shovel: minimum size, overlaps, claim blocks, and subdivisions fitting inside their parent. - If you selected a corner first, only the two sides that meet at that corner move. - Any of these cancels: left-clicking a block or entity, dropping (Q), swapping hands (F), pressing a number key, putting the shovel away, dying, changing worlds, or a minute without scrolling. Left-clicking the air doesn't cancel, because 26.3 no longer tells the server about it. - Shaped claims can't be made on Fabric yet, so they can't be scroll-resized either. ### /trapped - Stand still for ten seconds in a claim you can't build in, and you're moved past the claim's west and north corner and up to the surface, as on Paper. If another claim is in the way, you're moved past that one too. The surface you'd land on is checked against claims as well, so a 3D claim above the ground can't catch you. - Moving during the ten seconds cancels the rescue. - Overworld only, since there's no telling where a safe spot is in the nether or the end. Administrative claims only when `Claims.AllowTrappedInAdminClaims` is on. - Paper's chat hint, which points players who say "trapped" or "stuck" at `/trapped`, isn't on Fabric yet. ### Claim alerts - A claim's owner is warned when a piston tries to push a block into or out of the claim, or a fluid tries to flow in or out, and is stopped. The warning gives the location. Repeats are merged, and a burst of them is summed up in one message, as on Paper. - `/claim alerts on|off` sets the claim you're standing in. `/claimtogglealerts on|off` sets all your claims. ## New protections - **Ender pearls and chorus fruit** need access trust to land in a claim (`EnderPearlsRequireAccessTrust`). A refused pearl breaks, and comes back to the thrower when `RefundDeniedEnderPearls` is on. Players in creative never spent it, so they get nothing back. A refused chorus fruit jump is undone, and vanilla tries another spot. - **Lightning** starts no fires in claims. - **Fishing rods** need container trust to reel in a claimed animal, armor stand or sulfur cube. - **Falling blocks** (sand cannons): a falling block that drifted sideways only lands in a claim if the spot it fell from is in that claim too, or if it fell from a claim and lands in one of that claim's unrestricted subdivisions. Otherwise it drops as an item. - **Sword sweeps** get the same protection as the hit that caused them. A sweep used to damage the mobs beside its target directly, past every claim check. Creatures, villagers and armor stands in claims, and players in claims where PvP is off, are now checked like the target. On 1.21.2 to 1.21.4 the sweep's knockback is checked too. - **Sulfur cubes** (26.2+) are protected like other creatures ([#12](https://github.com/castledking/GriefPrevention3D/issues/12)). Hits, burning arrows and fire aspect can't reach a claimed cube, so a TNT cube can't be lit. Using one takes container trust. Hits were already stopped before the cube's own damage handling; the gaps were fishing rods and sweeps, both closed above. ## Config New `config.yml` keys, matching the Paper plugin. They're added to existing files on startup without changing anything you've set, and `/gpreload` rereads them. ```yaml GriefPrevention: Claims: AllowTrappedInAdminClaims: false EnderPearlsRequireAccessTrust: true RefundDeniedEnderPearls: true ``` `Allow3DSubdivisions`, which v18.4.12 read but never wrote into the file, now shows up there too. ## Stricter than Paper - On Paper, anyone standing in a claim can mute its owner's alerts with `/claim alerts`. On Fabric it takes permission to edit the claim. - `/claimtogglealerts` also covers the subdivisions of your claims. Paper leaves subdivisions as they were. ## Upgrade notes - Claims and player data keep the same `GriefPreventionData` format as Paper. There's nothing to migrate. - `EnderPearlsRequireAccessTrust` defaults to `true`, as on Paper. From this release on, players can't pearl or chorus-fruit into claims they have no access trust in. Set it to `false` to allow that again. - Sweeps, fishing rods and falling blocks now respect claims. Sand cannons aimed into claims they didn't start in stop working, and so do fishing rods used on other players' animals. - To keep players off a new command, deny its permission in LuckPerms. ## Not on Fabric yet Shaped claims and shaped subdivisions (`/shapedclaims`, `/shapedsubdivideclaims`), merging claims, `/siege`, `/extendclaim`, restore nature, buying or selling claim blocks, and charging fees. The roadmap lists the protections still to come.

# GriefPrevention3D v18.4.13 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## Fixes - **Sulfur cubes in claims are protected like other creatures** ([#12](https://github.com/castledking/GriefPrevention3D/issues/12)). Minecraft 26.2's sulfur cubes got past claim protection in three ways. All three now need container trust in the cube's claim, which is what hurting any claimed creature already needs: - **Hits.** A cube holding a block takes no damage from a hit. The hit knocks it away instead, and fire aspect lights a TNT cube's fuse. Neither fires a damage event, so creature protection never saw them. On Paper and servers built on it, the hit is now stopped before it lands. That covers knockback, fire aspect and a sword killing an empty cube. Spigot has no event for this, so there a hit cube is still put back where it stood, as before. - **Arrows and other projectiles.** A projectile shot by a player without container trust stops when it hits a claimed cube, so a burning arrow can no longer prime a TNT cube. - **Fishing rods.** Reeling in a claimed cube now takes container trust, as reeling in animals and armor stands already did. The protection follows `Claims.ProtectCreatures`: turn that off and sulfur cubes are no more protected than other creatures. Staff using `/ignoreclaims` get through as usual. - **New claims reach down to everything built under them.** When a claim is created, GriefPrevention looks under it for player-built blocks and storage, and lowers the claim's floor to cover them. If the claim's west or north edge was at a negative coordinate, that search skipped the chunks along that edge. Chests and builds under that part of the claim could end up below the claim's floor, unprotected. Ported from upstream GriefPrevention (#2659). 3D claims are not affected, since they keep the heights they were drawn with. ## Upgrade notes Nothing to migrate and no new options. Sulfur cubes only exist on Minecraft 26.2 and later, so older servers only get the claim depth fix. The experimental Fabric version in the same jar gains `/scrollresize`, `/trapped`, claim alerts and several new protections. They're listed in the Fabric version's changelog on Modrinth. Both versions still ship in one `GriefPrevention3D.jar`: 1.8 through the latest release on Spigot, Paper, Purpur and Folia, and 1.21.2 through 1.21.11 and 26.1 through 26.3 on Fabric.

# GriefPrevention3D v18.4.12 — Fabric (experimental beta) **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki **Roadmap:** [platforms/fabric-common/ROADMAP.md](https://github.com/castledking/GriefPrevention3D/blob/master/platforms/fabric-common/ROADMAP.md) > **Still a beta, dedicated-server-only build.** Back up `GriefPreventionData` before updating. Requires Fabric > API; LuckPerms is optional but recommended. ## Overview Fabric finally has subdivisions. `/subdivideclaims` cuts a claim into pieces, `/3dsubdivideclaims` cuts it into pieces with exact heights, and both can be resized and trusted like on Paper. Everything a claim touches under water or in the air also got better: the claim tool now looks for the corner you aim at instead of whatever block the view happens to reach, so a corner sticking out of the sea is a corner you can click. The same `GriefPrevention3D.jar` still runs on Fabric 1.21.2 through 1.21.11 and 26.1 through 26.3 and as a Spigot/Paper plugin. ## Subdivisions | Command | What it does | |---|---| | `/subdivideclaims` (`/claim mode 2d`) | The shovel draws subdivisions that reach from the claim's floor to the sky, as on Paper | | `/3dsubdivideclaims` (`/claim mode 3d`) | The shovel draws subdivisions whose top and bottom you pick | | `/basicclaims` (`/claim mode basic`) | Back to whole claims | | `/restrictsubclaim` | Stops a subdivision inheriting its parent's trust, or lets it again | - Permissions `griefprevention.subdivideclaims` and `griefprevention.3dsubdivideclaims` both default to `true`, as on Paper. - Take the golden shovel into a claim you manage, right-click where the subdivision starts, right-click again where it ends. A 2D subdivision fills the height of its claim; a 3D one uses the heights you clicked, exactly. - Subdivisions may be any size, including one block, and must fit inside their parent without touching each other. Overlaps are refused with Paper's messages and a conflict zone. - Subdivisions can be resized by clicking their corner and dragged to the opposite corner, and they carry their own trust: `/trust`, `/trustlist` and the rest work on them as on Paper. - Sneaking with the shovel at a corner in subdivision mode subdivides there; without sneaking it still resizes the claim whose corner it is, exactly as on Paper. - Nested subdivisions (a subdivision inside a subdivision) are not offered yet, as on Paper without `AllowNestedSubClaims`. `/restrictsubclaim` is in this release, so trust inheritance is on the player to manage. ## Corner clicks, under water and everywhere else Both the stick and the shovel work from up to 100 blocks away. On a faraway click the tool follows the player's view, and while doing so it now also looks for the corner of a claim they are aiming at: - A 3D claim's corner is a single block, so the corner is the block the click lands on, whatever it is made of. - A claim without heights of its own — a parent claim, a 2D subdivision — has a corner that runs its whole height, so whichever block of that corner the view passes is the one clicked. The corner under water is as good as any other. This is what Paper already does, and it fixes the two ways a far corner used to fail: - Aim at a corner and get nothing: the corner is air, water or a gap, so the click reached nothing at all. - Aim at a corner and get the seabed: the click landed a block or two away, outside the claim, so a **new** claim started instead of the corner being selected for a resize. The corner only takes the click when it is what the player is closest to along their view — within two blocks of it, and within a forgiving 1.2 blocks of the corner itself — so ordinary clicks are untouched. A half-finished claim or subdivision never snaps, keeping its second corner exactly where it was clicked. ## Visualization - Fake blocks can be hit: left-clicking one of the blocks a visualization shows sends back the real block and drops it from the display, as breaking it always did. - 3D claims two blocks thick or thinner no longer draw the extra vertical corner markers. ## Config New `config.yml` key, added to existing files on startup and reread by `/gpreload`, matching the Paper plugin: ```yaml GriefPrevention: Claims: Allow3DSubdivisions: true ``` Turn it off and `/3dsubdivideclaims` answers that 3D subdivisions are disabled here, while `/subdivideclaims` keeps working. ## Upgrade notes - Claims and player data keep the same `GriefPreventionData` format as Paper; nothing to migrate. Subdivisions made on Paper in a claim you copy over are resized, trusted and abandoned as usual here. - `Allow3DSubdivisions` defaults to `true`, so 3D subdivision mode is open from this release on. - Clicks near a corner now pick that corner, at any range, instead of the block behind it. That is what Paper has always done within reach; it is only new because the range is no longer limited to what the player touches. ## Not on Fabric yet Shaped claims and shaped subdivisions (`/shapedclaims`, `/shapedsubdivideclaims`), merging claims, `/trapped`, `/siege`, `/extendclaim`, restore nature, buying or selling claim blocks, `/claim alerts` and charging fees. The roadmap lists the protections still to come.

# GriefPrevention3D v18.4.12 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki Nothing changes for Spigot and Paper servers in this release. It behaves exactly like v18.4.11, so updating is optional. This update is for the experimental Fabric version in the same jar. Fabric finally has subdivisions, including 3D ones, and its claim tool finds the corner you aim at from any distance, so a corner under water is clickable. The Fabric changes are in the Fabric version's changelog on Modrinth. Both versions still ship in one `GriefPrevention3D.jar`: 1.8 through the latest release on Spigot, Paper, Purpur and Folia, and 1.21.2 through 1.21.11 and 26.1 through 26.3 on Fabric.

# GriefPrevention3D v18.4.11 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## New options - **`AutoIgnoreClaims` (default false).** Staff who hold the new `griefprevention.autoignoreclaims` permission start each session with claim protections already off, so they can build wherever they need to without touching every claim first. The grant covers every protection: building, containers, entity damage, PvE and knockback, pets, and the rest. Running `/ignoreclaims` turns protections back on for the rest of that session. It is not saved to disk, so it never outlives the session. The new permission defaults to `op` and is deliberately **not** a child of `griefprevention.adminclaims`, so granting that one does not hand it out. Grant it on its own: ``` griefprevention.autoignoreclaims: default: op ``` - **`RequireIgnoreClaimsInAdminClaims` (default false).** Staff normally walk into administrative claims and build freely. With this on, building and using containers inside an administrative claim additionally requires that the staff member be ignoring claims. Walking through, resizing and managing administrative claims still work as before, so `/adminclaim` and friends do not suddenly start refusing. The refusal reads the same way every other protection refuses: each one gives its own reason for that action, followed by the usual "To override, use /ignoreclaims." pointer. No new messages were needed for it. The two options pair up: turn `RequireIgnoreClaimsInAdminClaims` on and give your builders `griefprevention.autoignoreclaims` alongside `AutoIgnoreClaims`, and staff keep building in admin land while every other claim stays protected. Both options appear in your generated `config.yml` between `AdminsGetSignNotifications` and `VisualizationAntiCheatCompatMode`, in this order: ```yaml GriefPrevention: AdminsGetSignNotifications: true AutoIgnoreClaims: false RequireIgnoreClaimsInAdminClaims: false VisualizationAntiCheatCompatMode: false ``` ## Upgrade notes Nothing to migrate. Both options are off by default, so nothing changes until you turn one on. Staff without `griefprevention.autoignoreclaims` are unaffected by `AutoIgnoreClaims` even when it is on. ## Under the hood - The session grant is a separate field on a player's data from the `/ignoreclaims` toggle, and like that toggle it is never written to storage. Protection checks ask whether a player is ignoring claims rather than reading the toggle directly, so every existing protection honours the session grant without each one needing to know about it. - The two `/ignoreclaims` code paths, the unified command handler and the legacy one, now share a single toggle so they cannot drift apart. - New tests cover the session grant, the permission gate, `/ignoreclaims` turning protections back on, and the administrative claim requirement for building and containers.

# GriefPrevention3D v18.4.11 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## New options - **`AutoIgnoreClaims` (default false).** Staff who hold the new `griefprevention.autoignoreclaims` permission start each session with claim protections already off, so they can build wherever they need to without touching every claim first. The grant covers every protection: building, containers, entity damage, PvE and knockback, pets, and the rest. Running `/ignoreclaims` turns protections back on for the rest of that session. It is not saved to disk, so it never outlives the session. The new permission defaults to `op` and is deliberately **not** a child of `griefprevention.adminclaims`, so granting that one does not hand it out. Grant it on its own: ``` griefprevention.autoignoreclaims: default: op ``` - **`RequireIgnoreClaimsInAdminClaims` (default false).** Staff normally walk into administrative claims and build freely. With this on, building and using containers inside an administrative claim additionally requires that the staff member be ignoring claims. Walking through, resizing and managing administrative claims still work as before, so `/adminclaim` and friends do not suddenly start refusing. The refusal reads the same way every other protection refuses: each one gives its own reason for that action, followed by the usual "To override, use /ignoreclaims." pointer. No new messages were needed for it. The two options pair up: turn `RequireIgnoreClaimsInAdminClaims` on and give your builders `griefprevention.autoignoreclaims` alongside `AutoIgnoreClaims`, and staff keep building in admin land while every other claim stays protected. Both options appear in your generated `config.yml` between `AdminsGetSignNotifications` and `VisualizationAntiCheatCompatMode`, in this order: ```yaml GriefPrevention: AdminsGetSignNotifications: true AutoIgnoreClaims: false RequireIgnoreClaimsInAdminClaims: false VisualizationAntiCheatCompatMode: false ``` ## Upgrade notes Nothing to migrate. Both options are off by default, so nothing changes until you turn one on. Staff without `griefprevention.autoignoreclaims` are unaffected by `AutoIgnoreClaims` even when it is on. ## Under the hood - The session grant is a separate field on a player's data from the `/ignoreclaims` toggle, and like that toggle it is never written to storage. Protection checks ask whether a player is ignoring claims rather than reading the toggle directly, so every existing protection honours the session grant without each one needing to know about it. - The two `/ignoreclaims` code paths, the unified command handler and the legacy one, now share a single toggle so they cannot drift apart. - New tests cover the session grant, the permission gate, `/ignoreclaims` turning protections back on, and the administrative claim requirement for building and containers.

# GriefPrevention3D v18.4.10 — Fabric (experimental beta) **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki **Roadmap:** [platforms/fabric-common/ROADMAP.md](https://github.com/castledking/GriefPrevention3D/blob/master/platforms/fabric-common/ROADMAP.md) > **Now a beta, dedicated-server-only build.** Back up `GriefPreventionData` before updating. Requires Fabric > API; LuckPerms is optional but recommended. ## Overview The same `GriefPrevention3D.jar` now runs on every Fabric release from 1.21.2 to 1.21.11 and on 26.1 through 26.3, fifteen Minecraft versions in all, and still works as a Spigot/Paper plugin. Everything from v18.4.9 works the same on the newly supported versions: claims, the claim tools, trust, the staff commands, `/transferclaim` and the protections. ## Minecraft 1.21.2 to 1.21.10 - 1.21.2 to 1.21.10 use the same Fabric build as 1.21.11, so the jar only grew by about 18 KB and is still around 2 MB. - Every build boots the jar on all fifteen versions with Fabric Loader and checks it against each version's game classes. - These versions need Java 21, as Minecraft does, and the Fabric API build for your Minecraft version. - On 1.21.2 to 1.21.10, claims follow the server's `pvp` setting in `server.properties`. From 1.21.11 on, the per-world `pvp` game rule decides. - Copper golem statues need build trust on the versions that have them (1.21.9 and later). ## Not on Fabric yet Fabric 1.21.1 and older; subdivisions, 3D and shaped claims; `/restrictsubclaim`, `/claim alerts`, `/trapped` and `/siege`; restore nature; and buying or selling claim blocks. The roadmap lists the protections still to come. ## Upgrade notes - Claims and player data use the same `GriefPreventionData` format as Paper on every supported version; nothing to migrate.

# GriefPrevention3D v18.4.10 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## Fixes - **A claim transfer an addon cancels now does nothing, and says nothing.** When an addon cancels the transfer, `/transferclaim`, `/makeadmin` and `/makebasic` leave the claim with its owner and stop quietly. Before, they could still say the claim was transferred or converted and write an admin log entry, though the owner had not changed. - **A transfer an addon redirects is no longer mistaken for a cancelled one.** If an addon hands a claim someone gives away to a different player, the transfer now counts as done. Before, it was treated as cancelled and the fee refunded, though the claim had changed hands. - **Servers running eco and Iris start again.** GriefPrevention3D no longer lists Iris as a soft dependency. Iris soft-depends on eco and eco on GriefPrevention, so the loop stopped the server from starting. Nothing in GriefPrevention3D uses Iris. ## Under the hood - New tests cover cancelled and redirected transfers. - A new test makes sure a copied claim keeps both of its corners and its area. The copy once took its lesser corner from the original's greater corner, which shrank it to a single column of blocks. That was fixed during the 3D work, and the test now keeps it fixed. Nothing changes in game. ## Fabric The experimental Fabric version in the same jar now also runs on Minecraft 1.21.2 through 1.21.10. The details are in the Fabric version's changelog on Modrinth. ## Upgrade notes Nothing to migrate.

# GriefPrevention3D v18.4.9 — Fabric (experimental alpha) **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki **Roadmap:** [platforms/fabric-common/ROADMAP.md](https://github.com/castledking/GriefPrevention3D/blob/master/platforms/fabric-common/ROADMAP.md) > **Still an alpha, dedicated-server-only build.** Back up `GriefPreventionData` before updating. Requires Fabric > API; LuckPerms is optional but recommended. ## Overview The same `GriefPrevention3D.jar` still runs on Fabric 1.21.11 and 26.1 through 26.3, and as a Spigot/Paper plugin. Right-clicking blocks in a claim now follows the Paper plugin's rules and config keys, lecterns included. Staff get Paper's claim management commands, and players can give their claims away with `/transferclaim`. ## Lecterns and other blocks Until now, Fabric asked for container trust for every block with a block entity and access trust for every other block. Fabric now uses the Paper plugin's rules instead: | Blocks | Trust needed | |---|---| | Chests, barrels, furnaces, hoppers, shulker boxes and other inventories, plus cake, cauldrons, anvils, beacons, bells, beehives, jukeboxes, respawn anchors, pumpkins and berries | Container, while `Claims.PreventTheft` is on | | Reading a lectern | Access with `Claims.LecternReadingRequiresAccessTrust: true` (the default); anyone may read when it is false | | Taking a lectern's book, or putting one on | Container, always | | Wooden doors / trapdoors | Access only with `Claims.LockWoodenDoors` / `Claims.LockTrapDoors` (both off by default) | | Fence gates | Access with `Claims.LockFenceGates` (on by default) | | Buttons, levers and beds | Access with `Claims.PreventButtonsSwitches` (on by default) | | Note blocks, repeaters, comparators, daylight detectors, redstone wire, flower pots, candles, dragon eggs and copper golem statues | Build | | Crafting tables, enchanting tables, ender chests, campfires and other workstations | None | Visitors with access trust can read a lectern but can no longer take its book; taking it needs container trust. Hitting a dragon egg to make it teleport needs build trust, too. ## Staff commands | Command | What it does | |---|---| | `/ignoreclaims` (`/ic`, `/aclaim ignore`) | Toggles ignoring claims until you log out (`griefprevention.ignoreclaims`) | | `/deleteclaim` | Deletes the claim you stand in, warning first if it has subdivisions. Admin claims also need `griefprevention.adminclaims`. | | `/aclaim delete <claim\|player <name>\|world <world>\|userworld <world>\|alladmin>` | Deletes one claim, a player's claims, every claim or every player claim in a world, or every admin claim | | `/deleteallclaims <player>` | Deletes all of a player's claims | | `/deletealladminclaims` | Deletes every administrative claim | | `/adminclaimslist` (`/aclaim adminlist`) | Lists where the administrative claims are | | `/makeadmin`, `/makebasic` | Turns the claim you stand in into an admin claim, or an admin claim into a claim you own (`griefprevention.adminclaims.convert`) | As on Paper, staff with `griefprevention.deleteclaims` can resize and abandon other players' claims. In `/ignoreclaims` mode, staff can do whatever their `ignoreclaims` or `deleteclaims` permission covers. Deleting someone else's claim gives all of its claim blocks back to its owner; only abandoning your own claim costs blocks. ## Giving claims away `/transferclaim <player> [confirm]` (also `/giveclaim`, `/claim transfer` and `/aclaim transfer`) works as on Paper: - Staff with `griefprevention.transferclaim.others` give the claim they stand in to any player straight away, or make it an admin claim when no name is given. - Players can give away a claim they own once `Claims.TransferClaim.Enabled` is true (off by default). The recipient needs enough claim blocks and a free claim slot, and the giver confirms with `confirm`. The recipient is told if they're online. - Fabric has no economy plugin to charge with. If `Claims.TransferClaim.Price` is above 0, a player's transfer is refused, as Paper refuses one without Vault, unless they have `griefprevention.transferclaim.free`. ## Explosions `/claimexplosions [on|off]` and `/witherexplosions [on|off]` let anyone with build trust in a claim decide whether explosions or wither explosions may damage it. Both were already saved with the claim and honored on Fabric; now the commands to change them are there too. ## Config New `config.yml` keys, added to existing files on startup and reread by `/gpreload`. Each matches the Paper plugin's key and default: ```yaml GriefPrevention: Claims: PreventTheft: true LockWoodenDoors: false LockTrapDoors: false LockFenceGates: true PreventButtonsSwitches: true LecternReadingRequiresAccessTrust: true TransferClaim: Enabled: false Price: 0.0 ``` ## Permissions The Fabric permission defaults now match the Paper plugin's for these commands, with or without LuckPerms: `griefprevention.transferclaim`, `griefprevention.claimexplosions` and `griefprevention.witherexplosions` are open to everyone. `griefprevention.transferclaim.others`, `ignoreclaims`, `deleteclaims` and `adminclaims.convert` need an operator or `griefprevention.admin.*`. `griefprevention.transferclaim.free` is off for everyone. A build-time check now compares every Fabric default with the Paper plugin's `plugin.yml`. ## Upgrade notes - **Doors and trapdoors open for everyone by default now**, as on Paper. To keep visitors out, set `LockWoodenDoors` and `LockTrapDoors` to true. - Crafting tables, enchanting tables, ender chests and campfires no longer need any trust. Note blocks, repeaters, comparators, daylight detectors, flower pots and candles now need build trust instead of access or container trust. - Claims and player data keep the same `GriefPreventionData` format as Paper; nothing to migrate. ## Not on Fabric yet Subdivisions, 3D and shaped claims, `/restrictsubclaim`, `/claim alerts`, `/trapped`, `/siege`, restore nature, buying or selling claim blocks, and charging fees. The roadmap lists the protections still to come.

# GriefPrevention3D v18.4.9 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki Nothing changes for Spigot and Paper servers in this release. It behaves exactly like v18.4.8, so updating is optional. This update is for the experimental Fabric version in the same jar. The Fabric changes are in the Fabric version's changelog on Modrinth.

# GriefPrevention3D v18.4.8 — Fabric (experimental alpha) **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki Nothing changes on Fabric in this release; it behaves exactly like v18.4.7 on Fabric 1.21.11 and 26.1 through 26.3. This update is for Spigot and Paper servers: players giving claims away with `/transferclaim`, pets respecting claims, and polar bears no longer attacking claim visitors. On Fabric, `/claim transfer` answers that it isn't available on Fabric yet.

# GriefPrevention3D v18.4.8 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## Giving claims to other players `/transferclaim <player>`, or `/claim transfer <player>`, now lets players give away a top-level claim they own, once a server turns it on. They confirm by adding `confirm` and can be charged through Vault, like `/claimpvp`: ```yaml GriefPrevention: Claims: TransferClaim: Enabled: false # let players give away their own claims Price: 0.0 # what giving a claim away costs ``` The recipient needs enough claim blocks and a free claim slot, and is told if they are online. Staff keep the old behavior with `griefprevention.transferclaim.others` (previously `griefprevention.transferclaim`): any claim, at once, for free. New permissions `griefprevention.transferclaim.free` and `griefprevention.claimpvp.free` skip the transfer and PvP toggle prices. The new messages are translated in every bundled language. ## Protection - Tamed pets can no longer attack animals in a claim where their owner couldn't ([GriefPrevention#2642](https://github.com/GriefPrevention/GriefPrevention/issues/2642)). - A polar bear guarding cubs in a claim no longer attacks players who aren't allowed to hit it back. - Leashing boats in claims follows `Claims.PreventTheft`, like leashing animals. ## Fabric Nothing changes for the experimental Fabric version in the same jar; these features are for Spigot and Paper. ## Upgrade notes Drop-in replacement for v18.4.7. Staff who had `griefprevention.transferclaim` set explicitly should be given `griefprevention.transferclaim.others` to keep transferring other players' claims.

# GriefPrevention3D v18.4.7 — Fabric (experimental alpha) **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki **Roadmap:** [platforms/fabric-common/ROADMAP.md](https://github.com/castledking/GriefPrevention3D/blob/master/platforms/fabric-common/ROADMAP.md) > **Still an alpha, dedicated-server-only build.** Back up `GriefPreventionData` before updating. Requires Fabric > API; LuckPerms is optional but recommended. ## Overview The same `GriefPrevention3D.jar` now runs on Fabric 1.21.11 and on 26.1, 26.1.1, 26.1.2, 26.2 and 26.3, and it still works as a Spigot/Paper plugin. The commands are now Paper's, including `/acb` and `/scb`. Staff can create admin claims, and protection covers much more of what the Paper plugin protects. ## Minecraft 26.1 to 26.3 - One jar covers every supported Fabric version: it picks the build for the running Minecraft version at startup and stays around 2 MB. - Every build boots the jar on all six versions with Fabric Loader and checks it against each version's game classes. - 26.x needs Java 25, as Minecraft itself does. Fabric API is still required. ## Commands The commands now match the Paper plugin's. `alias.yml` renames, aliases and usage text work as on Paper, and `/gpreload` rereads `alias.yml`. `[permission]` trust targets and negative amounts need no quoting. | Command | What it does | |---|---| | `/trust <player> [access\|container\|build\|manage]`, `/accesstrust`, `/containertrust`, `/managetrust` | Trusts a player, `public`, or a `[permission]` in the claim you stand in, or in all your claims when you stand outside them | | `/permissiontrust <permission> <type>` | Trusts everyone with a permission node | | `/untrust <player\|all\|public>`, `/trustlist` | Revokes and lists trust | | `/claim`, `/claim create [radius]` | Claims the land around you | | `/claimslist [player]` | Shows claim-block math and claims | | `/abandonclaim`, `/abandontoplevelclaim`, `/abandonallclaims confirm` | Abandons claims you own | | `/claimpvp`, `/claimpvpconfirm` | Toggles PvP in a claim, where `Claims.PvPToggle` allows it | | `/adminclaims`, `/basicclaims` | Switches between admin and basic claims | | `/acb <player\|[permission]> <amount>`, `/acball <amount>` | Adds bonus claim blocks to a player, everyone with a permission, or everyone online | | `/scb <player> <amount>`, `/scball <amount>` | Sets accrued claim blocks | | `/aclaim blocks <bonus\|accrued> <player\|all> <amount>` | Adds to either balance | - Permissions and their defaults match the Paper plugin, with or without LuckPerms. Player commands are open to everyone and staff commands to operators or `griefprevention.admin.*`. Setting `griefprevention.claims` to false still takes the claim commands away. - `/trust` no longer fails with "An unexpected error occurred". If a command does fail, the error is now logged in the server console. - Player names are matched against online players and players who have joined the server, never looked up with Mojang, so offline-mode servers always get the UUID the player actually joins with. - `/createclaim`, `/claimblocks` and `/claimhere` are gone. Use `/claim create`, `/claimslist` and the stick instead. ### Security fixes Update if other players are on your server: - Anyone standing in someone else's claim could delete it with `/abandonclaim`, or trust themselves there with `/trust`. Both now need ownership or manage trust, as on Paper. - `/claimslist` showed every claim on the server to anyone. It now shows your own; seeing another player's needs `griefprevention.claimslistother`. ## Admin claims `/adminclaims` makes the golden shovel and `/claim create` create administrative claims. They are free, count toward nobody's claim limit, and show in Paper's admin colors. Staff with `griefprevention.adminclaims` can build, resize, trust and abandon inside them. `/basicclaims` switches back, and the mode resets when you log out. ## Claim tools - The stick inspects claims up to 100 blocks away. Sneak while using it to see every claim within 150 blocks. - `VisualizationGlow: true` adds glowing claim-border outlines that only you can see. - Borders redraw when a claim they show is resized or abandoned, or when a new claim appears nearby. - Taking out the shovel shows your remaining claim blocks and the claim you stand in. Putting it away cancels a half-finished claim. - Staff with `griefprevention.seeinactivity` see how long ago a claim's owner was last online. Fabric records this in `LastSeen.yml` from this version on, so owners who haven't joined since the update show no time yet. - The tool items, `MinimumWidth`, `MinimumArea` and per-world `Claims.Mode` are read from `config.yml`. ## Protection Newly protected, following the Paper plugin's rules and config keys: - Buckets, boats, lily pads and spawn eggs, checked where the item lands. - Dyes, ink sacs, honeycomb, brushes and end crystals need build trust, and so do axes, hoes and shovels on blocks they would change. - Cake, cauldrons, respawn anchors, berry bushes, pumpkins and anvils need container trust. Editing signs needs build trust. - Item frames and armor stands need build trust to use. Item frames, paintings, armor stands, end crystals and vehicles need build trust to damage, by hand or by projectile, and so do villagers with `Claims.ProtectCreatures` on. Other animals need container trust. Monsters are never protected. - Players in claims are safe from PvP according to `PvP.ProtectPlayersInLandClaims`, and `/claimpvp` lets a claim choose for itself. - Explosions no longer hurt protected mobs and entities in claims. - Water and lava never flow into a claim from outside. - Pistons follow `PistonMovement`. - Fire follows `FireSpreads`, `FireDestroys`, `Claims.FireSpreadsInClaims` and `Claims.FireDamagesInClaims`. - Dispensers and droppers only reach into their own claim. - Farmland trampling follows build trust and `CreaturesTrampleCrops`; endermen follow `EndermenMoveBlocks`. ## Not on Fabric yet Subdivisions, 3D and shaped claims, `/ignoreclaims`, deleting or transferring other players' claims, `/trapped`, `/siege`, restore nature and buying or selling claim blocks. Those commands say they aren't available on Fabric yet. The roadmap lists the protections still to come. ## Upgrade notes - Claims and player data use the same `GriefPreventionData` format as Paper; nothing to migrate. - Scripts or command blocks that used `/createclaim`, `/claimblocks` or `/claimhere` need updating. - Building from source: `build/libs/GriefPrevention3D.jar` is now the universal jar, and the Paper-only jar is `GriefPrevention3D-Bukkit.jar`.

# GriefPrevention3D v18.4.7 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki Nothing changes for Spigot and Paper servers in this release. It behaves exactly like v18.4.6, so updating is optional. This update is for the experimental Fabric version in the same jar, which now runs on Minecraft 26.1 through 26.3 as well as 1.21.11. The Fabric changes are in the Fabric version's changelog on Modrinth.

# GriefPrevention3D v18.4.6 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## Overview `%gp3d_trust_level%` and `%gp3d_is_trusted%` now update live in TAB and other plugins that refresh placeholders in the background. Before, a scoreboard kept showing the trust level from when the player walked into the claim. Toggling `/ignoreclaims` or being trusted and untrusted while standing still changed nothing until they walked out and back in. `/trustlist` on a subdivision also stops hiding players whose inherited trust is only partly blocked by a deny entry. ## Trust placeholders ### Why it happened To work out a player's trust level, the expansion called `Claim.checkPermission`, which fires `ClaimPermissionCheckEvent`. Paper only allows that event on the main server thread. TAB and similar plugins refresh placeholders on their own thread, so every background refresh threw an error and the plugin kept the last value it had read successfully. That value usually came from when the board was first built. `/papi parse` runs on the main thread, so it always showed the right answer, which made the problem look like a scoreboard configuration mistake. ### The fix `Claim` gains `hasDefaultPermission(Player, ClaimPermission)`. It runs the same default trust rules as `checkPermission` without firing the event: - claim owner - `/ignoreclaims` with the bypass permission - admin claims and admin subdivisions - explicit trust, including permission-node trust - public trust - subdivision inheritance and deny entries The placeholders use it, so they are safe to read from any thread. Real permission checks in the game still fire the event exactly as before. Because the event is no longer fired for placeholders, plugins that listen to it (GPFlags, for example) no longer change what the placeholder displays. They still control the actual permission check. ## /trustlist and partly denied inheritance A subdivision inherits its parent claim's trust unless a deny entry blocks it. A deny for one level, such as `#build`, only blocks that level. A player who is a builder on the parent and denied `#build` in the subdivision still has container trust there, and `%gp3d_trust_level%` correctly reports `Container`. `/trustlist` grouped inherited entries by their level on the parent and dropped anyone denied that level. So that player vanished from the list completely, and it looked as though they had no trust in the subdivision at all. Denied inherited entries now move down to the highest level they still hold: | Parent trust | Denied in subdivision | Listed as | |---|---|---| | Builder | `#build` | Container | | Builder | `#build` and `#container` | Access | | Container | `#container` | Access | An entry leaves the list only when every level it could inherit is denied. ## Upgrade notes No configuration or storage changes. Drop-in replacement for v18.4.5.

# GriefPrevention3D v18.4.6 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## Overview `%gp3d_trust_level%` and `%gp3d_is_trusted%` now update live in TAB and other plugins that refresh placeholders in the background. Before, a scoreboard kept showing the trust level from when the player walked into the claim. Toggling `/ignoreclaims` or being trusted and untrusted while standing still changed nothing until they walked out and back in. `/trustlist` on a subdivision also stops hiding players whose inherited trust is only partly blocked by a deny entry. ## Trust placeholders ### Why it happened To work out a player's trust level, the expansion called `Claim.checkPermission`, which fires `ClaimPermissionCheckEvent`. Paper only allows that event on the main server thread. TAB and similar plugins refresh placeholders on their own thread, so every background refresh threw an error and the plugin kept the last value it had read successfully. That value usually came from when the board was first built. `/papi parse` runs on the main thread, so it always showed the right answer, which made the problem look like a scoreboard configuration mistake. ### The fix `Claim` gains `hasDefaultPermission(Player, ClaimPermission)`. It runs the same default trust rules as `checkPermission` without firing the event: - claim owner - `/ignoreclaims` with the bypass permission - admin claims and admin subdivisions - explicit trust, including permission-node trust - public trust - subdivision inheritance and deny entries The placeholders use it, so they are safe to read from any thread. Real permission checks in the game still fire the event exactly as before. Because the event is no longer fired for placeholders, plugins that listen to it (GPFlags, for example) no longer change what the placeholder displays. They still control the actual permission check. ## /trustlist and partly denied inheritance A subdivision inherits its parent claim's trust unless a deny entry blocks it. A deny for one level, such as `#build`, only blocks that level. A player who is a builder on the parent and denied `#build` in the subdivision still has container trust there, and `%gp3d_trust_level%` correctly reports `Container`. `/trustlist` grouped inherited entries by their level on the parent and dropped anyone denied that level. So that player vanished from the list completely, and it looked as though they had no trust in the subdivision at all. Denied inherited entries now move down to the highest level they still hold: | Parent trust | Denied in subdivision | Listed as | |---|---|---| | Builder | `#build` | Container | | Builder | `#build` and `#container` | Access | | Container | `#container` | Access | An entry leaves the list only when every level it could inherit is denied. ## Upgrade notes No configuration or storage changes. Drop-in replacement for v18.4.5.

# GriefPrevention3D v18.4.5 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## Overview With `VisualizationGlow: true`, players on clients older than 1.19.4 saw claim borders as blocks nudged out of alignment, with an armor stand flickering into view as each one spawned. Those players now get the classic fake block borders instead, while everyone else keeps the glowing ones. ## Why it happened Glowing visualization draws each border block as a **block display entity**, added in Minecraft 1.19.4. A server running ViaVersion accepts clients older than itself, so the server supporting display entities says nothing about what a given player can render. ViaBackwards translates a display into an armor stand wearing the block, which sits slightly off-centre — the nudged border, and the armor stand visible for the instant before it is dressed. The visualization provider only checked the server's own version, so every player got the glowing treatment whether or not their client could draw it. ## The fix The provider now considers the viewer as well as the server. A client known to be older than 1.19.4 is shown the fake block visualization, which every version renders correctly. Client versions are read from ViaVersion's API by reflection, so GriefPrevention3D gains no dependency and nothing changes on servers that do not run it: - **No ViaVersion installed:** every client speaks the server's protocol, so nothing is gated. This is what already happened. - **ViaVersion installed:** each viewer is checked as their border is drawn. Modern clients keep glowing borders; older ones get fake blocks. - **A player ViaVersion cannot identify:** treated as speaking the server's protocol, the same as above. Border displays were already spawned per-viewer, so an old client never saw another player's glowing borders either. ## Also fixed `BoundaryVisualization` decided whether a failed visualization belonged to GriefPrevention or to another plugin by comparing providers by identity against its own singleton. Building a provider per viewer would have made every internal failure report as coming from an "external visualization provider", so the check now tests the provider's type, and the error fallback path builds a viewer-aware provider as well. ## Upgrade notes No configuration or storage changes. `VisualizationGlow` keeps its meaning: enable it and every client that can render glowing borders gets them. Drop-in replacement for v18.4.4.

# GriefPrevention3D v18.4.5 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## Overview With `VisualizationGlow: true`, players on clients older than 1.19.4 saw claim borders as blocks nudged out of alignment, with an armor stand flickering into view as each one spawned. Those players now get the classic fake block borders instead, while everyone else keeps the glowing ones. ## Why it happened Glowing visualization draws each border block as a **block display entity**, added in Minecraft 1.19.4. A server running ViaVersion accepts clients older than itself, so the server supporting display entities says nothing about what a given player can render. ViaBackwards translates a display into an armor stand wearing the block, which sits slightly off-centre — the nudged border, and the armor stand visible for the instant before it is dressed. The visualization provider only checked the server's own version, so every player got the glowing treatment whether or not their client could draw it. ## The fix The provider now considers the viewer as well as the server. A client known to be older than 1.19.4 is shown the fake block visualization, which every version renders correctly. Client versions are read from ViaVersion's API by reflection, so GriefPrevention3D gains no dependency and nothing changes on servers that do not run it: - **No ViaVersion installed:** every client speaks the server's protocol, so nothing is gated. This is what already happened. - **ViaVersion installed:** each viewer is checked as their border is drawn. Modern clients keep glowing borders; older ones get fake blocks. - **A player ViaVersion cannot identify:** treated as speaking the server's protocol, the same as above. Border displays were already spawned per-viewer, so an old client never saw another player's glowing borders either. ## Also fixed `BoundaryVisualization` decided whether a failed visualization belonged to GriefPrevention or to another plugin by comparing providers by identity against its own singleton. Building a provider per viewer would have made every internal failure report as coming from an "external visualization provider", so the check now tests the provider's type, and the error fallback path builds a viewer-aware provider as well. ## Upgrade notes No configuration or storage changes. `VisualizationGlow` keeps its meaning: enable it and every client that can render glowing borders gets them. Drop-in replacement for v18.4.4.

# GriefPrevention3D v18.4.4 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## Overview Message text can now contain [PlaceholderAPI](https://placeholderapi.com) placeholders. Drop `%player_name%`, `%vault_eco_balance_fixed%` or anything else a server-side placeholder provides into `messages.yml` — or into any of the bundled `Lang/messages_*.yml` files — and the placeholder is resolved for the player who actually receives the message, in their own language and with their own values. ## How it works Previously a placeholder written into a message file appeared literally in chat. Placeholders are now resolved as the message is handed to a player: - **`DataStore.getMessage(player, ...)`** — the single funnel that resolves a message against a player's locale. With per-player locales enabled this is exactly where `messages_en.yml` is swapped for the client's language, so a German player gets the German template *with their own placeholder values* in one step. - **The raw message send paths** — denial messages built before a player is known (claim guards hand back a message supplier that only resolves at send time), scroll resize status, action bar and delayed/respawn messages. No localized output that reaches a player is left with literal `%...%` brackets. Placeholders are never expanded for the console or for messages built without a player, because there is nobody to resolve them for — a server-name placeholder in a console log line still makes sense, but nothing player-specific can. ## Soft dependency, no surprises PlaceholderAPI has always been an optional soft-depend. That stays true: - PlaceholderAPI absent or disabled → every message is byte-for-byte what it was before; the `%...%` text is left alone. - PlaceholderAPI present → expansion is wrapped so a placeholder that errors never breaks a message send. - No library is bundled. The plugin still boots fine on a server that has never heard of PlaceholderAPI. The bundled `%gp3d_*` expansion from v18.x (trust level, subdivision status) is untouched and combines naturally with the new support — e.g. a message can embed `%gp3d_trust_level%` next to `%player_name%`. ## Documented in every language The header comment of every message file now advertises the feature, translated into each of the fifteen locales — English, Pirate Speak, Czech, German, Spanish, French, Japanese, Malay, Polish, Portuguese (Brazil), Russian, Turkish, Ukrainian and Chinese (Simplified). Successful examples (`%vault_eco_balance_fixed%`, `%player_name%`) are spelled out so the format is copy-pastable. ## Upgrade notes No configuration or storage changes. Install [PlaceholderAPI](https://placeholderapi.com) on the server (it already sits in the plugin's soft-depend list), restart, and refresh any existing `messages.yml` / `messages_*.yml` from the jar — or just put placeholders into the files you already have. Two things to keep in mind: - Placeholders resolve when a message reaches a player. Anything rendered without a player — such as the welcome book, which is built from locale strings at startup — shows the literal placeholder text unless the book is customised. - A placeholder only generates output while the player and its backing plugin (e.g. Vault) are online. Messages sent to a player who just logged out keep the placeholder text rather than crash. Drop-in replacement for v18.4.3.

# GriefPrevention3D v18.4.4 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## Overview Message text can now contain [PlaceholderAPI](https://placeholderapi.com) placeholders. Drop `%player_name%`, `%vault_eco_balance_fixed%` or anything else a server-side placeholder provides into `messages.yml` — or into any of the bundled `Lang/messages_*.yml` files — and the placeholder is resolved for the player who actually receives the message, in their own language and with their own values. ## How it works Previously a placeholder written into a message file appeared literally in chat. Placeholders are now resolved as the message is handed to a player: - **`DataStore.getMessage(player, ...)`** — the single funnel that resolves a message against a player's locale. With per-player locales enabled this is exactly where `messages_en.yml` is swapped for the client's language, so a German player gets the German template *with their own placeholder values* in one step. - **The raw message send paths** — denial messages built before a player is known (claim guards hand back a message supplier that only resolves at send time), scroll resize status, action bar and delayed/respawn messages. No localized output that reaches a player is left with literal `%...%` brackets. Placeholders are never expanded for the console or for messages built without a player, because there is nobody to resolve them for — a server-name placeholder in a console log line still makes sense, but nothing player-specific can. ## Soft dependency, no surprises PlaceholderAPI has always been an optional soft-depend. That stays true: - PlaceholderAPI absent or disabled → every message is byte-for-byte what it was before; the `%...%` text is left alone. - PlaceholderAPI present → expansion is wrapped so a placeholder that errors never breaks a message send. - No library is bundled. The plugin still boots fine on a server that has never heard of PlaceholderAPI. The bundled `%gp3d_*` expansion from v18.x (trust level, subdivision status) is untouched and combines naturally with the new support — e.g. a message can embed `%gp3d_trust_level%` next to `%player_name%`. ## Documented in every language The header comment of every message file now advertises the feature, translated into each of the fifteen locales — English, Pirate Speak, Czech, German, Spanish, French, Japanese, Malay, Polish, Portuguese (Brazil), Russian, Turkish, Ukrainian and Chinese (Simplified). Successful examples (`%vault_eco_balance_fixed%`, `%player_name%`) are spelled out so the format is copy-pastable. ## Upgrade notes No configuration or storage changes. Install [PlaceholderAPI](https://placeholderapi.com) on the server (it already sits in the plugin's soft-depend list), restart, and refresh any existing `messages.yml` / `messages_*.yml` from the jar — or just put placeholders into the files you already have. Two things to keep in mind: - Placeholders resolve when a message reaches a player. Anything rendered without a player — such as the welcome book, which is built from locale strings at startup — shows the literal placeholder text unless the book is customised. - A placeholder only generates output while the player and its backing plugin (e.g. Vault) are online. Messages sent to a player who just logged out keep the placeholder text rather than crash. Drop-in replacement for v18.4.3.

# GriefPrevention3D v18.4.3 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## Overview - **Protection fix:** container trust was enough to break a claim's minecarts and boats. It now takes build trust. - **Locale fix:** the bundled Czech translation was registered nowhere, so `cs_CZ` could not be selected at all. ## Breaking a claimed vehicle now needs build trust Vehicle damage was checked against container trust — the same level that opening a chest minecart takes. Any claim that grants container trust broadly, such as a public shop or a warp handing out trial loot, therefore let visitors break its minecarts and boats and walk off with the drops. Breaking a vehicle destroys it, so it is now checked against **build** trust. Nothing else about vehicles changed: - Riding a boat still takes **access** trust. - Opening a chest or hopper minecart still takes **container** trust. - Non-player damage — creepers, withers, TNT — is still blocked outright inside claims. The only players who lose anything are those who were never trusted to build in the first place. This is not a Minecraft 26.2 regression, despite when it started being reported. Minecraft 26.3 still routes vehicle damage through `VehicleDamageEvent` before `VehicleDestroyEvent`, exactly as earlier versions did, so the events GriefPrevention listens for never stopped arriving — the trust level being asked for was simply the wrong one. ## Czech locale was never registered Czech translations shipped in the jar, but the locale was never registered. `messages_cs_CZ.yml` was only known to nothing — neither the list of bundled locale files nor the list of supported locale codes — so it was never extracted to the `Lang/` folder and could not be selected by anything. `Locale: cs_CZ` in `config.yml` fell back to English, and a Czech client was silently ignored on servers running per-player locales. ## Two missing registrations The locale system keeps two lists, and `cs_CZ` was in neither: - **`BUNDLED_LOCALE_FILES`** — the files unpacked from the jar into `Lang/` on first start. An unlisted file stays bundled, unreachable no matter what the configuration asks for. - **`SUPPORTED_LOCALE_CODES`** — the codes accepted by `Locale:` in `config.yml` and matched against a client's language for the per-player locale feature. `messages_cs_CZ.yml` is now registered in both. Server admins can set `Locale: cs_CZ`, and Czech clients get their language automatically when `PerPlayerLocale` is left enabled, falling back to English where a message has no Czech translation yet. ## README: the language situation is now documented The README previously claimed only Spanish and Portuguese clients were served their own language. A new **Supported Languages** section lists all fourteen bundled locales — English, Czech, German, Spanish, French, Japanese, Malay, Polish, Portuguese (Brazil), Russian, Turkish, Ukrainian, Chinese (Simplified) and Pirate Speak — and clarifies how the per-player locale feature actually behaves. The section links to the [Locale guide](https://github.com/castledking/GriefPrevention3D/wiki/Locale) for customising or adding languages. The same pass tidied the README's feature lists: `/scrollresize` is now covered under Key Features, and the v18.4.2 rate limiting under Subtle Changes. Documentation only; no plugin behaviour changed. ## Also merged: the upstream raid-location fix The raid trigger check upstream shipped this cycle now looks up the claim at the raid's location rather than the player's. GP3D has done the same since the handler was pulled into its own class — and it additionally falls back to the player's location when no claim is at the raid site — so the merge kept GP3D's version unchanged. ## Upgrade notes Players holding only container trust can no longer break vehicles in a claim. If your server relies on visitors breaking carts — a public minecart station where riders pick their cart back up, for instance — those players need build trust, or the carts need to sit outside the claim. No configuration or storage changes. Run the new jar once and the Czech translation is extracted to `Lang/`; it is then selectable as `Locale: cs_CZ` or served to Czech clients automatically. Drop-in replacement for v18.4.2.

# GriefPrevention3D v18.4.3 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## Overview - **Protection fix:** container trust was enough to break a claim's minecarts and boats. It now takes build trust. - **Locale fix:** the bundled Czech translation was registered nowhere, so `cs_CZ` could not be selected at all. ## Breaking a claimed vehicle now needs build trust Vehicle damage was checked against container trust — the same level that opening a chest minecart takes. Any claim that grants container trust broadly, such as a public shop or a warp handing out trial loot, therefore let visitors break its minecarts and boats and walk off with the drops. Breaking a vehicle destroys it, so it is now checked against **build** trust. Nothing else about vehicles changed: - Riding a boat still takes **access** trust. - Opening a chest or hopper minecart still takes **container** trust. - Non-player damage — creepers, withers, TNT — is still blocked outright inside claims. The only players who lose anything are those who were never trusted to build in the first place. This is not a Minecraft 26.2 regression, despite when it started being reported. Minecraft 26.3 still routes vehicle damage through `VehicleDamageEvent` before `VehicleDestroyEvent`, exactly as earlier versions did, so the events GriefPrevention listens for never stopped arriving — the trust level being asked for was simply the wrong one. ## Czech locale was never registered Czech translations shipped in the jar, but the locale was never registered. `messages_cs_CZ.yml` was only known to nothing — neither the list of bundled locale files nor the list of supported locale codes — so it was never extracted to the `Lang/` folder and could not be selected by anything. `Locale: cs_CZ` in `config.yml` fell back to English, and a Czech client was silently ignored on servers running per-player locales. ## Two missing registrations The locale system keeps two lists, and `cs_CZ` was in neither: - **`BUNDLED_LOCALE_FILES`** — the files unpacked from the jar into `Lang/` on first start. An unlisted file stays bundled, unreachable no matter what the configuration asks for. - **`SUPPORTED_LOCALE_CODES`** — the codes accepted by `Locale:` in `config.yml` and matched against a client's language for the per-player locale feature. `messages_cs_CZ.yml` is now registered in both. Server admins can set `Locale: cs_CZ`, and Czech clients get their language automatically when `PerPlayerLocale` is left enabled, falling back to English where a message has no Czech translation yet. ## README: the language situation is now documented The README previously claimed only Spanish and Portuguese clients were served their own language. A new **Supported Languages** section lists all fourteen bundled locales — English, Czech, German, Spanish, French, Japanese, Malay, Polish, Portuguese (Brazil), Russian, Turkish, Ukrainian, Chinese (Simplified) and Pirate Speak — and clarifies how the per-player locale feature actually behaves. The section links to the [Locale guide](https://github.com/castledking/GriefPrevention3D/wiki/Locale) for customising or adding languages. The same pass tidied the README's feature lists: `/scrollresize` is now covered under Key Features, and the v18.4.2 rate limiting under Subtle Changes. Documentation only; no plugin behaviour changed. ## Also merged: the upstream raid-location fix The raid trigger check upstream shipped this cycle now looks up the claim at the raid's location rather than the player's. GP3D has done the same since the handler was pulled into its own class — and it additionally falls back to the player's location when no claim is at the raid site — so the merge kept GP3D's version unchanged. ## Upgrade notes Players holding only container trust can no longer break vehicles in a claim. If your server relies on visitors breaking carts — a public minecart station where riders pick their cart back up, for instance — those players need build trust, or the carts need to sit outside the claim. No configuration or storage changes. Run the new jar once and the Czech translation is extracted to `Lang/`; it is then selectable as `Locale: cs_CZ` or served to Czech clients automatically. Drop-in replacement for v18.4.2.

# GriefPrevention3D v18.4.2 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## Overview Denial messages that arrive once per swing, per arrow or per placed block are now rate limited, and the 10 second cooldown behind them was fixed so that throttling one message no longer silences the rest. ## One cooldown per message GriefPrevention keeps a 10 second cooldown on rate limited messages, but it stored a single timestamp per player. Any throttled denial therefore silenced *every* other error for the remainder of the window — a player stopped at a claim border would not be told why their next, unrelated action failed. Cooldowns are now tracked per player per message. Two further fixes came with it: - Lapsed entries are dropped as they are checked, so denials that carry an owner's name cannot accumulate for the length of a session. - A player's cooldowns are forgotten when they disconnect, rather than being held until the next restart. ## Denials that are now rate limited These all fire from events that repeat without the player doing anything new: - **Projectiles changing blocks** — decorated pots, chorus flowers, TNT and pointed dripstone. A cancelled hit leaves the arrow in flight, so it keeps colliding with the block; this was the worst of the set. - **Damage to claimed entities** — animals, pets, armor stands, item frames, villagers, end crystals and vehicles, each of which messaged once per swing or arrow. - **PvP safe zones and spawn immunity** — the knockback handler sent its own copies of these on every hit, duplicating denials that were already throttled elsewhere. - **Hanging entities, paintings, signs, block and multi-block placement**, the creative active-block limit, and automatic claim creation failing because another claim is too close. - **Cauldrons, end portal frames, ignition, chorus flower hits and nether portals.** - **Splash potions** thrown at claimed animals. - **PvP and siege restrictions** on drops, containers, the claim tool and pets, wilderness buckets, and ender pearls denied at a claim border. ## Repeatable warnings move to the action bar Three warnings fired once per block placed and had no cooldown at all. They are now rate limited in their own colour, and added to the default `ActionBarMessages` list so a row of blocks no longer fills chat: - `NoPistonsOutsideClaims` - `TooDeepToClaim` - `NoEnoughBlocksForChestClaim` ## What is deliberately unchanged Golden shovel feedback keeps a specific message for every click, so each denial still explains exactly what was wrong with that click. Chat and command output are untouched as well — a command that replies with nothing reads as a lagging server. ## Upgrade notes `ActionBarMessages` only takes its defaults when the list is absent or empty. An existing `config.yml` already lists the previous five entries, so add the three above to move them out of chat, or remove the list and let it regenerate. No storage changes. Drop-in replacement for v18.4.1.

# GriefPrevention3D v18.4.2 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## Overview Denial messages that arrive once per swing, per arrow or per placed block are now rate limited, and the 10 second cooldown behind them was fixed so that throttling one message no longer silences the rest. ## One cooldown per message GriefPrevention keeps a 10 second cooldown on rate limited messages, but it stored a single timestamp per player. Any throttled denial therefore silenced *every* other error for the remainder of the window — a player stopped at a claim border would not be told why their next, unrelated action failed. Cooldowns are now tracked per player per message. Two further fixes came with it: - Lapsed entries are dropped as they are checked, so denials that carry an owner's name cannot accumulate for the length of a session. - A player's cooldowns are forgotten when they disconnect, rather than being held until the next restart. ## Denials that are now rate limited These all fire from events that repeat without the player doing anything new: - **Projectiles changing blocks** — decorated pots, chorus flowers, TNT and pointed dripstone. A cancelled hit leaves the arrow in flight, so it keeps colliding with the block; this was the worst of the set. - **Damage to claimed entities** — animals, pets, armor stands, item frames, villagers, end crystals and vehicles, each of which messaged once per swing or arrow. - **PvP safe zones and spawn immunity** — the knockback handler sent its own copies of these on every hit, duplicating denials that were already throttled elsewhere. - **Hanging entities, paintings, signs, block and multi-block placement**, the creative active-block limit, and automatic claim creation failing because another claim is too close. - **Cauldrons, end portal frames, ignition, chorus flower hits and nether portals.** - **Splash potions** thrown at claimed animals. - **PvP and siege restrictions** on drops, containers, the claim tool and pets, wilderness buckets, and ender pearls denied at a claim border. ## Repeatable warnings move to the action bar Three warnings fired once per block placed and had no cooldown at all. They are now rate limited in their own colour, and added to the default `ActionBarMessages` list so a row of blocks no longer fills chat: - `NoPistonsOutsideClaims` - `TooDeepToClaim` - `NoEnoughBlocksForChestClaim` ## What is deliberately unchanged Golden shovel feedback keeps a specific message for every click, so each denial still explains exactly what was wrong with that click. Chat and command output are untouched as well — a command that replies with nothing reads as a lagging server. ## Upgrade notes `ActionBarMessages` only takes its defaults when the list is absent or empty. An existing `config.yml` already lists the previous five entries, so add the three above to move them out of chat, or remove the list and let it regenerate. No storage changes. Drop-in replacement for v18.4.1.

# GriefPrevention3D v18.4.1 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## Overview A dispenser inside a claim could not break that claim's own chorus flowers or decorated pots, so chorus flower farms stopped working once the area was claimed. Armor stands were already exempt; flowers and pots now follow the same rule. ## Chorus flowers and decorated pots Two handlers guard projectiles that break blocks, and they disagreed: - The `EntityChangeBlockEvent` handler already allowed a projectile fired by a dispenser standing in the same claim. - An earlier `ProjectileHitEvent` guard cancelled every hit on a chorus flower or decorated pot that a player did not fire. Since Minecraft 1.20.2 a cancelled hit never reaches the block, so the handler that would have allowed the dispenser never ran. The hit guard now applies the same rule as the change-block handler: a dispenser in the same claim is allowed, as is a mob when `MobProjectilesChangeBlocks` is enabled. A dispenser outside the claim shooting in is still blocked, and players still need trust in the claim. The guard is kept for older servers whose `EntityChangeBlockEvent` does not cover these blocks. This affects every projectile that breaks these blocks in vanilla — arrows, snowballs, eggs, tridents, fireballs and wind charges. ## Armor stands The armor stand check that allows a dispenser in the same claim now uses the same shared helper. The previous code compared claim IDs directly and could fail on a claim whose ID was not yet assigned. Behaviour is otherwise unchanged. ## Upgrade notes No configuration or storage changes. Drop-in replacement for v18.4.0. Reported upstream as [GriefPrevention/GriefPrevention#2278](https://github.com/GriefPrevention/GriefPrevention/issues/2278).

# GriefPrevention3D v18.4.1 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## Overview A dispenser inside a claim could not break that claim's own chorus flowers or decorated pots, so chorus flower farms stopped working once the area was claimed. Armor stands were already exempt; flowers and pots now follow the same rule. ## Chorus flowers and decorated pots Two handlers guard projectiles that break blocks, and they disagreed: - The `EntityChangeBlockEvent` handler already allowed a projectile fired by a dispenser standing in the same claim. - An earlier `ProjectileHitEvent` guard cancelled every hit on a chorus flower or decorated pot that a player did not fire. Since Minecraft 1.20.2 a cancelled hit never reaches the block, so the handler that would have allowed the dispenser never ran. The hit guard now applies the same rule as the change-block handler: a dispenser in the same claim is allowed, as is a mob when `MobProjectilesChangeBlocks` is enabled. A dispenser outside the claim shooting in is still blocked, and players still need trust in the claim. The guard is kept for older servers whose `EntityChangeBlockEvent` does not cover these blocks. This affects every projectile that breaks these blocks in vanilla — arrows, snowballs, eggs, tridents, fireballs and wind charges. ## Armor stands The armor stand check that allows a dispenser in the same claim now uses the same shared helper. The previous code compared claim IDs directly and could fail on a claim whose ID was not yet assigned. Behaviour is otherwise unchanged. ## Upgrade notes No configuration or storage changes. Drop-in replacement for v18.4.0. Reported upstream as [GriefPrevention/GriefPrevention#2278](https://github.com/GriefPrevention/GriefPrevention/issues/2278).

# GriefPrevention3D v18.4.0 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## Overview Claim protection for the two pieces of furniture added in Minecraft 26.3: - **Cushions** could be placed in anyone's claim by untrusted players. Placing and breaking one now needs build trust, and sitting on one can optionally need access trust. - **Straw beds** are not part of the vanilla `beds` tag, so the existing bed rule never covered them. Using one now needs access trust by default. Everything else is unchanged; servers on older Minecraft versions are unaffected. ## Cushions Cushions are entities placed from one of sixteen dyed items, so the usual block protections never applied to them. - **Placing** a cushion in a claim requires **build trust**, like placing an armor stand. - **Breaking** a cushion requires **build trust**, like item frames and armor stands. - **Sitting** on a cushion is allowed by default, so a claim's furniture stays usable by visitors. Servers that want seats reserved for trusted players can turn on the new option below. ```yaml GriefPrevention: Claims: PreventCushionMount: false ``` - `false` (default): anyone may sit on a cushion. - `true`: sitting on a cushion inside a claim requires **access trust**. In creative worlds, cushions also count toward the per-claim entity limit, like armor stands and item frames. ## Straw beds Straw beds set a spawn point like a bed, but they break when they are slept in. They are deliberately not in the vanilla `beds` tag, so GriefPrevention's bed rule did not apply to them. ```yaml GriefPrevention: Claims: ProtectStrawBeds: true ``` - `true` (default): using a straw bed in a claim requires **access trust**, the same trust level beds use. This keeps a claim's straw beds from being consumed by passers-by while remaining available to anyone the owner trusts. - `false`: straw beds may be used by anyone, and are destroyed on use as in vanilla. Placing and breaking a straw bed already requires build trust, because it is an ordinary block. ## Upgrade notes Both options are added to `config.yml` the next time the server starts. No storage changes. Drop-in replacement for v18.3.14.

# GriefPrevention3D v18.4.0 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## Overview Claim protection for the two pieces of furniture added in Minecraft 26.3: - **Cushions** could be placed in anyone's claim by untrusted players. Placing and breaking one now needs build trust, and sitting on one can optionally need access trust. - **Straw beds** are not part of the vanilla `beds` tag, so the existing bed rule never covered them. Using one now needs access trust by default. Everything else is unchanged; servers on older Minecraft versions are unaffected. ## Cushions Cushions are entities placed from one of sixteen dyed items, so the usual block protections never applied to them. - **Placing** a cushion in a claim requires **build trust**, like placing an armor stand. - **Breaking** a cushion requires **build trust**, like item frames and armor stands. - **Sitting** on a cushion is allowed by default, so a claim's furniture stays usable by visitors. Servers that want seats reserved for trusted players can turn on the new option below. ```yaml GriefPrevention: Claims: PreventCushionMount: false ``` - `false` (default): anyone may sit on a cushion. - `true`: sitting on a cushion inside a claim requires **access trust**. In creative worlds, cushions also count toward the per-claim entity limit, like armor stands and item frames. ## Straw beds Straw beds set a spawn point like a bed, but they break when they are slept in. They are deliberately not in the vanilla `beds` tag, so GriefPrevention's bed rule did not apply to them. ```yaml GriefPrevention: Claims: ProtectStrawBeds: true ``` - `true` (default): using a straw bed in a claim requires **access trust**, the same trust level beds use. This keeps a claim's straw beds from being consumed by passers-by while remaining available to anyone the owner trusts. - `false`: straw beds may be used by anyone, and are destroyed on use as in vanilla. Placing and breaking a straw bed already requires build trust, because it is an ordinary block. ## Upgrade notes Both options are added to `config.yml` the next time the server starts. No storage changes. Drop-in replacement for v18.3.14.

# GriefPrevention3D v18.3.14 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## Overview - **New:** `/scrollresize` — resize claims and subdivisions with the mouse wheel and a live preview. - **Permissions:** every claim and admin command now has its own permission node, so a single command can be negated without removing the rest of `griefprevention.claims` or `griefprevention.adminclaims`. Denials send the plugin's own "no permission" message everywhere. - **Changed:** `/claimpvp` now needs manager trust in the claim instead of edit permission. - **Fix:** `Claims.Allow3DSubdivisions` and `Claims.Allow3DAdminClaims` are now written to `config.yml`. - **Fix:** 3D subdivision outlines that are one block wide or one or two layers tall now draw correctly. - **Fix:** clicking a second spot on a shaped claim's boundary in `/shapedclaims` placed the segment marker next to the previous one instead of where you clicked. ## /scrollresize Hold your claim tool and run `/scrollresize` (or `/claim scrollresize`, aliases `/sr`, `/src`). **Which claim:** the claim or subdivision you're looking at or standing in — including 3D subdivisions too small to stand inside, like a 1x1x1 — or the claim you selected by right-clicking one of its corners. **Which side:** the side your line of sight hits. From outside a claim that's the side facing you (the top when you look down on it); from inside, it's the side you're looking at. Right-clicking a corner first limits the resize to the sides at that corner (two on a 2D claim, plus the top or bottom on a 3D claim). On shaped claims and shaped subdivisions the side is the segment you're standing in front of and facing, the same one `/expandclaim` moves, or one of the two edges at a selected corner. **Scrolling follows your camera:** scrolling up pushes the side away from you and scrolling down pulls it toward you, one block per notch. Looking down at a 1x1x1 subdivision, scroll down raises its top and scroll up brings it back to a single layer. **Preview:** the new outline is drawn through GriefPrevention's normal visualization event, so fake-block and glowing borders — and visualization addons that hook that event — show it. Nearby claims and the parent claim's other subdivisions are shown too. The outline turns red if it would overlap another claim, stick out of its parent, cut into its own subdivisions, or cost more claim blocks than you have; the action bar shows the size and remaining claim blocks. (Servers without an action bar API, such as 1.8.8, get conflicts in chat right away and size updates in chat once you stop scrolling.) **Applying and cancelling:** - **Right-click** applies the resize, through the same checks as the golden shovel. If the preview shows a conflict, the session stays open so you can scroll back. - **Left-click, drop (Q), swap hands (F, 1.9+), a number key, switching off the claim tool, changing worlds, or a minute without scrolling** cancels it and restores the claim's real outline. Subdivisions never cost claim blocks. Shaped segments can be pulled inward into a notch, stopping at the last valid shape. New permission: **`griefprevention.scrollresize`** (default `true`, child of `griefprevention.claims`). ## Per-command permissions Upstream GriefPrevention gated most claim commands behind `griefprevention.claims`, so negating one command meant losing all of them. GP3D now gives each command its own node under a parent bundle: - **Commands check their own node.** `plugin.yml` commands, `/claim` and `/aclaim` subcommands, and the standalone aliases configured in `alias.yml` all check the command's specific permission. For example: `/claim untrust` checks `griefprevention.untrust`, `/claim pvp` checks `griefprevention.claimpvp`, `/claim trust <player> access` checks `griefprevention.accesstrust`, and `/claim abandon all` checks `griefprevention.abandonallclaims`. - **One denial message.** Every denial sends `NoPermissionForCommand` from `messages.yml` — including Bukkit's own `plugin.yml` permission check and dynamically registered aliases, which previously sent generic English text. - **New nodes under `griefprevention.claims`** (default `true`): `griefprevention.trustlist`, `griefprevention.claimalerts` (`/claim alerts`), and `griefprevention.toggleclaimalerts` (`/claimtogglealerts`, which previously used an undeclared node and so only worked for operators). - **New nodes under `griefprevention.adminclaims`** (default `op`): `griefprevention.3dadminclaims`, `griefprevention.adminclaimslist`, and `griefprevention.deletealladminclaims` (which also still requires `griefprevention.deleteclaims`). `/aclaim transfer` checks `griefprevention.transferclaim`, and `/aclaim delete` checks `griefprevention.deleteclaims`, `griefprevention.deleteclaimsinworld`, or `griefprevention.deletealladminclaims` depending on what is being deleted. - **Previously undeclared nodes are now declared** (default `op`): `griefprevention.deleteclaimsinworld`, `griefprevention.deathblow`, and `griefprevention.eavesdrop.immune`. Everyone who has `griefprevention.claims` or `griefprevention.adminclaims` keeps the same access as before; the change only makes negating individual commands possible. ## /claimpvp needs manager trust Toggling PvP in a claim now requires manager trust (owners, players given `/managetrust`, and staff with `griefprevention.adminclaims` on admin claims) instead of edit permission, and the command permission is `griefprevention.claimpvp` instead of `griefprevention.claims`. Players without manager trust see the claim's "you don't have permission to manage permissions here" message. ## 3D config options now generate `Claims.Allow3DSubdivisions` and `Claims.Allow3DAdminClaims` were read but never written back, so they never appeared in `config.yml`. They are now added with their current values (default `true`) the next time the server starts. ## 3D subdivision previews Very small 3D subdivisions put several outline markers on the same block: a one-block-wide ring collapses into a column, a one-layer subdivision drew the same ring twice, and the white wool markers of a two-layer subdivision landed on the other ring's corners. Which marker appeared was random, so these subdivisions looked unchanged while resizing. Each block is now drawn once with corners winning, one-layer subdivisions draw a single ring, and the wool markers only appear when there's a gap between the top and bottom rings. This applies everywhere 3D subdivisions are shown, including the golden shovel and investigation tool. ## Shaped claim segment markers In `/shapedclaims`, the first click on a claim boundary places a segment marker and starts a reshape path from it. A second click elsewhere on the same boundary was read as the next point of that path and snapped to the block next to the first marker. A path that hasn't left the boundary yet is now dropped when you click another spot on the same boundary, so the new marker goes exactly where you clicked. Reshaping outward, cuts, and cross-claim merges work as before. ## Upgrade notes - **alias.yml:** existing files keep their values. If yours sets `subcommands.claim.pvp.permission: griefprevention.claims`, you can change it to `griefprevention.claimpvp`; the command also checks `griefprevention.claimpvp` either way. - New messages are translated into every bundled locale. - No storage changes. Drop-in replacement for v18.3.13.

# GriefPrevention3D v18.3.14 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## Overview - **New:** `/scrollresize` — resize claims and subdivisions with the mouse wheel and a live preview. - **Permissions:** every claim and admin command now has its own permission node, so a single command can be negated without removing the rest of `griefprevention.claims` or `griefprevention.adminclaims`. Denials send the plugin's own "no permission" message everywhere. - **Changed:** `/claimpvp` now needs manager trust in the claim instead of edit permission. - **Fix:** `Claims.Allow3DSubdivisions` and `Claims.Allow3DAdminClaims` are now written to `config.yml`. - **Fix:** 3D subdivision outlines that are one block wide or one or two layers tall now draw correctly. - **Fix:** clicking a second spot on a shaped claim's boundary in `/shapedclaims` placed the segment marker next to the previous one instead of where you clicked. ## /scrollresize Hold your claim tool and run `/scrollresize` (or `/claim scrollresize`, aliases `/sr`, `/src`). **Which claim:** the claim or subdivision you're looking at or standing in — including 3D subdivisions too small to stand inside, like a 1x1x1 — or the claim you selected by right-clicking one of its corners. **Which side:** the side your line of sight hits. From outside a claim that's the side facing you (the top when you look down on it); from inside, it's the side you're looking at. Right-clicking a corner first limits the resize to the sides at that corner (two on a 2D claim, plus the top or bottom on a 3D claim). On shaped claims and shaped subdivisions the side is the segment you're standing in front of and facing, the same one `/expandclaim` moves, or one of the two edges at a selected corner. **Scrolling follows your camera:** scrolling up pushes the side away from you and scrolling down pulls it toward you, one block per notch. Looking down at a 1x1x1 subdivision, scroll down raises its top and scroll up brings it back to a single layer. **Preview:** the new outline is drawn through GriefPrevention's normal visualization event, so fake-block and glowing borders — and visualization addons that hook that event — show it. Nearby claims and the parent claim's other subdivisions are shown too. The outline turns red if it would overlap another claim, stick out of its parent, cut into its own subdivisions, or cost more claim blocks than you have; the action bar shows the size and remaining claim blocks. (Servers without an action bar API, such as 1.8.8, get conflicts in chat right away and size updates in chat once you stop scrolling.) **Applying and cancelling:** - **Right-click** applies the resize, through the same checks as the golden shovel. If the preview shows a conflict, the session stays open so you can scroll back. - **Left-click, drop (Q), swap hands (F, 1.9+), a number key, switching off the claim tool, changing worlds, or a minute without scrolling** cancels it and restores the claim's real outline. Subdivisions never cost claim blocks. Shaped segments can be pulled inward into a notch, stopping at the last valid shape. New permission: **`griefprevention.scrollresize`** (default `true`, child of `griefprevention.claims`). ## Per-command permissions Upstream GriefPrevention gated most claim commands behind `griefprevention.claims`, so negating one command meant losing all of them. GP3D now gives each command its own node under a parent bundle: - **Commands check their own node.** `plugin.yml` commands, `/claim` and `/aclaim` subcommands, and the standalone aliases configured in `alias.yml` all check the command's specific permission. For example: `/claim untrust` checks `griefprevention.untrust`, `/claim pvp` checks `griefprevention.claimpvp`, `/claim trust <player> access` checks `griefprevention.accesstrust`, and `/claim abandon all` checks `griefprevention.abandonallclaims`. - **One denial message.** Every denial sends `NoPermissionForCommand` from `messages.yml` — including Bukkit's own `plugin.yml` permission check and dynamically registered aliases, which previously sent generic English text. - **New nodes under `griefprevention.claims`** (default `true`): `griefprevention.trustlist`, `griefprevention.claimalerts` (`/claim alerts`), and `griefprevention.toggleclaimalerts` (`/claimtogglealerts`, which previously used an undeclared node and so only worked for operators). - **New nodes under `griefprevention.adminclaims`** (default `op`): `griefprevention.3dadminclaims`, `griefprevention.adminclaimslist`, and `griefprevention.deletealladminclaims` (which also still requires `griefprevention.deleteclaims`). `/aclaim transfer` checks `griefprevention.transferclaim`, and `/aclaim delete` checks `griefprevention.deleteclaims`, `griefprevention.deleteclaimsinworld`, or `griefprevention.deletealladminclaims` depending on what is being deleted. - **Previously undeclared nodes are now declared** (default `op`): `griefprevention.deleteclaimsinworld`, `griefprevention.deathblow`, and `griefprevention.eavesdrop.immune`. Everyone who has `griefprevention.claims` or `griefprevention.adminclaims` keeps the same access as before; the change only makes negating individual commands possible. ## /claimpvp needs manager trust Toggling PvP in a claim now requires manager trust (owners, players given `/managetrust`, and staff with `griefprevention.adminclaims` on admin claims) instead of edit permission, and the command permission is `griefprevention.claimpvp` instead of `griefprevention.claims`. Players without manager trust see the claim's "you don't have permission to manage permissions here" message. ## 3D config options now generate `Claims.Allow3DSubdivisions` and `Claims.Allow3DAdminClaims` were read but never written back, so they never appeared in `config.yml`. They are now added with their current values (default `true`) the next time the server starts. ## 3D subdivision previews Very small 3D subdivisions put several outline markers on the same block: a one-block-wide ring collapses into a column, a one-layer subdivision drew the same ring twice, and the white wool markers of a two-layer subdivision landed on the other ring's corners. Which marker appeared was random, so these subdivisions looked unchanged while resizing. Each block is now drawn once with corners winning, one-layer subdivisions draw a single ring, and the wool markers only appear when there's a gap between the top and bottom rings. This applies everywhere 3D subdivisions are shown, including the golden shovel and investigation tool. ## Shaped claim segment markers In `/shapedclaims`, the first click on a claim boundary places a segment marker and starts a reshape path from it. A second click elsewhere on the same boundary was read as the next point of that path and snapped to the block next to the first marker. A path that hasn't left the boundary yet is now dropped when you click another spot on the same boundary, so the new marker goes exactly where you clicked. Reshaping outward, cuts, and cross-claim merges work as before. ## Upgrade notes - **alias.yml:** existing files keep their values. If yours sets `subcommands.claim.pvp.permission: griefprevention.claims`, you can change it to `griefprevention.claimpvp`; the command also checks `griefprevention.claimpvp` either way. - New messages are translated into every bundled locale. - No storage changes. Drop-in replacement for v18.3.13.

# GriefPrevention3D v18.3.13 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## Overview - `/extendclaim` on a 3D subdivision inside a shaped claim resized the **shaped claim** instead of the subdivision. - **Security:** players without edit permission could resize someone else's shaped claim with `/extendclaim`. - Shaped subdivisions no longer hit the "claim too narrow" / "insufficient area" minimums. ## `/extendclaim` extended the wrong claim When no claim was selected with the golden shovel, `/extendclaim` (and `/claim expand`) replaced the claim the player was standing in with its **parent**. Standing inside a 3D subdivision of a shaped claim therefore targeted the shaped claim, which grows whichever boundary segment the player faces. That edge could be far away, so the command looked like it just flashed and refreshed the visualization without extending anything — while quietly growing the parent claim. Fix: - `/extendclaim` now extends the most specific claim you're standing in — including 2D, 3D, and shaped subdivisions — matching upstream GriefPrevention. A claim selected with the golden shovel still takes priority. - Extending a 3D subdivision vertically checked against the parent's raw stored Y values. Shaped claims store only their floor, so a 3D subdivision inside one could never grow upward. The check now uses the parent's real vertical range (the world height limit for 2D parents). - Shaped subdivisions use the shaped segment expansion (the same as shaped claims) instead of the rectangle resize, which would have changed their stored bounds without moving their outline. Behavior note: standing inside a rectangular subdivision, `/extendclaim` now grows that subdivision, not the claim around it. To grow the whole claim, stand outside the subdivision or select the claim's corner with the golden shovel first. ## Security: shaped claims could be resized without permission The shaped-claim branch of `/extendclaim` ran **before** the edit-permission check, so any player holding the claim modification tool could expand (or shrink, with a negative amount) another player's shaped claim just by standing in it. The permission check now runs first for every claim type. ## Shaped subdivisions can be as small as you like Shaped subdivisions carve up land the owner already paid for, so they now skip the claim size minimums (`MinimumWidth` / `MinimumArea` for rectangular outlines, `ShapedMinimumArea` for other outlines) both when created with `/shapedsubdivideclaims` and when reshaped or extended. Top-level claims are unaffected. The smallest shaped subdivision is 2×2: a shaped outline can't be one block wide, because that would need a zero-length edge. Use a regular `/subdivideclaims` subdivision for 1×1 spaces. ## Upgrade notes No configuration or storage changes. Drop-in replacement for v18.3.12.

# GriefPrevention3D v18.3.13 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## Overview - `/extendclaim` on a 3D subdivision inside a shaped claim resized the **shaped claim** instead of the subdivision. - **Security:** players without edit permission could resize someone else's shaped claim with `/extendclaim`. - Shaped subdivisions no longer hit the "claim too narrow" / "insufficient area" minimums. ## `/extendclaim` extended the wrong claim When no claim was selected with the golden shovel, `/extendclaim` (and `/claim expand`) replaced the claim the player was standing in with its **parent**. Standing inside a 3D subdivision of a shaped claim therefore targeted the shaped claim, which grows whichever boundary segment the player faces. That edge could be far away, so the command looked like it just flashed and refreshed the visualization without extending anything — while quietly growing the parent claim. Fix: - `/extendclaim` now extends the most specific claim you're standing in — including 2D, 3D, and shaped subdivisions — matching upstream GriefPrevention. A claim selected with the golden shovel still takes priority. - Extending a 3D subdivision vertically checked against the parent's raw stored Y values. Shaped claims store only their floor, so a 3D subdivision inside one could never grow upward. The check now uses the parent's real vertical range (the world height limit for 2D parents). - Shaped subdivisions use the shaped segment expansion (the same as shaped claims) instead of the rectangle resize, which would have changed their stored bounds without moving their outline. Behavior note: standing inside a rectangular subdivision, `/extendclaim` now grows that subdivision, not the claim around it. To grow the whole claim, stand outside the subdivision or select the claim's corner with the golden shovel first. ## Security: shaped claims could be resized without permission The shaped-claim branch of `/extendclaim` ran **before** the edit-permission check, so any player holding the claim modification tool could expand (or shrink, with a negative amount) another player's shaped claim just by standing in it. The permission check now runs first for every claim type. ## Shaped subdivisions can be as small as you like Shaped subdivisions carve up land the owner already paid for, so they now skip the claim size minimums (`MinimumWidth` / `MinimumArea` for rectangular outlines, `ShapedMinimumArea` for other outlines) both when created with `/shapedsubdivideclaims` and when reshaped or extended. Top-level claims are unaffected. The smallest shaped subdivision is 2×2: a shaped outline can't be one block wide, because that would need a zero-length edge. Use a regular `/subdivideclaims` subdivision for 1×1 spaces. ## Upgrade notes No configuration or storage changes. Drop-in replacement for v18.3.12.

# GriefPrevention3D v18.3.12 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## Overview Fix for the per-claim PvP toggle: claims that players turned PvP **off** before v18.3.10 had PvP enabled again after upgrading, on servers whose global config allows combat in claims. From a player's point of view, "PvP is enabled in all claims". ## Root cause v18.3.10 introduced an explicit-toggle marker (`PvP Toggle Set` / the `pvptoggled` column) so that claims nobody ever toggled fall back to the global `PvP.ProtectPlayersInLandClaims.*` settings instead of being treated as PvP-on by default. Claims saved before that release had `PvP Enabled: false` but no marker. They loaded as never-toggled, so `claimIsPvPSafeZone` ignored their stored "off" and used the global config instead. On servers where `ProtectPlayersInLandClaims.PlayerOwnedClaims` is `false` — typical for servers that let owners opt out of PvP per claim, and the default when siege is enabled in any world — every claim players had disabled became a PvP zone again. Claims toggled after upgrading got the marker and worked, which made the problem easy to miss when testing. ## Fix A claim's stored PvP state can only differ from the default (on) because someone explicitly turned PvP off — through `/claimpvp false confirm`, or a subdivision inheriting a disabled parent. So a stored `PvP Enabled: false` now counts as an explicit toggle when the claim loads, from both flat-file and database storage. - Claims disabled before v18.3.10 are protected again as soon as v18.3.12 starts — no commands or data changes needed. - Claims nobody ever toggled still follow the global `ProtectPlayersInLandClaims` settings. - Flat-file saves only write the `PvP Toggle Set` marker for claims explicitly toggled **on**, since "off" already implies it. Existing claim files and cross-platform (Fabric) claim documents are not rewritten with redundant fields. New regression tests cover legacy disabled claims and subdivisions staying protected while the global config allows combat, and untoggled claims still following the global config. ## Upgrade notes No configuration or storage changes. Drop-in replacement for v18.3.11. Claims explicitly toggled **on** before v18.3.10 are stored identically to the default and can't be told apart; they keep following the global config until `/claimpvp true confirm` is run on them again. If players expect claims that were never toggled to be protected, make sure `GriefPrevention.PvP.ProtectPlayersInLandClaims.PlayerOwnedClaims` is `true` in `config.yml`.

# GriefPrevention3D v18.3.12 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## Overview Fix for the per-claim PvP toggle: claims that players turned PvP **off** before v18.3.10 had PvP enabled again after upgrading, on servers whose global config allows combat in claims. From a player's point of view, "PvP is enabled in all claims". ## Root cause v18.3.10 introduced an explicit-toggle marker (`PvP Toggle Set` / the `pvptoggled` column) so that claims nobody ever toggled fall back to the global `PvP.ProtectPlayersInLandClaims.*` settings instead of being treated as PvP-on by default. Claims saved before that release had `PvP Enabled: false` but no marker. They loaded as never-toggled, so `claimIsPvPSafeZone` ignored their stored "off" and used the global config instead. On servers where `ProtectPlayersInLandClaims.PlayerOwnedClaims` is `false` — typical for servers that let owners opt out of PvP per claim, and the default when siege is enabled in any world — every claim players had disabled became a PvP zone again. Claims toggled after upgrading got the marker and worked, which made the problem easy to miss when testing. ## Fix A claim's stored PvP state can only differ from the default (on) because someone explicitly turned PvP off — through `/claimpvp false confirm`, or a subdivision inheriting a disabled parent. So a stored `PvP Enabled: false` now counts as an explicit toggle when the claim loads, from both flat-file and database storage. - Claims disabled before v18.3.10 are protected again as soon as v18.3.12 starts — no commands or data changes needed. - Claims nobody ever toggled still follow the global `ProtectPlayersInLandClaims` settings. - Flat-file saves only write the `PvP Toggle Set` marker for claims explicitly toggled **on**, since "off" already implies it. Existing claim files and cross-platform (Fabric) claim documents are not rewritten with redundant fields. New regression tests cover legacy disabled claims and subdivisions staying protected while the global config allows combat, and untoggled claims still following the global config. ## Upgrade notes No configuration or storage changes. Drop-in replacement for v18.3.11. Claims explicitly toggled **on** before v18.3.10 are stored identically to the default and can't be told apart; they keep following the global config until `/claimpvp true confirm` is run on them again. If players expect claims that were never toggled to be protected, make sure `GriefPrevention.PvP.ProtectPlayersInLandClaims.PlayerOwnedClaims` is `true` in `config.yml`.

# GriefPrevention3D v18.3.11 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## Overview New permission: **`griefprevention.maxclaims.<amount>`** sets how many claims a player (or a whole rank) may own, so the claim-count limit no longer has to be one number for the entire server. ``` /lp group default permission set griefprevention.maxclaims.3 true /lp group vip permission set griefprevention.maxclaims.10 true ``` ## How it works Until now the only controls were the global `Claims.MaximumNumberOfClaimsPerPlayer` config value and the all-or-nothing `griefprevention.overrideclaimcountlimit` bypass, which only gave two tiers: "limited" and "unlimited". When a player starts a new claim, GP3D now resolves their limit like this: 1. **`griefprevention.overrideclaimcountlimit`** → no limit (unchanged). 2. Otherwise, the **highest** `griefprevention.maxclaims.<amount>` node the player holds is their limit. Because the highest node wins, ranks that inherit from each other just work — a VIP who also inherits `maxclaims.3` from the default group gets 10. 3. Otherwise, the configured `Claims.MaximumNumberOfClaimsPerPlayer` applies (`0` = unlimited). Details: - A permission limit applies even when the config value is `0`, and it can raise **or** lower a player's limit relative to the config. - Negated nodes, wildcards (`griefprevention.maxclaims.*`), and zero/negative amounts are ignored. Use `overrideclaimcountlimit` for unlimited claims. - The limit counts top-level claims the player owns; subdivisions don't count. - It is enforced everywhere a claim can be started: `/claim create`, the golden shovel, and shaped claim mode. The lookup reads the player's effective permissions, so it works with LuckPerms and any other permission plugin, and on every supported Bukkit-family server back to 1.8.8. ## Also in this release - New regression tests covering admin-claim `/claim pvp` toggles (staff can toggle admin claims and their subdivisions; regular players are still denied). - Wiki refresh: shaped subdivisions, shaped claim cuts, administrative subdivisions, PvP/PvE combat trust, and the new claim-count permission are now documented. ## Upgrade notes No configuration or storage changes. Servers that don't grant any `griefprevention.maxclaims.*` nodes behave exactly as before. The experimental Fabric build still uses the config limit and the override permission only. Drop-in replacement for v18.3.10.

# GriefPrevention3D v18.3.11 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## Overview New permission: **`griefprevention.maxclaims.<amount>`** sets how many claims a player (or a whole rank) may own, so the claim-count limit no longer has to be one number for the entire server. ``` /lp group default permission set griefprevention.maxclaims.3 true /lp group vip permission set griefprevention.maxclaims.10 true ``` ## How it works Until now the only controls were the global `Claims.MaximumNumberOfClaimsPerPlayer` config value and the all-or-nothing `griefprevention.overrideclaimcountlimit` bypass, which only gave two tiers: "limited" and "unlimited". When a player starts a new claim, GP3D now resolves their limit like this: 1. **`griefprevention.overrideclaimcountlimit`** → no limit (unchanged). 2. Otherwise, the **highest** `griefprevention.maxclaims.<amount>` node the player holds is their limit. Because the highest node wins, ranks that inherit from each other just work — a VIP who also inherits `maxclaims.3` from the default group gets 10. 3. Otherwise, the configured `Claims.MaximumNumberOfClaimsPerPlayer` applies (`0` = unlimited). Details: - A permission limit applies even when the config value is `0`, and it can raise **or** lower a player's limit relative to the config. - Negated nodes, wildcards (`griefprevention.maxclaims.*`), and zero/negative amounts are ignored. Use `overrideclaimcountlimit` for unlimited claims. - The limit counts top-level claims the player owns; subdivisions don't count. - It is enforced everywhere a claim can be started: `/claim create`, the golden shovel, and shaped claim mode. The lookup reads the player's effective permissions, so it works with LuckPerms and any other permission plugin, and on every supported Bukkit-family server back to 1.8.8. ## Also in this release - New regression tests covering admin-claim `/claim pvp` toggles (staff can toggle admin claims and their subdivisions; regular players are still denied). - Wiki refresh: shaped subdivisions, shaped claim cuts, administrative subdivisions, PvP/PvE combat trust, and the new claim-count permission are now documented. ## Upgrade notes No configuration or storage changes. Servers that don't grant any `griefprevention.maxclaims.*` nodes behave exactly as before. The experimental Fabric build still uses the config limit and the override permission only. Drop-in replacement for v18.3.10.

# GriefPrevention3D v18.3.10 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## Overview Two fixes for the per-claim PvP toggle on **admin claims**: 1. Admin claims (e.g. a spawn claim) became PvP-enabled **automatically** — "PvP Enabled" flipped on without anyone toggling it; 2. `/claim pvp` (and its confirm step) was rejected on admin claims even for OP players. ## Root cause ### Auto-enabled PvP `pvpEnabled` defaults to `true`. The v18.3.8 fix made the per-claim toggle authoritative in both directions: `claimIsPvPSafeZone` returned `!claim.pvpEnabled` whenever the toggle feature was enabled for that claim type. But that treated *every* claim's default value as an explicit toggle — so any claim that had never been touched was reported as PvP-enabled, overriding the global `PvP.ProtectPlayersInLandClaims.AdministrativeClaims` protection. A spawn admin claim silently lost its PvP safety. ### Cannot toggle admin claims `handlePvpCommand` gated on `claim.hasExplicitPermission(player, ClaimPermission.Edit)`. Admin claims have no owner and no trust lists, so that check can never pass — only the explicit-grant map matters there. OP players were blocked even though `claim.checkPermission` does honor the `griefprevention.adminclaims` permission on admin claims. ## Fix ### Explicit-toggle tracking Claims now carry a `pvpToggleSet` marker that records whether `pvpEnabled` was actually set by a player (`/claim pvp … confirm`), rather than left at its default. `claimIsPvPSafeZone` only applies the per-claim override when that marker is set. Claims that were never toggled fall back to the global no-combat config, so: - **never-toggled** claims: follow `PvP.ProtectPlayersInLandClaims.*` exactly as before (admin claims included — no more surprise PvP-on); - **explicitly disabled** claim: PvP blocked, attacker told why; - **explicitly enabled** claim: combat allowed, overriding any global no-combat fallback; - the "already toggled" message now only fires for an *existing explicit* state, so enabling a default-protected claim still arms the override instead of reporting "already enabled". The marker is persisted: - flat file: new `PvP Toggle Set` key (defaults to missing/false); - database: new `pvptoggled BOOLEAN DEFAULT 0` column (auto-added, schema version 13 → 14); - cross-platform claim document: carried as a schema event-field so it survives claim moves. Subdivisions created with `Subdivision.DefaultState: INHERIT` inherit the parent's marker along with its `pvpEnabled`. ### Admin-claim permission Both the toggle command and its confirm step now use `claim.checkPermission(player, ClaimPermission.Edit)` instead of `hasExplicitPermission`. This lets players holding `griefprevention.adminclaims` (including consoles/ops) enable and disable PvP on admin claims, while everyone else is still denied. ## Upgrade notes No configuration changes. Storage upgrades automatically: - **Database users:** the migration adds the `pvptoggled` column on startup; no manual SQL needed. - **Existing flat-file data:** the new key is optional and defaults to false. One behavior note: claims that were explicitly toggled *before* this release lose their explicit marker once and return to global-config behavior. Re-run `/claim pvp` on those claims to mark them again. Drop-in replacement for v18.3.9.

# GriefPrevention3D v18.3.10 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## Overview Two fixes for the per-claim PvP toggle on **admin claims**: 1. Admin claims (e.g. a spawn claim) became PvP-enabled **automatically** — "PvP Enabled" flipped on without anyone toggling it; 2. `/claim pvp` (and its confirm step) was rejected on admin claims even for OP players. ## Root cause ### Auto-enabled PvP `pvpEnabled` defaults to `true`. The v18.3.8 fix made the per-claim toggle authoritative in both directions: `claimIsPvPSafeZone` returned `!claim.pvpEnabled` whenever the toggle feature was enabled for that claim type. But that treated *every* claim's default value as an explicit toggle — so any claim that had never been touched was reported as PvP-enabled, overriding the global `PvP.ProtectPlayersInLandClaims.AdministrativeClaims` protection. A spawn admin claim silently lost its PvP safety. ### Cannot toggle admin claims `handlePvpCommand` gated on `claim.hasExplicitPermission(player, ClaimPermission.Edit)`. Admin claims have no owner and no trust lists, so that check can never pass — only the explicit-grant map matters there. OP players were blocked even though `claim.checkPermission` does honor the `griefprevention.adminclaims` permission on admin claims. ## Fix ### Explicit-toggle tracking Claims now carry a `pvpToggleSet` marker that records whether `pvpEnabled` was actually set by a player (`/claim pvp … confirm`), rather than left at its default. `claimIsPvPSafeZone` only applies the per-claim override when that marker is set. Claims that were never toggled fall back to the global no-combat config, so: - **never-toggled** claims: follow `PvP.ProtectPlayersInLandClaims.*` exactly as before (admin claims included — no more surprise PvP-on); - **explicitly disabled** claim: PvP blocked, attacker told why; - **explicitly enabled** claim: combat allowed, overriding any global no-combat fallback; - the "already toggled" message now only fires for an *existing explicit* state, so enabling a default-protected claim still arms the override instead of reporting "already enabled". The marker is persisted: - flat file: new `PvP Toggle Set` key (defaults to missing/false); - database: new `pvptoggled BOOLEAN DEFAULT 0` column (auto-added, schema version 13 → 14); - cross-platform claim document: carried as a schema event-field so it survives claim moves. Subdivisions created with `Subdivision.DefaultState: INHERIT` inherit the parent's marker along with its `pvpEnabled`. ### Admin-claim permission Both the toggle command and its confirm step now use `claim.checkPermission(player, ClaimPermission.Edit)` instead of `hasExplicitPermission`. This lets players holding `griefprevention.adminclaims` (including consoles/ops) enable and disable PvP on admin claims, while everyone else is still denied. ## Upgrade notes No configuration changes. Storage upgrades automatically: - **Database users:** the migration adds the `pvptoggled` column on startup; no manual SQL needed. - **Existing flat-file data:** the new key is optional and defaults to false. One behavior note: claims that were explicitly toggled *before* this release lose their explicit marker once and return to global-config behavior. Re-run `/claim pvp` on those claims to mark them again. Drop-in replacement for v18.3.9.

# GriefPrevention3D v18.3.9 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## Overview Fix for the per-claim PvP toggle: attacking a player inside a claim with PvP **disabled** silently denied the hit — the player was protected but never told why. ## Root cause The general melee PvP handler (`handlePvpDamageByPlayer`) had an early-return gate that skipped all claim PvP checks when both global no-combat configs were off: ```java if (attackerData.ignoreClaims || !config_pvp_noCombatInPlayerLandClaims && !config_pvp_noCombatInAdminLandClaims) { return false; } ``` Servers running the per-claim PvP toggle typically leave the global "no combat in claims" flags off (combat is decided per claim), so the gate short-circuited and `handlePvpInClaim` was never reached. That meant `claimIsPvPSafeZone` was never consulted, the attack was not attributed to the claim, and the "that player is in a PvP safe zone" / "can't fight while protected" message never fired — the protection happened silently. ## Fix When the per-claim PvP toggle feature is enabled, the melee handler now bypasses the global-config-only gate and falls through to the normal claim PvP logic. `handlePvpInClaim` consults `claimIsPvPSafeZone`, which cancels the attack in a PvP-disabled claim and sends the appropriate protection message to the attacker. To summarize the resulting per-claim toggle behavior after v18.3.8 + this release: - PvP **enabled** claim: combat works (overrides any global no-combat fallback); - PvP **disabled** claim: combat is blocked *and* the attacker is told why; - claims the server didn't enable the toggle for: fall back to the global config as before. ## Upgrade notes No configuration, storage, or migration changes. Drop-in replacement for v18.3.8.

# GriefPrevention3D v18.3.9 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## Overview Fix for the per-claim PvP toggle: attacking a player inside a claim with PvP **disabled** silently denied the hit — the player was protected but never told why. ## Root cause The general melee PvP handler (`handlePvpDamageByPlayer`) had an early-return gate that skipped all claim PvP checks when both global no-combat configs were off: ```java if (attackerData.ignoreClaims || !config_pvp_noCombatInPlayerLandClaims && !config_pvp_noCombatInAdminLandClaims) { return false; } ``` Servers running the per-claim PvP toggle typically leave the global "no combat in claims" flags off (combat is decided per claim), so the gate short-circuited and `handlePvpInClaim` was never reached. That meant `claimIsPvPSafeZone` was never consulted, the attack was not attributed to the claim, and the "that player is in a PvP safe zone" / "can't fight while protected" message never fired — the protection happened silently. ## Fix When the per-claim PvP toggle feature is enabled, the melee handler now bypasses the global-config-only gate and falls through to the normal claim PvP logic. `handlePvpInClaim` consults `claimIsPvPSafeZone`, which cancels the attack in a PvP-disabled claim and sends the appropriate protection message to the attacker. To summarize the resulting per-claim toggle behavior after v18.3.8 + this release: - PvP **enabled** claim: combat works (overrides any global no-combat fallback); - PvP **disabled** claim: combat is blocked *and* the attacker is told why; - claims the server didn't enable the toggle for: fall back to the global config as before. ## Upgrade notes No configuration, storage, or migration changes. Drop-in replacement for v18.3.8.

# GriefPrevention3D v18.3.8 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## Overview Fix for the per-claim PvP toggle: turning PvP **on** via `/claim pvp on confirm` (or the equivalent) did not actually enable combat — players in the claim remained protected. ## Root cause `claimIsPvPSafeZone` only honored the per-claim setting in one direction. When a claim's PvP toggle was turned **off**, the method correctly returned a safe zone. But when it was turned **on**, the method fell through to the global config fallback (`PvP.ProtectPlayersInLandClaims`, etc.). On servers whose global config protected players in claims (the common default), that fallback still reported the claim as a PvP safe zone — so enabling PvP on an individual claim had no effect. The fix also scopes the toggle by claim type. Previously the check keyed off an aggregate "is either toggle enabled" flag, so enabling only the main-claim toggle would also make subdivisions defer to their per-claim value, bypassing the global subdivision config. ## Fix `claimIsPvPSafeZone` now: - checks the per-claim toggle only for the claim type the server enabled it for (main claim vs subdivision, mirroring `getPvpToggleContext` in the command handler); - treats the claim's own `pvpEnabled` setting as authoritative in **both** directions when that toggle is active — off protects, and on overrides the global "no combat in claims" fallback; - otherwise falls back to the global config, preserving existing behavior on servers that never opted into the per-claim toggle. ## Upgrade notes No configuration, storage, or migration changes. Drop-in replacement for v18.3.7.

# GriefPrevention3D v18.3.8 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## Overview Fix for the per-claim PvP toggle: turning PvP **on** via `/claim pvp on confirm` (or the equivalent) did not actually enable combat — players in the claim remained protected. ## Root cause `claimIsPvPSafeZone` only honored the per-claim setting in one direction. When a claim's PvP toggle was turned **off**, the method correctly returned a safe zone. But when it was turned **on**, the method fell through to the global config fallback (`PvP.ProtectPlayersInLandClaims`, etc.). On servers whose global config protected players in claims (the common default), that fallback still reported the claim as a PvP safe zone — so enabling PvP on an individual claim had no effect. The fix also scopes the toggle by claim type. Previously the check keyed off an aggregate "is either toggle enabled" flag, so enabling only the main-claim toggle would also make subdivisions defer to their per-claim value, bypassing the global subdivision config. ## Fix `claimIsPvPSafeZone` now: - checks the per-claim toggle only for the claim type the server enabled it for (main claim vs subdivision, mirroring `getPvpToggleContext` in the command handler); - treats the claim's own `pvpEnabled` setting as authoritative in **both** directions when that toggle is active — off protects, and on overrides the global "no combat in claims" fallback; - otherwise falls back to the global config, preserving existing behavior on servers that never opted into the per-claim toggle. ## Upgrade notes No configuration, storage, or migration changes. Drop-in replacement for v18.3.7.

# GriefPrevention3D v18.3.7 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## Overview This is a fix release for the shaped claim cuts introduced in v18.3.6. Cut clicks only worked when every click landed at the same Y level; otherwise the path failed to close and players saw **"The resulting shape is not valid"**. ## Root cause Cut click classification used the claim's 3D containment check (`claim.contains(location, ...)`), which requires the clicked block's Y to fall inside the claim's height range. Shaped claims are 2D — their geometry lives entirely in the X/Z plane — so a player clicking on terrain above or below that band produced a point that counted as neither interior nor boundary. The cut path could then never detect closure, and finalization rejected the shape. ## Fix All six cut-flow classification checks now test the click's X/Z coordinates against the boundary polygon directly (`polygon.containsCell(x, z)`) instead of the 3D location check: - interior-cut-click detection (both handler paths); - general interior-click detection; - boundary-closure detection (clicking back onto the boundary to finish the cut). Y level no longer plays any role in shaped claim cuts: you can seed, shape, and close a cut from any elevation. ## Upgrade notes No configuration, storage, or migration changes. Drop-in replacement for v18.3.6.

# GriefPrevention3D v18.3.7 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## Overview This is a fix release for the shaped claim cuts introduced in v18.3.6. Cut clicks only worked when every click landed at the same Y level; otherwise the path failed to close and players saw **"The resulting shape is not valid"**. ## Root cause Cut click classification used the claim's 3D containment check (`claim.contains(location, ...)`), which requires the clicked block's Y to fall inside the claim's height range. Shaped claims are 2D — their geometry lives entirely in the X/Z plane — so a player clicking on terrain above or below that band produced a point that counted as neither interior nor boundary. The cut path could then never detect closure, and finalization rejected the shape. ## Fix All six cut-flow classification checks now test the click's X/Z coordinates against the boundary polygon directly (`polygon.containsCell(x, z)`) instead of the 3D location check: - interior-cut-click detection (both handler paths); - general interior-click detection; - boundary-closure detection (clicking back onto the boundary to finish the cut). Y level no longer plays any role in shaped claim cuts: you can seed, shape, and close a cut from any elevation. ## Upgrade notes No configuration, storage, or migration changes. Drop-in replacement for v18.3.6.

# GriefPrevention3D v18.3.6 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## Overview This release adds **shaped claim cuts** — the ability to carve inward cuts from an existing claim boundary using the shaped claim tool. Where v18.3.x introduced outward reshaping (extending claim boundaries into unclaimed land), this release completes the shaped-claim workflow by allowing players to subtract irregular shapes from their own claims. A cut is started by clicking a boundary segment to seed the path, then clicking inward into the claim interior. Each interior click adds an orthogonal corner point (snapped automatically), and the cut is finalized by clicking back onto any boundary point. The carved region is unclaimed. ## How it works 1. Enter shaped claim mode (`/shapedclaims` or equivalent shovel mode). 2. Click a boundary point on your claim — this seeds the cut path from that boundary edge. 3. Click inward into the claim interior — the first interior click starts the cut and shows a warning message. 4. Continue clicking interior points to shape the cut — each point is snapped to be orthogonal with the previous point. 5. Click back onto any boundary point to complete the cut — the shaped interior region is unclaimed. ## Cut message When a cut is started, the player sees: > Starting a shaped cut of your claim. Continue to shape and merge back to a boundary to complete the cut. Warning: cut means to unclaim that shaped land. ## Technical details - Cut points are validated to be inside the claim polygon (`containsCell`), not just non-boundary points. This ensures interior cut clicks are distinguished from exterior reshape-extension clicks. - Interior points are automatically snapped to be orthogonal with the previous path point, matching the behavior of the existing shaped-claim extension path. - The cut polygon is constructed by walking the claim boundary between the two cut-edge endpoints and inserting the cut path. The resulting polygon is validated via `OrthogonalPolygonValidator.validatePath` for self-intersection, orthogonal edges, and closed-path requirements. - Same-edge cuts (both cut points on the same boundary edge) produce correct non-overlapping polygon geometry with proper corner-to-cutPoint pairings. ## Also in this release - Fix: cut path interior points now snap orthogonally to the previous point when the click is not axis-aligned, matching the extension reshape path behavior.

# GriefPrevention3D v18.3.6 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## Overview This release adds **shaped claim cuts** — the ability to carve inward cuts from an existing claim boundary using the shaped claim tool. Where v18.3.x introduced outward reshaping (extending claim boundaries into unclaimed land), this release completes the shaped-claim workflow by allowing players to subtract irregular shapes from their own claims. A cut is started by clicking a boundary segment to seed the path, then clicking inward into the claim interior. Each interior click adds an orthogonal corner point (snapped automatically), and the cut is finalized by clicking back onto any boundary point. The carved region is unclaimed. ## How it works 1. Enter shaped claim mode (`/shapedclaims` or equivalent shovel mode). 2. Click a boundary point on your claim — this seeds the cut path from that boundary edge. 3. Click inward into the claim interior — the first interior click starts the cut and shows a warning message. 4. Continue clicking interior points to shape the cut — each point is snapped to be orthogonal with the previous point. 5. Click back onto any boundary point to complete the cut — the shaped interior region is unclaimed. ## Cut message When a cut is started, the player sees: > Starting a shaped cut of your claim. Continue to shape and merge back to a boundary to complete the cut. Warning: cut means to unclaim that shaped land. ## Technical details - Cut points are validated to be inside the claim polygon (`containsCell`), not just non-boundary points. This ensures interior cut clicks are distinguished from exterior reshape-extension clicks. - Interior points are automatically snapped to be orthogonal with the previous path point, matching the behavior of the existing shaped-claim extension path. - The cut polygon is constructed by walking the claim boundary between the two cut-edge endpoints and inserting the cut path. The resulting polygon is validated via `OrthogonalPolygonValidator.validatePath` for self-intersection, orthogonal edges, and closed-path requirements. - Same-edge cuts (both cut points on the same boundary edge) produce correct non-overlapping polygon geometry with proper corner-to-cutPoint pairings. ## Also in this release - Fix: cut path interior points now snap orthogonally to the previous point when the click is not axis-aligned, matching the extension reshape path behavior.

# GriefPrevention3D v18.3.5 — Fabric 1.21.11 (experimental alpha) **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki **Roadmap:** [platforms/fabric-1.21.11/ROADMAP.md](https://github.com/castledking/GriefPrevention3D/blob/master/platforms/fabric-1.21.11/ROADMAP.md) — current target 1.21.11, next stop Minecraft 26.1.2 (first unobfuscated release; Loom swap, Java 25, mixin risk assessment inside). > **Still an alpha, dedicated-server-only build.** Not feature complete, not a drop-in replacement > for the Paper plugin. Back up `GriefPreventionData` before running it. Requires Fabric API; > LuckPerms optional but recommended. ## Overview This build retires the monolithic `/gp3d` command root in favor of the same standalone command surface Paper players already know, and ports GP3D's `alias.yml` command-customization system to Fabric so both platforms read one configuration. The same development cycle also delivered player-facing denial feedback and `messages.yml` support, which are summarized below. ## `/gp3d` subcommands become standalone commands Every player-facing action that used to live under the single `/gp3d` Brigadier literal is now a top-level command: | Old | New | |---|---| | `/gp3d claim create ...` | `/createclaim` | | `/gp3d claim trust <target> <type>` | `/trust <target> <type>` | | `/gp3d claim untrust <target>` | `/untrust <target>` | | `/gp3d claims list` | `/claimslist` | | `/gp3d claim abandon` | `/abandonclaim` | | `/gp3d blocks` | `/claimblocks` | | `/gp3d claim here` | `/claimhere` | | `/gp3d claim pvp on\|off` | `/claimpvp on\|off` | `/gpstatus` and `/gpreload` keep their names — they were already top-level. The old `/gp3d ...` spellings are gone rather than deprecated; this is an alpha and the rename is the point. Anything scripted against `/gp3d` (test harnesses, command blocks) needs updating once. The manual migration checklist in the platform README uses the new names throughout. ## alias.yml is now shared with Paper The command alias system moved from the Bukkit plugin into `gp3d-core`, and Fabric reads the same `alias.yml` shape Paper does: - `commands:` lists map a canonical subcommand onto alternate literals; - `standalone:` lists control which top-level commands exist at all; - `arguments:` blocks drive Brigadier suggestion types (`player`, integers, fixed option lists); - per-subcommand and per-root `enable: false` removes them from the tree. A new registrar builds the Brigadier command tree directly from this merged configuration instead of hand-written registrations, so a server operator can disable or rename commands once and both platforms follow. Fabric honors the global `standalone:` switch: when standalone commands are disabled, only the root trees remain registered. Because Brigadier trees are built at registration time, command changes apply on `/gpreload` through re-registration and the client's next command-tree sync. ## Denial feedback and messages.yml Shipped alongside the command work in the same cycle (see the platform README for the full checklist): - Refused block breaks, block uses, entity attacks, and entity interactions reply in red chat with the same message keys Paper uses (`NoBuildPermission`, `NoContainersPermission`, `NoAccessPermission`), resolving `{0}` to the owner's name — subdivisions name the parent's owner, admin claims say "an administrator". - Protection denials are rate limited to one message per player per ten seconds, matching Bukkit's `sendRateLimitedErrorMessage`; cooldowns drop on disconnect. - Player-facing text is read from `messages.yml`, accepting both the plain-key and legacy `<Key>.Text` shapes, translating `&`/`$` codes, `&#RRGGBB` hex, and `\n` before placeholder substitution, falling back to shipped defaults for missing keys, and treating a blanked message as disabled. Unknown addon keys survive read-modify-write cycles. ## Combat trust note Paper's v18.3.5 adds opt-in PvP/PvE combat trust (see v18.3.5.md). The shared claim codec already persists both trust sets, so Fabric claim files round-trip them today; wiring Fabric enforcement and `/trust` type arguments to those sets is tracked in the roadmap rather than this alpha. ## Also in this release - Neighbor trust persistence hardening shared with Paper, including `allowAllNeighbors`. - Upstream merge: interacting with an untamed horse no longer clears its equipment (#2624).

# 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 ```yaml 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 | Target | Legacy gate | With flag on | |---|---|---| | Other players (knockback/combat early-allow in claims) | Access trust | **PvP trust** | | Creatures — animals, villagers, copper golems, sulfur cubes | Container trust | **PvE trust** | 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: ```text 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 ```text /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).

# GriefPrevention3D v18.3.4 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## Overview This maintenance release restores GriefPrevention's upstream manage-trust behavior. Players with manage trust may once again grant normal trust or manage trust to another player, and manage trust once again includes every lower interaction permission. GP3D v18.3.0 separated manage trust from build, container, and access trust. It also restricted a manager to granting only permissions they separately held themselves, while granting manage trust was reserved for the claim owner. Together, those rules produced two confusing failures: - a manager could grant container trust in some cases, but `/trust <player>` appeared to do nothing; - `/managetrust <player>` appeared to do nothing unless the command sender owned the claim. Both restrictions are removed in v18.3.4. Holding manage trust is now the complete authorization needed to manage the claim's grantable trust list, matching upstream GriefPrevention. ## Manage trust is hierarchical again The effective trust hierarchy is restored to: ```text Owner/Edit -> Manage -> Build -> Container -> Access -> Neighbor ``` A manager can therefore build, use containers, and access the claim without needing a second trust entry. Manage trust still does **not** grant owner-only Edit permission: managers cannot resize, delete, transfer, or otherwise perform actions reserved for the claim owner merely because they can manage trust. The hierarchy is applied consistently by the Bukkit claim implementation and the shared trust model used by Fabric. Player UUIDs, `public`, and trusted permission-node identifiers all follow the same ordering when their effective permission is evaluated. ## Managers can delegate trust Trust commands now require the sender to hold Manage permission on the selected or current claim. There is no additional requirement that the sender personally hold the level being granted, and granting manage trust is no longer owner-only. A manager may use: - `/accesstrust <player>`; - `/containertrust <player>`; - `/trust <player>`; and - `/managetrust <player>`. This also applies when the commands are routed through GP3D's unified claim command interfaces. The separate administrative gate for granting trust to arbitrary permission nodes remains in place: `/permissiontrust` still requires `griefprevention.permissiontrust`. ## Relationship to the owner-side trust-loss report The clarification that the command sender owns the claim means the delegation restriction fixed in this release did not block that sender: claim owners already satisfied every grant check. The reported sequence is nevertheless consistent with the separate v18.3.1 storage bug. At that time a claim could store only one trust value per player. An owner could successfully give Linkondorf normal trust and then give him manage trust, but the second command replaced the first entry. Loading the claim applied `Managers` last and could repeat the overwrite. Because manage trust did not include interaction rights in v18.3.1, Linkondorf then appeared to have lost all useful permissions. There is also an important command-name difference between those releases: - In v18.3.1, `/permissiontrust Linkondorf` was an alias for granting player manage trust and could trigger the one-slot overwrite. - Since v18.3.2, player manage trust is `/managetrust Linkondorf`. `/permissiontrust <permission> <access|container|build|manage>` now targets a permission node, so `/permissiontrust Linkondorf` is not a valid player-trust command. v18.3.2 already fixed the destructive part by storing manage and interaction trust independently. v18.3.4 keeps that safer storage model while restoring the upstream hierarchy: - granting manage trust does not overwrite an explicit build, container, or access grant; - granting normal trust does not remove manage trust; - both tracks survive claim loading and saving; and - a surviving manager entry now provides lower interaction permissions by itself. This means an existing player still listed under `Managers` regains build, container, and access without a claim-data migration. If old server versions removed both entries entirely, the claim owner must trust the player again. If a player should retain a particular interaction level after their manage trust is later removed, the owner should also grant that interaction level explicitly; the independent entry remains stored separately from manager status. ### Subdivision scope can look like disappearing trust Trust granted directly in a subdivision applies inside that subdivision and its inheriting descendants; it does not grant the same permission in the surrounding parent claim. With a 3D subdivision, moving above or below its Y bounds can therefore make working trust appear to vanish even though the subdivision entry is still present. An untrusted parent does not asynchronously erase a direct subdivision grant. GP3D checks explicit trust on the current subdivision before consulting its parent, so the direct grant wins while the player remains inside that subdivision. A later `/untrust` performed on the parent can deliberately propagate removal into children which inherit its permissions, but there is no timer which clears a child grant merely because the parent lacks trust. If `/trust Linkondorf` still appears ineffective after upgrading, confirm that the owner and Linkondorf are testing the same claim and vertical layer, that no old golden-shovel claim-selection session is targeting a different subdivision, and that `/trustlist` is being read from that exact claim. ## Upgrade notes - No configuration changes are required. - No permission nodes, commands, aliases, or message keys were added. - No claim-data migration or automatic claim rewrite is required. - Existing `Managers` entries immediately receive the restored lower permissions. - The independent storage introduced in v18.3.2 remains in place; this release changes effective permission evaluation and command authorization, not the on-disk claim format. - `/untrust <player>` continues to remove both manage and interaction trust. ## Verification New command-level regression tests cover the upstream manager-delegation cases with a manager standing inside another player's claim. They verify that `/trust Linkondorf` records Build trust and that `/managetrust Linkondorf` records Manage trust. A separate owner-path test grants Build and then Manage to the same player and verifies that both entries remain. Hierarchy tests verify that Manage grants Build, Container, and Access while owner-only Edit remains denied. The existing real flat-file round-trip test verifies that a player listed under both `Builders` and `Managers` retains both entries after a Paper load and save. Fabric evaluator and repository tests cover the same hierarchy for UUID and permission-node trust while retaining the explicit interaction grant alongside manager status. The full `./gradlew check` pipeline passes: **439 tests, 0 failures, 0 errors** — 250 in the Bukkit plugin, 136 in the shared core, 51 on the Fabric platform, and 2 in the Fabric bootstrap. This also includes the universal JAR audit, Java 8 legacy class loading, shaded-core isolation, and the Fabric boot smoke test against the generated universal JAR. ## Files Changed ```text M gp3d-core/src/main/java/com/griefprevention/claims/ClaimTrustLevel.java M gp3d-core/src/main/java/com/griefprevention/claims/ClaimTrustSnapshot.java M gp3d-core/src/test/java/com/griefprevention/claims/ClaimTrustLevelTest.java M gp3d-core/src/test/java/com/griefprevention/claims/ClaimTrustSnapshotTest.java M gradle.properties M platforms/fabric-1.21.11/src/test/java/com/griefprevention/fabric/FabricClaimRepositoryTrustTest.java M platforms/fabric-1.21.11/src/test/java/com/griefprevention/fabric/FabricClaimTrustEvaluatorTest.java M pom.xml M src/main/java/me/ryanhamshire/GriefPrevention/Claim.java M src/main/java/me/ryanhamshire/GriefPrevention/ClaimPermission.java M src/main/java/me/ryanhamshire/GriefPrevention/GriefPrevention.java M src/test/java/me/ryanhamshire/GriefPrevention/ClaimPermissionTest.java M src/test/java/me/ryanhamshire/GriefPrevention/TrustCommandPermissionTest.java ```

# GriefPrevention3D v18.3.4 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## Overview This maintenance release restores GriefPrevention's upstream manage-trust behavior. Players with manage trust may once again grant normal trust or manage trust to another player, and manage trust once again includes every lower interaction permission. GP3D v18.3.0 separated manage trust from build, container, and access trust. It also restricted a manager to granting only permissions they separately held themselves, while granting manage trust was reserved for the claim owner. Together, those rules produced two confusing failures: - a manager could grant container trust in some cases, but `/trust <player>` appeared to do nothing; - `/managetrust <player>` appeared to do nothing unless the command sender owned the claim. Both restrictions are removed in v18.3.4. Holding manage trust is now the complete authorization needed to manage the claim's grantable trust list, matching upstream GriefPrevention. ## Manage trust is hierarchical again The effective trust hierarchy is restored to: ```text Owner/Edit -> Manage -> Build -> Container -> Access -> Neighbor ``` A manager can therefore build, use containers, and access the claim without needing a second trust entry. Manage trust still does **not** grant owner-only Edit permission: managers cannot resize, delete, transfer, or otherwise perform actions reserved for the claim owner merely because they can manage trust. The hierarchy is applied consistently by the Bukkit claim implementation and the shared trust model used by Fabric. Player UUIDs, `public`, and trusted permission-node identifiers all follow the same ordering when their effective permission is evaluated. ## Managers can delegate trust Trust commands now require the sender to hold Manage permission on the selected or current claim. There is no additional requirement that the sender personally hold the level being granted, and granting manage trust is no longer owner-only. A manager may use: - `/accesstrust <player>`; - `/containertrust <player>`; - `/trust <player>`; and - `/managetrust <player>`. This also applies when the commands are routed through GP3D's unified claim command interfaces. The separate administrative gate for granting trust to arbitrary permission nodes remains in place: `/permissiontrust` still requires `griefprevention.permissiontrust`. ## Relationship to the owner-side trust-loss report The clarification that the command sender owns the claim means the delegation restriction fixed in this release did not block that sender: claim owners already satisfied every grant check. The reported sequence is nevertheless consistent with the separate v18.3.1 storage bug. At that time a claim could store only one trust value per player. An owner could successfully give Linkondorf normal trust and then give him manage trust, but the second command replaced the first entry. Loading the claim applied `Managers` last and could repeat the overwrite. Because manage trust did not include interaction rights in v18.3.1, Linkondorf then appeared to have lost all useful permissions. There is also an important command-name difference between those releases: - In v18.3.1, `/permissiontrust Linkondorf` was an alias for granting player manage trust and could trigger the one-slot overwrite. - Since v18.3.2, player manage trust is `/managetrust Linkondorf`. `/permissiontrust <permission> <access|container|build|manage>` now targets a permission node, so `/permissiontrust Linkondorf` is not a valid player-trust command. v18.3.2 already fixed the destructive part by storing manage and interaction trust independently. v18.3.4 keeps that safer storage model while restoring the upstream hierarchy: - granting manage trust does not overwrite an explicit build, container, or access grant; - granting normal trust does not remove manage trust; - both tracks survive claim loading and saving; and - a surviving manager entry now provides lower interaction permissions by itself. This means an existing player still listed under `Managers` regains build, container, and access without a claim-data migration. If old server versions removed both entries entirely, the claim owner must trust the player again. If a player should retain a particular interaction level after their manage trust is later removed, the owner should also grant that interaction level explicitly; the independent entry remains stored separately from manager status. ### Subdivision scope can look like disappearing trust Trust granted directly in a subdivision applies inside that subdivision and its inheriting descendants; it does not grant the same permission in the surrounding parent claim. With a 3D subdivision, moving above or below its Y bounds can therefore make working trust appear to vanish even though the subdivision entry is still present. An untrusted parent does not asynchronously erase a direct subdivision grant. GP3D checks explicit trust on the current subdivision before consulting its parent, so the direct grant wins while the player remains inside that subdivision. A later `/untrust` performed on the parent can deliberately propagate removal into children which inherit its permissions, but there is no timer which clears a child grant merely because the parent lacks trust. If `/trust Linkondorf` still appears ineffective after upgrading, confirm that the owner and Linkondorf are testing the same claim and vertical layer, that no old golden-shovel claim-selection session is targeting a different subdivision, and that `/trustlist` is being read from that exact claim. ## Upgrade notes - No configuration changes are required. - No permission nodes, commands, aliases, or message keys were added. - No claim-data migration or automatic claim rewrite is required. - Existing `Managers` entries immediately receive the restored lower permissions. - The independent storage introduced in v18.3.2 remains in place; this release changes effective permission evaluation and command authorization, not the on-disk claim format. - `/untrust <player>` continues to remove both manage and interaction trust. ## Verification New command-level regression tests cover the upstream manager-delegation cases with a manager standing inside another player's claim. They verify that `/trust Linkondorf` records Build trust and that `/managetrust Linkondorf` records Manage trust. A separate owner-path test grants Build and then Manage to the same player and verifies that both entries remain. Hierarchy tests verify that Manage grants Build, Container, and Access while owner-only Edit remains denied. The existing real flat-file round-trip test verifies that a player listed under both `Builders` and `Managers` retains both entries after a Paper load and save. Fabric evaluator and repository tests cover the same hierarchy for UUID and permission-node trust while retaining the explicit interaction grant alongside manager status. The full `./gradlew check` pipeline passes: **439 tests, 0 failures, 0 errors** — 250 in the Bukkit plugin, 136 in the shared core, 51 on the Fabric platform, and 2 in the Fabric bootstrap. This also includes the universal JAR audit, Java 8 legacy class loading, shaded-core isolation, and the Fabric boot smoke test against the generated universal JAR. ## Files Changed ```text M gp3d-core/src/main/java/com/griefprevention/claims/ClaimTrustLevel.java M gp3d-core/src/main/java/com/griefprevention/claims/ClaimTrustSnapshot.java M gp3d-core/src/test/java/com/griefprevention/claims/ClaimTrustLevelTest.java M gp3d-core/src/test/java/com/griefprevention/claims/ClaimTrustSnapshotTest.java M gradle.properties M platforms/fabric-1.21.11/src/test/java/com/griefprevention/fabric/FabricClaimRepositoryTrustTest.java M platforms/fabric-1.21.11/src/test/java/com/griefprevention/fabric/FabricClaimTrustEvaluatorTest.java M pom.xml M src/main/java/me/ryanhamshire/GriefPrevention/Claim.java M src/main/java/me/ryanhamshire/GriefPrevention/ClaimPermission.java M src/main/java/me/ryanhamshire/GriefPrevention/GriefPrevention.java M src/test/java/me/ryanhamshire/GriefPrevention/ClaimPermissionTest.java M src/test/java/me/ryanhamshire/GriefPrevention/TrustCommandPermissionTest.java ```

# GriefPrevention3D v18.3.3 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## Overview This maintenance release restores claim knockback protection on Canvas servers. Canvas is a Paper fork and provides Paper's cancellable knockback events, but GP3D detects it as its own platform. The knockback listener recognized only `PAPER` and `SPIGOT`, so it declared itself unsupported when the detected platform was `CANVAS` and was never registered. The issue was reported through sulfur cubes: an untrusted player could punch a cube holding a block and move it around another player's claim despite both of the relevant settings being enabled. The same registration gap affected every protection handled by the platform knockback listener, not only sulfur cubes. ## Canvas now uses the Paper knockback path GP3D has separate listener implementations for the two event APIs exposed by supported Bukkit servers: - Paper and Paper-compatible servers use `EntityKnockbackByEntityEvent` and `EntityPushedByEntityAttackEvent` from the Paper API. - Spigot uses Bukkit's `EntityKnockbackByEntityEvent`. Canvas includes the Paper events and fires them from the sulfur cube's custom knockback path. GP3D now maps `CANVAS` to the Paper implementation, checks that the required Paper event classes exist, and registers `PaperKnockbackProtectionHandler` just as it does on Paper. This restores cancellation for player-caused knockback against: - non-hostile creatures protected by container trust, including sulfur cubes; - armor stands and hanging entities protected by build trust; - players covered by GP3D's PvP-safe claim rules or fresh-spawn immunity; and - projectile and attack-driven knockback routed through the same Paper events. Paper and Spigot retain their existing native listener implementations. Unsupported platforms remain rejected before a platform-specific handler class is loaded, preserving the universal JAR's older-server class-loading behavior. ## Why this appeared as sulfur cube theft A sulfur cube containing a block is already immune to direct player health damage in Minecraft 26.2. Punching it applies the cube's special knockback instead. On Canvas, that knockback event was available but GP3D had no listener registered to cancel it, allowing the cube to be moved despite the claim denial. Once a cube is moved outside the protected claim, the block it carries can be retrieved where the original claim no longer supplies a denial. This is why the incident can look like the cube was killed and its block stolen even though the vulnerable regular-combat path is movement rather than health damage. The normal creature-damage handler is unchanged. With `GriefPrevention.Claims.ProtectCreatures: true`, direct damage to an empty sulfur cube in a claim still requires container trust. A block-holding cube remains immune to player damage at the game level. ## Configuration and scope No configuration, permission, message, command, or claim-data changes are required. Existing settings remain authoritative: ```yaml GriefPrevention: Claims: PreventTheft: true ProtectCreatures: true ``` Both values already default to `true`. This patch covers punch, projectile, and other player-caused movement which fires the platform knockback events. Walking directly into a block-holding sulfur cube uses Minecraft's body-collision movement path and does not fire the same cancellable attack event; that separate path is not changed in this release. ## Verification The regression test records the platform selection directly. It failed before the fix because Canvas resolved to `UNSUPPORTED`, then passed after Canvas was mapped to the Paper knockback API. Additional assertions keep the existing Paper and Spigot selections from regressing. The full `./gradlew check` pipeline passes: **436 tests, 0 failures, 0 errors** — 247 in the Bukkit plugin, 136 in the shared core, 51 on the Fabric platform, and 2 in the Fabric bootstrap. This also includes the universal JAR audit, Java 8 legacy class loading, shaded-core isolation, and the Fabric boot smoke test against the generated universal JAR. The Canvas 26.2 API was inspected to confirm that both Paper event classes required by the selected handler are present. Live-server verification should reproduce the original case with an untrusted player punching a block-holding sulfur cube inside another player's claim and confirm that the cube does not receive the denied knockback. ## Files Changed ```text M gradle.properties M pom.xml M src/main/java/com/griefprevention/platform/knockback/KnockbackProtectionListener.java A src/test/java/com/griefprevention/platform/knockback/KnockbackProtectionListenerTest.java ```

# GriefPrevention3D v18.3.3 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## Overview This maintenance release restores claim knockback protection on Canvas servers. Canvas is a Paper fork and provides Paper's cancellable knockback events, but GP3D detects it as its own platform. The knockback listener recognized only `PAPER` and `SPIGOT`, so it declared itself unsupported when the detected platform was `CANVAS` and was never registered. The issue was reported through sulfur cubes: an untrusted player could punch a cube holding a block and move it around another player's claim despite both of the relevant settings being enabled. The same registration gap affected every protection handled by the platform knockback listener, not only sulfur cubes. ## Canvas now uses the Paper knockback path GP3D has separate listener implementations for the two event APIs exposed by supported Bukkit servers: - Paper and Paper-compatible servers use `EntityKnockbackByEntityEvent` and `EntityPushedByEntityAttackEvent` from the Paper API. - Spigot uses Bukkit's `EntityKnockbackByEntityEvent`. Canvas includes the Paper events and fires them from the sulfur cube's custom knockback path. GP3D now maps `CANVAS` to the Paper implementation, checks that the required Paper event classes exist, and registers `PaperKnockbackProtectionHandler` just as it does on Paper. This restores cancellation for player-caused knockback against: - non-hostile creatures protected by container trust, including sulfur cubes; - armor stands and hanging entities protected by build trust; - players covered by GP3D's PvP-safe claim rules or fresh-spawn immunity; and - projectile and attack-driven knockback routed through the same Paper events. Paper and Spigot retain their existing native listener implementations. Unsupported platforms remain rejected before a platform-specific handler class is loaded, preserving the universal JAR's older-server class-loading behavior. ## Why this appeared as sulfur cube theft A sulfur cube containing a block is already immune to direct player health damage in Minecraft 26.2. Punching it applies the cube's special knockback instead. On Canvas, that knockback event was available but GP3D had no listener registered to cancel it, allowing the cube to be moved despite the claim denial. Once a cube is moved outside the protected claim, the block it carries can be retrieved where the original claim no longer supplies a denial. This is why the incident can look like the cube was killed and its block stolen even though the vulnerable regular-combat path is movement rather than health damage. The normal creature-damage handler is unchanged. With `GriefPrevention.Claims.ProtectCreatures: true`, direct damage to an empty sulfur cube in a claim still requires container trust. A block-holding cube remains immune to player damage at the game level. ## Configuration and scope No configuration, permission, message, command, or claim-data changes are required. Existing settings remain authoritative: ```yaml GriefPrevention: Claims: PreventTheft: true ProtectCreatures: true ``` Both values already default to `true`. This patch covers punch, projectile, and other player-caused movement which fires the platform knockback events. Walking directly into a block-holding sulfur cube uses Minecraft's body-collision movement path and does not fire the same cancellable attack event; that separate path is not changed in this release. ## Verification The regression test records the platform selection directly. It failed before the fix because Canvas resolved to `UNSUPPORTED`, then passed after Canvas was mapped to the Paper knockback API. Additional assertions keep the existing Paper and Spigot selections from regressing. The full `./gradlew check` pipeline passes: **436 tests, 0 failures, 0 errors** — 247 in the Bukkit plugin, 136 in the shared core, 51 on the Fabric platform, and 2 in the Fabric bootstrap. This also includes the universal JAR audit, Java 8 legacy class loading, shaded-core isolation, and the Fabric boot smoke test against the generated universal JAR. The Canvas 26.2 API was inspected to confirm that both Paper event classes required by the selected handler are present. Live-server verification should reproduce the original case with an untrusted player punching a block-holding sulfur cube inside another player's claim and confirm that the cube does not receive the denied knockback. ## Files Changed ```text M gradle.properties M pom.xml M src/main/java/com/griefprevention/platform/knockback/KnockbackProtectionListener.java A src/test/java/com/griefprevention/platform/knockback/KnockbackProtectionListenerTest.java ```

# GriefPrevention3D v18.3.2 — Fabric 1.21.11 (experimental alpha) **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki > **This is an alpha, dedicated-server-only build of the native Fabric platform.** It is not feature > complete and is not a drop-in replacement for the Paper plugin. Back up `GriefPreventionData` > before running it. Requires Fabric API. LuckPerms is optional but strongly recommended. ## Overview This build closes most of the remaining gap between the Fabric claim-block economy and Bukkit's, and brings Paper-compatible permission-node trust to Fabric. Everything below matches upstream GriefPrevention arithmetic deliberately, including its integer division and overflow behavior, so a world can be moved between Paper and Fabric without the numbers changing. ## Manage trust permission renamed The permission that gates granting manage trust is now **`griefprevention.managetrust`**, matching the `/managetrust` command name. It replaces the `griefprevention.managertrust` spelling used during Fabric development. If you granted or denied `griefprevention.managertrust` in LuckPerms, update it. The node defaults to allowed, so a server that never configured it explicitly needs no change. Separately, granting trust to a **permission node** requires `griefprevention.permissiontrust`. On Fabric it inherits from `griefprevention.adminclaims`, and falls back to operator status when no permission provider is installed. ## Manage trust no longer erases interaction trust The shared claim codec stripped build, container, and access trust from any identifier listed under `Managers` when a claim file was read. A player granted `/trust` and then `/managetrust` on Paper lost their interaction trust as soon as the claim was loaded — on either platform. Manage trust and interaction trust are now independent on Fabric too: - reading a claim keeps both; - `/gp3d claim trust <target> manage` no longer clears an existing interaction level, and granting an interaction level no longer clears manage trust; - trust checks are satisfied by either track. Claims already on disk are not migrated. If someone lost access under an earlier build, grant it again once; it will persist correctly from now on. ## Playtime claim blocks Accrual is wired and follows Bukkit's global ten-minute cadence and integer division. The default 100 blocks/hour therefore delivers 16 blocks per check — 96 over six uninterrupted checks, not 100. - The first check treats a player as active unless they are riding or in liquid. Later checks apply `Accrued Idle Threshold` movement detection and `AccruedIdlePercent`. - Accrual applies in every world, including creative and claim-disabled worlds, matching Bukkit. - `griefprevention.accruals` (default allowed) and `griefprevention.accruals.afkbypass` (default operator-only) are honored through the permission bridge, including explicit LuckPerms denials. - Each award participates immediately in balance and claim mutations, and is atomically written to only the accrued-block line of the player file before the delivery completes. - Disconnect and server shutdown retry any award whose write failed. - A zero-or-negative hourly rate at startup does not schedule the task, as on Bukkit; making it positive requires a server restart. Both the legacy `BlocksAccruedPerHour` / `MaxAccruedBlocks` keys and the newer `Claim Blocks Accrued Per Hour.Default` / `Max Accrued Claim Blocks.Default` shapes are read, and legacy values are carried into the newer keys rather than being reset to defaults. ## Claim count limit and abandon return ratio - `MaximumNumberOfClaimsPerPlayer` is enforced. The first golden-shovel corner is rejected at the limit, and persistence rechecks it before the claim is actually created. `griefprevention.overrideclaimcountlimit` bypasses it; Minecraft operators get the same bypass without a permission provider. - A non-default `Claims.AbandonReturnRatio` now applies. Abandoning an owned top-level claim adjusts only the accrued-block line, using Bukkit's exact ceiling arithmetic — at `0.5`, abandoning a 25-block claim removes 13 accrued blocks. - The player record is written atomically. A malformed or concurrently changed record fails the mutation closed instead of being overwritten, and the claim deletion is rolled back if the entitlement update cannot be committed. At the default ratio, player files stay byte-for-byte identical during claim mutations. ## Permission-node trust Paper-compatible `[permission.node]` entries in `Builders`, `Containers`, `Accessors`, and `Managers` are resolved through the optional LuckPerms bridge for block and entity protections and for explosion-trigger access. General and level-specific deny entries are included in the evaluation. The trust commands accept a quoted bracketed node or a bare dotted node, and persist the bracketed Bukkit representation, so a claim edited on Fabric reads correctly on Paper: ```text /gp3d claim trust myserver.vip container /gp3d claim trust "[myserver.vip]" container ``` Trust targets may now also be a previously seen player name, resolved through the online list and Minecraft's seen-player cache — not just online players. Command replies are sent only to the executor instead of being broadcast to other operators. ## Config and message files are updated in place On each Fabric boot, newly shipped `config.yml` and `messages.yml` keys that are missing from an existing file are inserted. Existing values, comments, ordering, and unknown addon fields are left untouched. ## Still not wired Economy operations, administrative balance commands, denial feedback messages, subdivision tools, fluid/piston protection paths, and legacy/database import tooling remain unimplemented. See the [platform README](https://github.com/castledking/GriefPrevention3D/blob/master/platforms/fabric-1.21.11/README.md) for the current coverage list and the manual verification gate. ## Verification The full `./gradlew check` pipeline passes: **434 tests, 0 failures, 0 errors** — 51 on the Fabric platform, 2 in the Fabric bootstrap, 136 in the shared core, and 245 in the Bukkit plugin. The Fabric boot smoke test runs against the exact generated universal JAR. Fabric coverage added here includes the accrual cadence and idle arithmetic, the abandon-ratio penalty, claim-count limits and overrides, permission-node trust evaluation and target resolution, the trust-command permission defaults, and the config/message defaults updater. Cross-platform round trips, LuckPerms-backed permission trust, and the claim-block economy still need live verification. The manual gate in the platform README covers explosions, migration, claim-block balance, accrual, abandon ratio, and permission-node trust on both platforms. ## Files Changed ```text M gp3d-core/src/main/java/com/griefprevention/claims/ClaimBlockConfigCodec.java M gp3d-core/src/main/java/com/griefprevention/claims/ClaimBlockSettings.java M gp3d-core/src/main/java/com/griefprevention/claims/ClaimTrustSnapshot.java M gp3d-core/src/main/java/com/griefprevention/persistence/ClaimDocumentCodec.java M gp3d-core/src/main/java/com/griefprevention/persistence/PlayerDataDocumentCodec.java A gp3d-core/src/main/java/com/griefprevention/claims/ClaimBlockAbandonment.java A gp3d-core/src/main/java/com/griefprevention/claims/ClaimBlockAccrual.java A gp3d-core/src/main/java/com/griefprevention/claims/ClaimTrustCommandPermissions.java A gp3d-core/src/main/java/com/griefprevention/claims/ClaimTrustIdentifier.java M platforms/fabric-1.21.11/README.md M platforms/fabric-1.21.11/src/main/java/com/griefprevention/fabric/FabricClaimBlockService.java M platforms/fabric-1.21.11/src/main/java/com/griefprevention/fabric/FabricClaimRepository.java M platforms/fabric-1.21.11/src/main/java/com/griefprevention/fabric/FabricClaimToolHooks.java M platforms/fabric-1.21.11/src/main/java/com/griefprevention/fabric/FabricCommands.java M platforms/fabric-1.21.11/src/main/java/com/griefprevention/fabric/FabricDataFolder.java M platforms/fabric-1.21.11/src/main/java/com/griefprevention/fabric/FabricExplosionProtection.java M platforms/fabric-1.21.11/src/main/java/com/griefprevention/fabric/FabricProtectionHooks.java M platforms/fabric-1.21.11/src/main/java/com/griefprevention/fabric/GriefPreventionFabric.java A platforms/fabric-1.21.11/src/main/java/com/griefprevention/fabric/FabricClaimBlockAccrual.java A platforms/fabric-1.21.11/src/main/java/com/griefprevention/fabric/FabricClaimTrustEvaluator.java A platforms/fabric-1.21.11/src/main/java/com/griefprevention/fabric/FabricPermissionResolver.java R platforms/fabric-1.21.11/src/main/java/com/griefprevention/fabric/FabricGroupBonusPermissions.java -> FabricPermissions.java A platforms/fabric-1.21.11/src/main/java/com/griefprevention/fabric/FabricTrustCommandAuthorization.java A platforms/fabric-1.21.11/src/main/java/com/griefprevention/fabric/FabricTrustTargetResolver.java R platforms/fabric-1.21.11/src/main/java/com/griefprevention/fabric/LuckPermsGroupBonusPermissionResolver.java -> LuckPermsPermissionResolver.java A platforms/fabric-1.21.11/src/main/java/com/griefprevention/fabric/YamlDefaultsUpdater.java D platforms/fabric-1.21.11/src/main/java/com/griefprevention/fabric/FabricGroupBonusPermissionResolver.java ```

# GriefPrevention3D v18.3.2 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## Overview v18.3.0 restored manage trust as its own track: a manager may edit a claim's trust list but does not implicitly receive build, container, or access trust. That change was correct, but the storage underneath it was not. A claim kept exactly one trust value per player, so granting manage trust **overwrote** whatever build, container, or access trust that player already had. Before v18.3.0 the overwrite was invisible, because manage trust used to imply every lower permission. After v18.3.0 it silently locked trusted players out of chests, doors, and blocks. This release separates the two tracks in storage so they can be held at the same time, and finishes the `/permissiontrust` split that v18.3.0 started: `/permissiontrust` is now the command for granting trust to a **permission node**, and manage trust lives entirely under `/managetrust`. ## Manage trust no longer erases interaction trust A claim now tracks manage trust in its own set, alongside the build/container/access map. - `/managetrust <player>` adds manage trust and leaves existing trust untouched. - `/trust`, `/containertrust`, and `/accesstrust` no longer remove manage trust. - The order the commands are run in no longer matters. - `/untrust <player>` still removes everything, as before. The same defect existed on every path that wrote trust, and all of them are fixed: - **Loading a claim.** `Builders`, `Containers`, `Accessors`, and `Managers` were applied in that order, so anyone listed under `Managers` had their interaction trust stripped on every server start. The lists are now independent. - **Saving a claim.** A player who holds both is written to both lists and round-trips correctly. The cross-platform document writer had a second copy of the same defect and dropped the build/container/access trust of anyone who was also a manager on its way to disk. - **Creating a subdivision.** The creating player was force-set to manage trust, discarding the build or container trust that had just been copied down from the parent claim. - **Clearing inherited trust.** Dropping an inherited copy of one kind of trust also dropped the other. Each track is now dropped on its own. - **Permission-node trust.** A `[permission.node]` entry granted manage trust is now evaluated against both tracks, so a node can carry manage trust and interaction trust together. Two related storage bugs are fixed in the same pass: - Neighbor trust entries were written into the `Accessors` list, which quietly promoted neighbors to access trust the next time the claim loaded. Neighbor trust has its own list and is no longer written to a bucket that does not belong to it. - The shared claim codec used by the Fabric platform stripped interaction trust from anyone listed under `Managers`, mirroring the Bukkit bug. ### Existing claims are not migrated If a player lost trust after upgrading to v18.3.0 or v18.3.1, the data on disk already lost it — the old code overwrote the value before it was ever saved. This release stops the overwrite but does not grant anything back. Claim owners should re-run `/trust`, `/containertrust`, or `/accesstrust` once for anyone who is missing access. It will stick this time, in any command order. ## Permission-node trust is its own command `/permissiontrust` no longer aliases `/managetrust`. It now grants a permission node trust in a claim: ```text /permissiontrust <permission> <access|container|build|manage> /aclaim trust permission <permission> <type> ``` Both the bare dotted form and the Bukkit bracketed form are accepted, and the bracketed form is what gets stored: ```text /permissiontrust myserver.vip container /permissiontrust [myserver.vip] container ``` A target without a dot and without brackets is rejected, so a mistyped player name cannot silently become a permission node. `inventory` is accepted as a synonym for `container`, and `manager` for `manage`. ## Command and permission changes | Before | Now | | --- | --- | | `/permissiontrust <player>` (alias `/pt`) | `/managetrust <player>` (alias `/mt`) | | `/claim trust <player> permission` | `/claim trust <player> manage` (also `manager`) | | — | `/permissiontrust <permission> <type>` (new, alias `/pt`) | | — | `/aclaim trust permission <permission> <type>` (new) | | Permission | Default | Purpose | | --- | --- | --- | | `griefprevention.managetrust` | everyone | Use `/managetrust`. Child of `griefprevention.claims`. | | `griefprevention.permissiontrust` | operators | Grant trust to a permission node. Child of `griefprevention.adminclaims`. | **Read this before upgrading if you manage permissions explicitly.** `griefprevention.permissiontrust` previously granted `/managetrust` and defaulted to `true`. It now means something different and defaults to `false`. Manage trust moved to the new `griefprevention.managetrust` node, which defaults to `true` and is inherited from `griefprevention.claims`, so ordinary players keep `/managetrust` with no configuration change. If your permission plugin grants `griefprevention.permissiontrust` to a non-staff group, revoke it or those players will be able to hand out trust to arbitrary permission nodes. If you explicitly *denied* `griefprevention.permissiontrust` to stop players using the old `/permissiontrust`, that denial no longer affects `/managetrust`; deny `griefprevention.managetrust` instead. `/managetrust` keeps `/mt` but no longer answers to `/pt` or `/permissiontrust`. Both of those names now belong to the new permission-node command, so a player who typed `/pt <player>` out of habit will get a permission error instead of granting manage trust. ## alias.yml upgrades no longer drop sibling entries Merging a server's existing `alias.yml` against the shipped defaults recreated user-owned parent sections, which erased default entries added by an upgrade. Adding `aclaim.trust` beside an existing `aclaim.restore` would have removed one of them. The merge is now leaf-level: every default value is written first, then every user value is overlaid on top. Customizations still win, and new shipped entries survive the upgrade. This is what allows the new `/permissiontrust` and `/aclaim trust permission` entries to appear in an `alias.yml` that already exists. ## Upgrade notes - No claim-data migration is required and no claim files are rewritten on upgrade. - No message keys were added. The existing `InvalidPermissionID` and `CantGrantThatPermission` messages cover the new command's failures. - `griefprevention.permissiontrust` changed meaning and default — see the table above. - A player may now appear in more than one section of `/trustlist`; a manager who also has build trust is listed in both. That is the intended display. - Trust granted to a permission node still requires the target player to actually hold that node at the time of the check, exactly as before. ## Verification The full `./gradlew check` pipeline passes: **434 tests, 0 failures, 0 errors** — 245 in the Bukkit plugin, 136 in the shared core, 51 on the Fabric platform, and 2 in the Fabric bootstrap. This includes the universal JAR audit, legacy class loading, shaded-core isolation, and the Fabric boot smoke test. New regression coverage asserts that manage trust and interaction trust survive each other through loading, both grant orders, both drop paths, and a save round trip; that neighbor trust is never written as access trust; that the permission-node identifier rules reject bare player names; that `/permissiontrust` and `/managetrust` require their own permission nodes; that the shipped permission layout keeps them separate; and that an `alias.yml` merge preserves both user entries and newly shipped siblings. ## Files Changed ```text M gp3d-core/src/main/java/com/griefprevention/claims/ClaimTrustLevel.java M gp3d-core/src/main/java/com/griefprevention/claims/ClaimTrustSnapshot.java M gp3d-core/src/main/java/com/griefprevention/persistence/ClaimDocumentCodec.java M src/main/java/com/griefprevention/commands/CommandAliasConfiguration.java M src/main/java/com/griefprevention/commands/UnifiedAdminClaimCommand.java M src/main/java/com/griefprevention/commands/UnifiedClaimCommand.java M src/main/java/me/ryanhamshire/GriefPrevention/Alias.java M src/main/java/me/ryanhamshire/GriefPrevention/Claim.java M src/main/java/me/ryanhamshire/GriefPrevention/ClaimPermission.java M src/main/java/me/ryanhamshire/GriefPrevention/DataStore.java M src/main/java/me/ryanhamshire/GriefPrevention/FlatFileDataStore.java M src/main/java/me/ryanhamshire/GriefPrevention/GriefPrevention.java M src/main/resources/alias.yml M src/main/resources/plugin.yml M src/test/java/com/griefprevention/commands/UnifiedCommandAliasBehaviorTest.java M src/test/java/me/ryanhamshire/GriefPrevention/ClaimPermissionTest.java M src/test/java/me/ryanhamshire/GriefPrevention/FlatFileClaimMigrationParityTest.java M gp3d-core/src/test/java/com/griefprevention/claims/ClaimTrustLevelTest.java M gp3d-core/src/test/java/com/griefprevention/claims/ClaimTrustSnapshotTest.java M gp3d-core/src/test/java/com/griefprevention/persistence/ClaimDocumentCodecTest.java A gp3d-core/src/main/java/com/griefprevention/claims/ClaimTrustCommandPermissions.java A gp3d-core/src/main/java/com/griefprevention/claims/ClaimTrustIdentifier.java A gp3d-core/src/test/java/com/griefprevention/claims/ClaimTrustIdentifierTest.java A src/test/java/com/griefprevention/commands/UnifiedAdminClaimPermissionTrustTest.java A src/test/java/me/ryanhamshire/GriefPrevention/TrustCommandPermissionTest.java A src/test/java/me/ryanhamshire/GriefPrevention/TrustPermissionLayoutTest.java ```

# GriefPrevention3D v18.3.1 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## Overview This maintenance release completes a broad runtime audit of the universal Bukkit JAR against the 1.8.8 API. GP3D already targets Java 8 bytecode and ships legacy compatibility classes, but several ordinary gameplay paths still linked methods, enum constants, classes, or event shapes which were introduced after Bukkit 1.8. Those references could let the plugin start and then fail only when a specific feature was used. The affected paths now resolve version-dependent behavior through compatibility helpers or stable names. Current servers keep their current APIs and behavior; older servers use the closest safe equivalent available to them. This release also corrects lectern permission handling and a shaped-claim resize case which reported success without changing the polygon or charging/refunding any claim blocks. ## Bukkit 1.8 compatibility ### Restore-nature and claim auto-extension no longer link modern-only world APIs The largest compatibility gap was in the terrain analysis shared by `/restorenature`, automatic nature restoration, and downward claim extension. The code now handles all of the relevant Bukkit API eras: - chunk snapshots use the modern material accessor when present and the legacy numeric block ID accessor on pre-1.13 servers; - biome reads use the modern three-dimensional accessor or the legacy two-dimensional accessor; - biome labels no longer invoke the current `Biome` interface directly—on Bukkit 1.8 the type is a concrete enum/class; - biome namespaced keys are queried only on versions which provide them; - block data comparisons tolerate the absence of the 1.13 `BlockData` API; - custom world environments are matched by name rather than linking the post-1.8 `CUSTOM` enum constant; - cardinal block faces are identified from their coordinate modifiers instead of calling the post-1.8 `BlockFace#isCartesian` and `BlockFace#getDirection` methods; and - End terrain recognizes both `END_STONE` and its legacy `ENDER_STONE` name, while mushroom and badlands restoration similarly use the material available on the running server. The restore material catalogue no longer directly links modern flattened material constants. Logs, leaves, grass, signs, fences, glass panes, doors, rails, stone bricks, wool, planks, slabs, beds, cobwebs, pistons, bricks, spawners, enchanting tables, and related blocks are resolved from both their modern names and their 1.8 aliases. This keeps restored terrain analysis operational without reducing the modern material coverage. QuickShop sign protection still checks persistent-data keys on servers with the 1.14+ API. On older servers, where persistent data does not exist, that check now safely reports no key instead of making the restore snapshot class fail to load. The legacy class-loading audit now loads `RestoreNatureProcessingTask` and invokes its biome-name path with the legacy `DESERT` biome. This specifically guards against reintroducing the class-versus- interface bytecode failure. ### Interaction and event differences are bridged Several event APIs changed shape between Bukkit 1.8 and current Paper. The universal JAR now adapts the following paths: - hopper transfer protection derives inventory locations from their holders when `Inventory#getLocation` is unavailable; - boat collision protection uses the single legacy passenger accessor when the passenger-list API is unavailable; - projectile handlers tolerate the absence of `ProjectileHitEvent#getHitBlock`, and cancel only on server versions where that event implements `Cancellable`; - Nether portal protection accepts legacy `OBC_DESTINATION` creation events, reads either blocks or block states from the event, and tolerates the older event not identifying its creating entity; - block burn protection treats the missing legacy igniting-block accessor as an unknown/spontaneous source; - piston warning sounds use the older three-argument explosion overload when the modern `breakBlocks` flag is unavailable; and - block-place permission simulations use the constructor and item representation supported by the running server instead of directly linking the newest `EquipmentSlot` and block/item type APIs. Player locale detection now falls back to `Player.Spigot#getLocale` on 1.8–1.11. Player bans and pardons use profile bans on current servers and the legacy name ban list before profile bans were introduced. bStats also skips its informational configuration header on Bukkit versions which lack the list-based header method while continuing to save and run metrics normally. ### Legacy materials and entity hierarchies are handled safely Protection and cleanup code no longer assumes flattened material names or newer entity interfaces: - leads recognize both `LEAD` and legacy `LEASH`; - rails recognize both `RAIL` and legacy `RAILS`; - grass-block checks no longer confuse the block with modern `SHORT_GRASS`; - end portal frames accept both `ENDER_EYE` and legacy `EYE_OF_ENDER`, and read the inserted-eye flag through modern block data or legacy metadata; - falling-block refunds read either modern block data or the legacy material accessor; - egg refunds fall back to a plain egg before projectile item stacks existed; - air checks work before `Material#isAir`; - `Mob`, `AbstractHorse`, newer entity types such as copper golems, and loot-table support are detected without hard-linking types absent from 1.8; and - wolf/pet target checks use the legacy `Creature` hierarchy only when the entity actually supports it, avoiding invalid tameable casts on older Bukkit versions. These changes cover creative entity cleanup, entity/block damage protection, pet combat, leashing, projectile block changes, falling-block refunds, and claim interaction checks. ### Boundary visualization remains usable on legacy servers Modern servers still use collision shapes to decide whether an anti-cheat-compatible fake boundary block is transparent. Bukkit 1.8 has no collision-shape or API bounding-box support, so legacy servers now use material occlusion as the fallback. The same compatibility path is used by both the configured anti-cheat visualization and `BoundaryVisualizationEvent` defaults. ## Lectern trust behavior Right-clicking a lectern is no longer treated as ordinary container access merely because a lectern implements `InventoryHolder`. The intended permission split now applies: | Action | Required permission | | --- | --- | | Read a lectern book | Access trust when `LecternReadingRequiresAccessTrust` is `true` | | Take the book | Container trust | | Place a book into the lectern | Container trust | Previously, the general theft-prevention branch ran first and required container trust even for reading, making `GriefPrevention.Claims.LecternReadingRequiresAccessTrust` ineffective for players who had Access but not Container trust. Lecterns are now excluded from that general branch. Reading continues through the existing access-trust rule, while the dedicated take-book event and block-place handling retain container protection. The setting is unchanged and still defaults to `true`: ```yaml GriefPrevention: Claims: LecternReadingRequiresAccessTrust: true ``` ## Shaped-claim nib resizing Resizing from the inner/concave endpoint of a stepped shaped-claim nib now changes the selected face as expected. The concave-nib resolver could construct a candidate which passed polygon validation but normalized back to the original corner list. Because the resize path checked only whether the candidate was valid, GP3D committed the unchanged polygon, sent `Claim resized`, reported the same available claim blocks, and ended the resize session. Nib candidates are now accepted only when they are valid, contain a polygon, **and differ from the original polygon**. An unchanged candidate is ignored so routing can continue to the normal edge move. The same guard applies to cardinal and diagonal nib candidates and to both Bukkit shovel interaction paths. A regression test uses the reported ten-corner stepped claim and verifies both that the formerly failing concave drag changes the polygon and that dragging either endpoint of the inner nib face produces the same resize. ## Upgrade notes - No claim-data migration is required. - No permission nodes or message keys were added. - The lectern setting retains its existing value and default. - Modern APIs remain the preferred path. Besides the lectern and shaped-resize fixes, the only intentional modern behavior correction in this pass is recognizing `GRASS_BLOCK`—rather than the unrelated `SHORT_GRASS` plant—in the sapling placement check. - The compatibility fallbacks are intentionally conservative where old Bukkit exposes less information. For example, pre-1.14 portal events cannot identify the creating entity, and pre-1.13 collision transparency is approximated from material occlusion. ## Verification The full `./gradlew check --no-daemon` pipeline passes. This includes **229 Bukkit tests**, the core and Fabric test suites, the universal JAR audit, legacy class loading, shaded-core isolation, and the Fabric boot smoke test against the exact generated universal JAR. The shaped-nib regression is automated with the reported polygon. The compatibility build verifies that the edited event handlers, restoration tasks, visualization classes, and plugin entry point load against the legacy API. Live-server smoke testing is still recommended for 1.8 event behavior, particularly portals, projectiles, hopper transfers, and terrain restoration. ## Files Changed ```text M build.gradle.kts M src/compat/legacy/java/com/griefprevention/compat/legacy/LegacyClassLoadingCheck.java M src/main/java/com/griefprevention/compat/BlockDataCompat.java M src/main/java/com/griefprevention/events/BoundaryVisualizationEvent.java M src/main/java/com/griefprevention/metrics/Metrics.java M src/main/java/com/griefprevention/protection/InteractionProtectionHandler.java M src/main/java/com/griefprevention/visualization/impl/AntiCheatCompatVisualization.java M src/main/java/me/ryanhamshire/GriefPrevention/AutoExtendClaimTask.java M src/main/java/me/ryanhamshire/GriefPrevention/BlockEventHandler.java M src/main/java/me/ryanhamshire/GriefPrevention/BlockSnapshot.java M src/main/java/me/ryanhamshire/GriefPrevention/ClaimToolDispatcher.java M src/main/java/me/ryanhamshire/GriefPrevention/EntityCleanupTask.java M src/main/java/me/ryanhamshire/GriefPrevention/EntityDamageHandler.java M src/main/java/me/ryanhamshire/GriefPrevention/EntityEventHandler.java M src/main/java/me/ryanhamshire/GriefPrevention/GriefPrevention.java M src/main/java/me/ryanhamshire/GriefPrevention/PlayerEventHandler.java M src/main/java/me/ryanhamshire/GriefPrevention/RestoreNatureExecutionTask.java M src/main/java/me/ryanhamshire/GriefPrevention/RestoreNatureProcessingTask.java M src/main/java/me/ryanhamshire/GriefPrevention/compat/CompatUtil.java M src/main/java/me/ryanhamshire/GriefPrevention/util/BoundingBox.java A src/test/java/me/ryanhamshire/GriefPrevention/ShapedClaimResizeTest.java ```

# GriefPrevention3D v18.3.1 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## Overview This maintenance release completes a broad runtime audit of the universal Bukkit JAR against the 1.8.8 API. GP3D already targets Java 8 bytecode and ships legacy compatibility classes, but several ordinary gameplay paths still linked methods, enum constants, classes, or event shapes which were introduced after Bukkit 1.8. Those references could let the plugin start and then fail only when a specific feature was used. The affected paths now resolve version-dependent behavior through compatibility helpers or stable names. Current servers keep their current APIs and behavior; older servers use the closest safe equivalent available to them. This release also corrects lectern permission handling and a shaped-claim resize case which reported success without changing the polygon or charging/refunding any claim blocks. ## Bukkit 1.8 compatibility ### Restore-nature and claim auto-extension no longer link modern-only world APIs The largest compatibility gap was in the terrain analysis shared by `/restorenature`, automatic nature restoration, and downward claim extension. The code now handles all of the relevant Bukkit API eras: - chunk snapshots use the modern material accessor when present and the legacy numeric block ID accessor on pre-1.13 servers; - biome reads use the modern three-dimensional accessor or the legacy two-dimensional accessor; - biome labels no longer invoke the current `Biome` interface directly—on Bukkit 1.8 the type is a concrete enum/class; - biome namespaced keys are queried only on versions which provide them; - block data comparisons tolerate the absence of the 1.13 `BlockData` API; - custom world environments are matched by name rather than linking the post-1.8 `CUSTOM` enum constant; - cardinal block faces are identified from their coordinate modifiers instead of calling the post-1.8 `BlockFace#isCartesian` and `BlockFace#getDirection` methods; and - End terrain recognizes both `END_STONE` and its legacy `ENDER_STONE` name, while mushroom and badlands restoration similarly use the material available on the running server. The restore material catalogue no longer directly links modern flattened material constants. Logs, leaves, grass, signs, fences, glass panes, doors, rails, stone bricks, wool, planks, slabs, beds, cobwebs, pistons, bricks, spawners, enchanting tables, and related blocks are resolved from both their modern names and their 1.8 aliases. This keeps restored terrain analysis operational without reducing the modern material coverage. QuickShop sign protection still checks persistent-data keys on servers with the 1.14+ API. On older servers, where persistent data does not exist, that check now safely reports no key instead of making the restore snapshot class fail to load. The legacy class-loading audit now loads `RestoreNatureProcessingTask` and invokes its biome-name path with the legacy `DESERT` biome. This specifically guards against reintroducing the class-versus- interface bytecode failure. ### Interaction and event differences are bridged Several event APIs changed shape between Bukkit 1.8 and current Paper. The universal JAR now adapts the following paths: - hopper transfer protection derives inventory locations from their holders when `Inventory#getLocation` is unavailable; - boat collision protection uses the single legacy passenger accessor when the passenger-list API is unavailable; - projectile handlers tolerate the absence of `ProjectileHitEvent#getHitBlock`, and cancel only on server versions where that event implements `Cancellable`; - Nether portal protection accepts legacy `OBC_DESTINATION` creation events, reads either blocks or block states from the event, and tolerates the older event not identifying its creating entity; - block burn protection treats the missing legacy igniting-block accessor as an unknown/spontaneous source; - piston warning sounds use the older three-argument explosion overload when the modern `breakBlocks` flag is unavailable; and - block-place permission simulations use the constructor and item representation supported by the running server instead of directly linking the newest `EquipmentSlot` and block/item type APIs. Player locale detection now falls back to `Player.Spigot#getLocale` on 1.8–1.11. Player bans and pardons use profile bans on current servers and the legacy name ban list before profile bans were introduced. bStats also skips its informational configuration header on Bukkit versions which lack the list-based header method while continuing to save and run metrics normally. ### Legacy materials and entity hierarchies are handled safely Protection and cleanup code no longer assumes flattened material names or newer entity interfaces: - leads recognize both `LEAD` and legacy `LEASH`; - rails recognize both `RAIL` and legacy `RAILS`; - grass-block checks no longer confuse the block with modern `SHORT_GRASS`; - end portal frames accept both `ENDER_EYE` and legacy `EYE_OF_ENDER`, and read the inserted-eye flag through modern block data or legacy metadata; - falling-block refunds read either modern block data or the legacy material accessor; - egg refunds fall back to a plain egg before projectile item stacks existed; - air checks work before `Material#isAir`; - `Mob`, `AbstractHorse`, newer entity types such as copper golems, and loot-table support are detected without hard-linking types absent from 1.8; and - wolf/pet target checks use the legacy `Creature` hierarchy only when the entity actually supports it, avoiding invalid tameable casts on older Bukkit versions. These changes cover creative entity cleanup, entity/block damage protection, pet combat, leashing, projectile block changes, falling-block refunds, and claim interaction checks. ### Boundary visualization remains usable on legacy servers Modern servers still use collision shapes to decide whether an anti-cheat-compatible fake boundary block is transparent. Bukkit 1.8 has no collision-shape or API bounding-box support, so legacy servers now use material occlusion as the fallback. The same compatibility path is used by both the configured anti-cheat visualization and `BoundaryVisualizationEvent` defaults. ## Lectern trust behavior Right-clicking a lectern is no longer treated as ordinary container access merely because a lectern implements `InventoryHolder`. The intended permission split now applies: | Action | Required permission | | --- | --- | | Read a lectern book | Access trust when `LecternReadingRequiresAccessTrust` is `true` | | Take the book | Container trust | | Place a book into the lectern | Container trust | Previously, the general theft-prevention branch ran first and required container trust even for reading, making `GriefPrevention.Claims.LecternReadingRequiresAccessTrust` ineffective for players who had Access but not Container trust. Lecterns are now excluded from that general branch. Reading continues through the existing access-trust rule, while the dedicated take-book event and block-place handling retain container protection. The setting is unchanged and still defaults to `true`: ```yaml GriefPrevention: Claims: LecternReadingRequiresAccessTrust: true ``` ## Shaped-claim nib resizing Resizing from the inner/concave endpoint of a stepped shaped-claim nib now changes the selected face as expected. The concave-nib resolver could construct a candidate which passed polygon validation but normalized back to the original corner list. Because the resize path checked only whether the candidate was valid, GP3D committed the unchanged polygon, sent `Claim resized`, reported the same available claim blocks, and ended the resize session. Nib candidates are now accepted only when they are valid, contain a polygon, **and differ from the original polygon**. An unchanged candidate is ignored so routing can continue to the normal edge move. The same guard applies to cardinal and diagonal nib candidates and to both Bukkit shovel interaction paths. A regression test uses the reported ten-corner stepped claim and verifies both that the formerly failing concave drag changes the polygon and that dragging either endpoint of the inner nib face produces the same resize. ## Upgrade notes - No claim-data migration is required. - No permission nodes or message keys were added. - The lectern setting retains its existing value and default. - Modern APIs remain the preferred path. Besides the lectern and shaped-resize fixes, the only intentional modern behavior correction in this pass is recognizing `GRASS_BLOCK`—rather than the unrelated `SHORT_GRASS` plant—in the sapling placement check. - The compatibility fallbacks are intentionally conservative where old Bukkit exposes less information. For example, pre-1.14 portal events cannot identify the creating entity, and pre-1.13 collision transparency is approximated from material occlusion. ## Verification The full `./gradlew check --no-daemon` pipeline passes. This includes **229 Bukkit tests**, the core and Fabric test suites, the universal JAR audit, legacy class loading, shaded-core isolation, and the Fabric boot smoke test against the exact generated universal JAR. The shaped-nib regression is automated with the reported polygon. The compatibility build verifies that the edited event handlers, restoration tasks, visualization classes, and plugin entry point load against the legacy API. Live-server smoke testing is still recommended for 1.8 event behavior, particularly portals, projectiles, hopper transfers, and terrain restoration. ## Files Changed ```text M build.gradle.kts M src/compat/legacy/java/com/griefprevention/compat/legacy/LegacyClassLoadingCheck.java M src/main/java/com/griefprevention/compat/BlockDataCompat.java M src/main/java/com/griefprevention/events/BoundaryVisualizationEvent.java M src/main/java/com/griefprevention/metrics/Metrics.java M src/main/java/com/griefprevention/protection/InteractionProtectionHandler.java M src/main/java/com/griefprevention/visualization/impl/AntiCheatCompatVisualization.java M src/main/java/me/ryanhamshire/GriefPrevention/AutoExtendClaimTask.java M src/main/java/me/ryanhamshire/GriefPrevention/BlockEventHandler.java M src/main/java/me/ryanhamshire/GriefPrevention/BlockSnapshot.java M src/main/java/me/ryanhamshire/GriefPrevention/ClaimToolDispatcher.java M src/main/java/me/ryanhamshire/GriefPrevention/EntityCleanupTask.java M src/main/java/me/ryanhamshire/GriefPrevention/EntityDamageHandler.java M src/main/java/me/ryanhamshire/GriefPrevention/EntityEventHandler.java M src/main/java/me/ryanhamshire/GriefPrevention/GriefPrevention.java M src/main/java/me/ryanhamshire/GriefPrevention/PlayerEventHandler.java M src/main/java/me/ryanhamshire/GriefPrevention/RestoreNatureExecutionTask.java M src/main/java/me/ryanhamshire/GriefPrevention/RestoreNatureProcessingTask.java M src/main/java/me/ryanhamshire/GriefPrevention/compat/CompatUtil.java M src/main/java/me/ryanhamshire/GriefPrevention/util/BoundingBox.java A src/test/java/me/ryanhamshire/GriefPrevention/ShapedClaimResizeTest.java ```

# GriefPrevention3D v18.3.0 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## Overview GP3D originally followed upstream GriefPrevention's `master` branch. That branch became the development line for v20 and removed several long-standing systems with the expectation that they would move into addons. GP3D still intends to ship those systems in core, so this release audits the fork against upstream's `legacy/v16` branch and restores the remaining functionality which was lost through those merges. This is a source-level port, not a rollback. The restored behavior has been fitted around GP3D's 3D claims, shaped claims, current event API, universal 1.8-to-current JAR, and Folia/Canvas region scheduling. ## Features restored from `legacy/v16` ### Siege is functional again `/siege <player>` and `/claim siege <player>` were still advertised, but the state machine and event rules behind them had been removed upstream. Both commands now start a real siege. A siege may begin when the feature is enabled in the current world, the attacker is close enough, the defender is protected by a player-owned claim, neither player is already fighting or PvP immune, and the player/claim cooldown permits it. Administrative claims cannot be sieged. While the siege is active: - both players must remain near the besieged claim or near one another while giving chase; - logging out, dying, or abandoning the fight forfeits it; - participants cannot drop items, use containers, use the claim shovel, modify claims, or run restricted teleport actions; - outsiders cannot build in or use containers in a besieged claim; - the attacker may break only the configured siege materials; - a claim the defender enters may join the siege when the defender has access there; and - an attacker victory temporarily unlocks buttons and levers, then re-locks the claim and ejects the attacker when the looting window ends. The periodic checkup, unlock/re-lock tasks, player state reads, and ejection are dispatched through the appropriate entity or region scheduler rather than assuming one global server thread. Siege is deliberately **disabled by default**. Add world names before exposing the command: ```yaml GriefPrevention: Siege: Worlds: [] BreakableBlocks: - DIRT - GRASS_BLOCK - COBBLESTONE - GRAVEL - SAND - GLASS - GLASS_PANE - OAK_PLANKS - WHITE_WOOL - SNOW DoorsOpenDelayInSeconds: 300 CooldownEndInMinutes: 60 ``` The generated `BreakableBlocks` list contains the complete legacy-compatible material set, including old and current names for grass, wood, planks, and wool. New permissions: | Permission | Default | Purpose | | --- | --- | --- | | `griefprevention.siege` | everyone | Start a siege | | `griefprevention.siegeimmune` | operators | Prevent other players from sieging this player | | `griefprevention.siegeteleport` | operators | Bypass siege teleport restrictions | When at least one siege world is configured and the three `PvP.ProtectPlayersInLandClaims` settings are absent, their generated defaults become `false`, as they did in legacy GP. Values already present in an existing config remain authoritative. Review those settings before enabling siege on a production world. ### Creative-world entity and active-block controls are back Creative claims once scaled resource limits with their footprint. Those limits and the recurring cleanup pass are restored: - one non-player entity is allowed per 50 claim blocks; - one active block is allowed per 100 claim blocks; - hoppers, beacons, and spawners count as active blocks; - minecarts, armor stands, item frames, hanging entities, spawn eggs, and other entity-producing placements are checked before they are allowed; and - creature spawns are rejected in creative wilderness or when the destination claim is already at its limit. Administrative claims and player claims over 10,000 blocks are exempt from the entity cap. The limits use the top-level claim's 2D footprint, including for 3D subdivisions. The cleanup task starts two minutes after boot, processes ten percent of each creative world's currently loaded chunks per minute, and therefore completes a pass in about ten minutes. It does not intentionally load unloaded chunks. It removes empty boats, invalid minecarts, and non-player entities left in creative wilderness, then trims claims which are already above their entity limit. Each chunk is handled on its owning region. This is an intentionally visible behavior change for creative servers. Wilderness entity displays or mobs which were allowed to accumulate while the upstream code was absent may be removed after upgrading. ### Small unused creative claims expire again The legacy low-investment cleanup path is restored with: ```yaml GriefPrevention: Claims: Expiration: UnusedClaimDays: 14 ``` It considers only non-administrative creative claims no more than 25 blocks wide or deep and with an investment score below 400. Once the owner has been inactive for the configured number of days, the normal expiration event is fired, the claim is deleted with pet release, and the land is restored to nature. As in legacy GP, this is the fallback after whole-account inactivity expiration. It runs only when `Expiration.AllClaims.DaysInactive` is `0`; a non-zero all-claims policy takes precedence. ### AFK-aware claim-block accrual is back Claim-block delivery once distinguished active play from players standing still, sitting in a vehicle, or moving in liquid. That check is restored and still passes through the newer `AccrueClaimBlocksEvent`, so addons may inspect, modify, or cancel the result. ```yaml GriefPrevention: Claims: Accrued Idle Threshold: 0 AccruedIdlePercent: 0 ``` `Accrued Idle Threshold` is the minimum movement distance between accrual checks. The old `AccruedIdleThreshold` spelling is also read for compatibility, but the spaced name is written back. `AccruedIdlePercent` controls the percentage of the normal rate awarded when idle; `0` awards none. Players with `griefprevention.accruals.afkbypass` bypass the idle reduction. ### Permission trust is a separate trust level again `/managetrust`—and its legacy `/permissiontrust` alias—now stores `ClaimPermission.Manage` instead of translating it into ordinary gameplay trust. A manager may edit a claim's trust list but does not implicitly receive build, container, or access permission. Owners and full-edit trustees retain all lower permissions. A trustee may grant only a permission they possess themselves. For example, a player with access trust cannot grant build trust, and only an owner/full editor can grant manage trust. Denied grants use the new `CantGrantThatPermission` message. ### Deleted claims release their owner's pets again The `releasePets` argument survived upstream's cleanup but no longer did anything. When a top-level player claim is deleted through a path which requests pet release, GP3D now finds the owner's tamed animals inside the claim, makes them wild, clears inventories on inventory-bearing pets, and makes sittable pets stand. Work is partitioned by chunk for region-threaded servers. ### WorldGuard-aware claim creation is back When WorldGuard is installed, rectangular and shaped claims may no longer cover an area where the creator lacks WorldGuard's `BUILD` permission: ```yaml GriefPrevention: Claims: CreationRequiresWorldGuardBuildPermission: true ``` `WorldGuard` and `WorldEdit` are soft dependencies. GP3D still loads without either plugin, and the integration uses reflection so WorldGuard is not pulled into the universal JAR's class-loading surface. A WorldGuard API failure is logged to GP debug output and fails open, allowing claim creation instead of taking the claim system offline. ### Economy purchase limits and provider lifecycle are restored Servers may cap purchased bonus claim blocks independently of accrued blocks: ```yaml GriefPrevention: Economy: ClaimBlocksMaxBonus: 0 ``` `0` means unlimited. A positive value rejects `/buyclaimblocks` or `/claim buyblocks` when the requested purchase would put the player's bonus total over the cap. The Vault economy provider is now resolved live for each transaction, so enabling, disabling, or replacing an economy provider does not leave GP3D holding a stale service instance. ### Administrator diagnostics and legacy command access are back - `/gpblockinfo` reports the material in the player's main hand and the material of the targeted block. It requires `griefprevention.gpblockinfo`, which defaults to operators. - `/deletealladminclaims` is usable by an authorized player again, not only from the console. A player must pass the command's `griefprevention.adminclaims` permission and the destructive action's `griefprevention.deleteclaims` check. The deletion is written to the admin log. ### Legacy fire interaction protection is back On older clients fire has no selectable hitbox, so a left-click arrives as a click on the supporting block. GP3D now checks the adjacent fire block, enforces build trust at the claim, cancels denied interaction, and re-sends the fire block to prevent a client-side disappearance. This path avoids introducing a compile-time dependency on newer Bukkit APIs. ## Configuration summary | Setting | Default | Upgrade effect | | --- | ---: | --- | | `Claims.Expiration.UnusedClaimDays` | `14` | Only active when `AllClaims.DaysInactive` is `0`; creative claims only | | `Claims.Accrued Idle Threshold` | `0` | Any unchanged position is idle; vehicles and liquid also count as idle | | `Claims.AccruedIdlePercent` | `0` | Idle players receive no accrued blocks | | `Claims.CreationRequiresWorldGuardBuildPermission` | `true` | Effective only when WorldGuard is installed and hooked | | `Economy.ClaimBlocksMaxBonus` | `0` | Unlimited purchased bonus blocks | | `Siege.Worlds` | `[]` | Siege disabled everywhere | | `Siege.DoorsOpenDelayInSeconds` | `300` | Five-minute attacker looting window | | `Siege.CooldownEndInMinutes` | `60` | Per-opponent/per-claim cooldown | There is no claim-data migration. New settings are written into the normal generated config on startup. Twenty-seven message keys were added for siege and the two other new denial messages, with bundled translations for every supported locale. Custom locale files which omit a key still use the enum's English fallback. ## Compatibility notes - The restored systems remain compatible with the universal 1.8-to-current build. Newer API types used for pet state and WorldGuard are reached reflectively where loading them directly would break an older server. - Creative cleanup, pet release, claim expiration restoration, and siege movement are routed through GP3D's scheduler utilities for Folia and Canvas. - Creative cleanup scans only loaded chunks. Excess entities in an unloaded chunk are handled by a later pass after that chunk has been loaded; the recurring task does not force-load it merely to scan. - Siege state is transient. An active siege is not persisted across a server restart. ## Tests The full `./gradlew check --no-daemon` pipeline passes: **227 tests, 0 failures, 0 errors**. This also includes the legacy class-loading audit, universal JAR verification, and Fabric boot smoke test. New regression coverage verifies the creative entity limits and that Manage trust no longer implicitly grants Build, Container, or Access permission. The integration-heavy paths—WorldGuard, live-world cleanup, pet mutation, legacy fire interaction, and the multi-player siege lifecycle—are compiled and class-loaded by the compatibility/build checks but still require live-server validation of their runtime behavior. ## Files Changed ```text M src/main/java/com/griefprevention/commands/UnifiedClaimCommand.java M src/main/java/me/ryanhamshire/GriefPrevention/BlockEventHandler.java M src/main/java/me/ryanhamshire/GriefPrevention/Claim.java M src/main/java/me/ryanhamshire/GriefPrevention/ClaimPermission.java M src/main/java/me/ryanhamshire/GriefPrevention/CleanupUnusedClaimPreTask.java M src/main/java/me/ryanhamshire/GriefPrevention/CleanupUnusedClaimTask.java M src/main/java/me/ryanhamshire/GriefPrevention/DataStore.java M src/main/java/me/ryanhamshire/GriefPrevention/DeliverClaimBlocksTask.java M src/main/java/me/ryanhamshire/GriefPrevention/EntityEventHandler.java M src/main/java/me/ryanhamshire/GriefPrevention/GriefPrevention.java M src/main/java/me/ryanhamshire/GriefPrevention/Messages.java M src/main/java/me/ryanhamshire/GriefPrevention/PlayerData.java M src/main/java/me/ryanhamshire/GriefPrevention/PlayerEventHandler.java M src/main/resources/messages.yml M src/main/resources/messages_cs_CZ.yml M src/main/resources/messages_de_DE.yml M src/main/resources/messages_en.yml M src/main/resources/messages_en_PT.yml M src/main/resources/messages_es.yml M src/main/resources/messages_fr_FR.yml M src/main/resources/messages_ja_JP.yml M src/main/resources/messages_ms_MY.yml M src/main/resources/messages_pl_PL.yml M src/main/resources/messages_pt_BR.yml M src/main/resources/messages_ru_RU.yml M src/main/resources/messages_tr_TR.yml M src/main/resources/messages_uk_UA.yml M src/main/resources/messages_zh_CN.yml M src/main/resources/plugin.yml M src/test/java/me/ryanhamshire/GriefPrevention/ClaimPermissionTest.java A src/main/java/me/ryanhamshire/GriefPrevention/EntityCleanupTask.java A src/main/java/me/ryanhamshire/GriefPrevention/SecureClaimTask.java A src/main/java/me/ryanhamshire/GriefPrevention/SiegeCheckupTask.java A src/main/java/me/ryanhamshire/GriefPrevention/SiegeData.java A src/main/java/me/ryanhamshire/GriefPrevention/SiegeEventHandler.java A src/main/java/me/ryanhamshire/GriefPrevention/WorldGuardWrapper.java A src/test/java/me/ryanhamshire/GriefPrevention/CreativeEntityLimitTest.java ```

# GriefPrevention3D v18.3.0 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## Overview GP3D originally followed upstream GriefPrevention's `master` branch. That branch became the development line for v20 and removed several long-standing systems with the expectation that they would move into addons. GP3D still intends to ship those systems in core, so this release audits the fork against upstream's `legacy/v16` branch and restores the remaining functionality which was lost through those merges. This is a source-level port, not a rollback. The restored behavior has been fitted around GP3D's 3D claims, shaped claims, current event API, universal 1.8-to-current JAR, and Folia/Canvas region scheduling. ## Features restored from `legacy/v16` ### Siege is functional again `/siege <player>` and `/claim siege <player>` were still advertised, but the state machine and event rules behind them had been removed upstream. Both commands now start a real siege. A siege may begin when the feature is enabled in the current world, the attacker is close enough, the defender is protected by a player-owned claim, neither player is already fighting or PvP immune, and the player/claim cooldown permits it. Administrative claims cannot be sieged. While the siege is active: - both players must remain near the besieged claim or near one another while giving chase; - logging out, dying, or abandoning the fight forfeits it; - participants cannot drop items, use containers, use the claim shovel, modify claims, or run restricted teleport actions; - outsiders cannot build in or use containers in a besieged claim; - the attacker may break only the configured siege materials; - a claim the defender enters may join the siege when the defender has access there; and - an attacker victory temporarily unlocks buttons and levers, then re-locks the claim and ejects the attacker when the looting window ends. The periodic checkup, unlock/re-lock tasks, player state reads, and ejection are dispatched through the appropriate entity or region scheduler rather than assuming one global server thread. Siege is deliberately **disabled by default**. Add world names before exposing the command: ```yaml GriefPrevention: Siege: Worlds: [] BreakableBlocks: - DIRT - GRASS_BLOCK - COBBLESTONE - GRAVEL - SAND - GLASS - GLASS_PANE - OAK_PLANKS - WHITE_WOOL - SNOW DoorsOpenDelayInSeconds: 300 CooldownEndInMinutes: 60 ``` The generated `BreakableBlocks` list contains the complete legacy-compatible material set, including old and current names for grass, wood, planks, and wool. New permissions: | Permission | Default | Purpose | | --- | --- | --- | | `griefprevention.siege` | everyone | Start a siege | | `griefprevention.siegeimmune` | operators | Prevent other players from sieging this player | | `griefprevention.siegeteleport` | operators | Bypass siege teleport restrictions | When at least one siege world is configured and the three `PvP.ProtectPlayersInLandClaims` settings are absent, their generated defaults become `false`, as they did in legacy GP. Values already present in an existing config remain authoritative. Review those settings before enabling siege on a production world. ### Creative-world entity and active-block controls are back Creative claims once scaled resource limits with their footprint. Those limits and the recurring cleanup pass are restored: - one non-player entity is allowed per 50 claim blocks; - one active block is allowed per 100 claim blocks; - hoppers, beacons, and spawners count as active blocks; - minecarts, armor stands, item frames, hanging entities, spawn eggs, and other entity-producing placements are checked before they are allowed; and - creature spawns are rejected in creative wilderness or when the destination claim is already at its limit. Administrative claims and player claims over 10,000 blocks are exempt from the entity cap. The limits use the top-level claim's 2D footprint, including for 3D subdivisions. The cleanup task starts two minutes after boot, processes ten percent of each creative world's currently loaded chunks per minute, and therefore completes a pass in about ten minutes. It does not intentionally load unloaded chunks. It removes empty boats, invalid minecarts, and non-player entities left in creative wilderness, then trims claims which are already above their entity limit. Each chunk is handled on its owning region. This is an intentionally visible behavior change for creative servers. Wilderness entity displays or mobs which were allowed to accumulate while the upstream code was absent may be removed after upgrading. ### Small unused creative claims expire again The legacy low-investment cleanup path is restored with: ```yaml GriefPrevention: Claims: Expiration: UnusedClaimDays: 14 ``` It considers only non-administrative creative claims no more than 25 blocks wide or deep and with an investment score below 400. Once the owner has been inactive for the configured number of days, the normal expiration event is fired, the claim is deleted with pet release, and the land is restored to nature. As in legacy GP, this is the fallback after whole-account inactivity expiration. It runs only when `Expiration.AllClaims.DaysInactive` is `0`; a non-zero all-claims policy takes precedence. ### AFK-aware claim-block accrual is back Claim-block delivery once distinguished active play from players standing still, sitting in a vehicle, or moving in liquid. That check is restored and still passes through the newer `AccrueClaimBlocksEvent`, so addons may inspect, modify, or cancel the result. ```yaml GriefPrevention: Claims: Accrued Idle Threshold: 0 AccruedIdlePercent: 0 ``` `Accrued Idle Threshold` is the minimum movement distance between accrual checks. The old `AccruedIdleThreshold` spelling is also read for compatibility, but the spaced name is written back. `AccruedIdlePercent` controls the percentage of the normal rate awarded when idle; `0` awards none. Players with `griefprevention.accruals.afkbypass` bypass the idle reduction. ### Permission trust is a separate trust level again `/managetrust`—and its legacy `/permissiontrust` alias—now stores `ClaimPermission.Manage` instead of translating it into ordinary gameplay trust. A manager may edit a claim's trust list but does not implicitly receive build, container, or access permission. Owners and full-edit trustees retain all lower permissions. A trustee may grant only a permission they possess themselves. For example, a player with access trust cannot grant build trust, and only an owner/full editor can grant manage trust. Denied grants use the new `CantGrantThatPermission` message. ### Deleted claims release their owner's pets again The `releasePets` argument survived upstream's cleanup but no longer did anything. When a top-level player claim is deleted through a path which requests pet release, GP3D now finds the owner's tamed animals inside the claim, makes them wild, clears inventories on inventory-bearing pets, and makes sittable pets stand. Work is partitioned by chunk for region-threaded servers. ### WorldGuard-aware claim creation is back When WorldGuard is installed, rectangular and shaped claims may no longer cover an area where the creator lacks WorldGuard's `BUILD` permission: ```yaml GriefPrevention: Claims: CreationRequiresWorldGuardBuildPermission: true ``` `WorldGuard` and `WorldEdit` are soft dependencies. GP3D still loads without either plugin, and the integration uses reflection so WorldGuard is not pulled into the universal JAR's class-loading surface. A WorldGuard API failure is logged to GP debug output and fails open, allowing claim creation instead of taking the claim system offline. ### Economy purchase limits and provider lifecycle are restored Servers may cap purchased bonus claim blocks independently of accrued blocks: ```yaml GriefPrevention: Economy: ClaimBlocksMaxBonus: 0 ``` `0` means unlimited. A positive value rejects `/buyclaimblocks` or `/claim buyblocks` when the requested purchase would put the player's bonus total over the cap. The Vault economy provider is now resolved live for each transaction, so enabling, disabling, or replacing an economy provider does not leave GP3D holding a stale service instance. ### Administrator diagnostics and legacy command access are back - `/gpblockinfo` reports the material in the player's main hand and the material of the targeted block. It requires `griefprevention.gpblockinfo`, which defaults to operators. - `/deletealladminclaims` is usable by an authorized player again, not only from the console. A player must pass the command's `griefprevention.adminclaims` permission and the destructive action's `griefprevention.deleteclaims` check. The deletion is written to the admin log. ### Legacy fire interaction protection is back On older clients fire has no selectable hitbox, so a left-click arrives as a click on the supporting block. GP3D now checks the adjacent fire block, enforces build trust at the claim, cancels denied interaction, and re-sends the fire block to prevent a client-side disappearance. This path avoids introducing a compile-time dependency on newer Bukkit APIs. ## Configuration summary | Setting | Default | Upgrade effect | | --- | ---: | --- | | `Claims.Expiration.UnusedClaimDays` | `14` | Only active when `AllClaims.DaysInactive` is `0`; creative claims only | | `Claims.Accrued Idle Threshold` | `0` | Any unchanged position is idle; vehicles and liquid also count as idle | | `Claims.AccruedIdlePercent` | `0` | Idle players receive no accrued blocks | | `Claims.CreationRequiresWorldGuardBuildPermission` | `true` | Effective only when WorldGuard is installed and hooked | | `Economy.ClaimBlocksMaxBonus` | `0` | Unlimited purchased bonus blocks | | `Siege.Worlds` | `[]` | Siege disabled everywhere | | `Siege.DoorsOpenDelayInSeconds` | `300` | Five-minute attacker looting window | | `Siege.CooldownEndInMinutes` | `60` | Per-opponent/per-claim cooldown | There is no claim-data migration. New settings are written into the normal generated config on startup. Twenty-seven message keys were added for siege and the two other new denial messages, with bundled translations for every supported locale. Custom locale files which omit a key still use the enum's English fallback. ## Compatibility notes - The restored systems remain compatible with the universal 1.8-to-current build. Newer API types used for pet state and WorldGuard are reached reflectively where loading them directly would break an older server. - Creative cleanup, pet release, claim expiration restoration, and siege movement are routed through GP3D's scheduler utilities for Folia and Canvas. - Creative cleanup scans only loaded chunks. Excess entities in an unloaded chunk are handled by a later pass after that chunk has been loaded; the recurring task does not force-load it merely to scan. - Siege state is transient. An active siege is not persisted across a server restart. ## Tests The full `./gradlew check --no-daemon` pipeline passes: **227 tests, 0 failures, 0 errors**. This also includes the legacy class-loading audit, universal JAR verification, and Fabric boot smoke test. New regression coverage verifies the creative entity limits and that Manage trust no longer implicitly grants Build, Container, or Access permission. The integration-heavy paths—WorldGuard, live-world cleanup, pet mutation, legacy fire interaction, and the multi-player siege lifecycle—are compiled and class-loaded by the compatibility/build checks but still require live-server validation of their runtime behavior. ## Files Changed ```text M src/main/java/com/griefprevention/commands/UnifiedClaimCommand.java M src/main/java/me/ryanhamshire/GriefPrevention/BlockEventHandler.java M src/main/java/me/ryanhamshire/GriefPrevention/Claim.java M src/main/java/me/ryanhamshire/GriefPrevention/ClaimPermission.java M src/main/java/me/ryanhamshire/GriefPrevention/CleanupUnusedClaimPreTask.java M src/main/java/me/ryanhamshire/GriefPrevention/CleanupUnusedClaimTask.java M src/main/java/me/ryanhamshire/GriefPrevention/DataStore.java M src/main/java/me/ryanhamshire/GriefPrevention/DeliverClaimBlocksTask.java M src/main/java/me/ryanhamshire/GriefPrevention/EntityEventHandler.java M src/main/java/me/ryanhamshire/GriefPrevention/GriefPrevention.java M src/main/java/me/ryanhamshire/GriefPrevention/Messages.java M src/main/java/me/ryanhamshire/GriefPrevention/PlayerData.java M src/main/java/me/ryanhamshire/GriefPrevention/PlayerEventHandler.java M src/main/resources/messages.yml M src/main/resources/messages_cs_CZ.yml M src/main/resources/messages_de_DE.yml M src/main/resources/messages_en.yml M src/main/resources/messages_en_PT.yml M src/main/resources/messages_es.yml M src/main/resources/messages_fr_FR.yml M src/main/resources/messages_ja_JP.yml M src/main/resources/messages_ms_MY.yml M src/main/resources/messages_pl_PL.yml M src/main/resources/messages_pt_BR.yml M src/main/resources/messages_ru_RU.yml M src/main/resources/messages_tr_TR.yml M src/main/resources/messages_uk_UA.yml M src/main/resources/messages_zh_CN.yml M src/main/resources/plugin.yml M src/test/java/me/ryanhamshire/GriefPrevention/ClaimPermissionTest.java A src/main/java/me/ryanhamshire/GriefPrevention/EntityCleanupTask.java A src/main/java/me/ryanhamshire/GriefPrevention/SecureClaimTask.java A src/main/java/me/ryanhamshire/GriefPrevention/SiegeCheckupTask.java A src/main/java/me/ryanhamshire/GriefPrevention/SiegeData.java A src/main/java/me/ryanhamshire/GriefPrevention/SiegeEventHandler.java A src/main/java/me/ryanhamshire/GriefPrevention/WorldGuardWrapper.java A src/test/java/me/ryanhamshire/GriefPrevention/CreativeEntityLimitTest.java ```

# GriefPrevention3D v18.2.20 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## Features ### Automatic nature restoration is back Upstream deleted the entire restore-nature feature in [GriefPrevention#2332](https://github.com/GriefPrevention/GriefPrevention/pull/2332) (`5d0ebdec`, July 2024). That commit landed here through a routine upstream merge, so servers that had been running automatic cleanup for years lost it on update with nothing in the changelog pointing at it. The manual half came back in `cab3d9cf` — `/restorenature`, `/restorenatureaggressive` and `/restorenaturefill` all work, along with `RestoreNatureProcessingTask` and `RestoreNatureExecutionTask`. The automatic half did not. `restoreClaim` and `restoreChunk` existed nowhere in the source, the `AutomaticNatureRestoration` config key was never read, and `CleanupUnusedClaimTask` deleted expired claims and left the land exactly as the owner abandoned it. There was no setting an admin could flip, because there was no setting. This release reconnects the automatic path to the processing tasks that were already shipping. **Config:** ```yaml GriefPrevention: Claims: Expiration: AutomaticNatureRestoration: SurvivalWorlds: false ``` Defaults to `false`, matching upstream, so no existing server starts editing terrain after updating. It is written back on the next config save. **Where restoration now fires:** | Trigger | Restores when | | --- | --- | | Chest claim expiry (`Expiration.ChestClaimDays`) | creative world, **or** `SurvivalWorlds: true` | | Inactivity expiry (`Expiration.AllClaims.DaysInactive`) | creative world, **or** `SurvivalWorlds: true` | | Staff `/deleteclaim` | creative world, **or** `SurvivalWorlds: true` | | Player `/abandonclaim` | creative world only | That table is upstream's behaviour reproduced exactly, including the asymmetry on the last row. `SurvivalWorlds` was never consulted on the abandon path — upstream gated it on `creativeRulesApply` alone, and the field comment read *"whether survival claims will be automatically restored to nature when auto-deleted."* A survival player abandoning a claim does not get their build flattened. Restoration is silent when it fires automatically. `RestoreNatureExecutionTask.showVisualization` returns immediately on a null player ID, so nothing is drawn and no message is sent; the only trace is the existing expiry line in the admin log. The size guards are upstream's: admin claims are skipped entirely, and so is anything over 10000 blocks of area, 250 wide or 250 deep. `Claim#getArea` resolves to `ClaimBounds#area()` — the 2D footprint, or `polygon.cellCount()` for a shaped claim — and `getWidth`/`getHeight` are X and Z lengths, so these thresholds mean here what they meant upstream despite this fork's 3D claims. ### `Claim#removeSurfaceFluids` and `Messages.UnclaimCleanupWarning` restored Both were collateral in the same upstream removal and are needed by the paths above. `removeSurfaceFluids` clears lava and water above sea level before a claim is deleted, only in creative-rules worlds, never in the Nether, and never for admin or oversized claims. It now bounds its scan with `GriefPrevention.getWorldMaxY` instead of the old `World#getMaxHeight`. `UnclaimCleanupWarning` is back in the enum and translated across all fifteen message files — cs_CZ, de_DE, en, en_PT, es, fr_FR, ja_JP, ms_MY, pl_PL, pt_BR, ru_RU, tr_TR, uk_UA, zh_CN and the base `messages.yml`. Each follows the quoting convention and level of formality already used in that file, and reuses that locale's established word for a claim rather than introducing a new one. Servers with a customised `messages.yml` on disk are unaffected either way: a key absent from the file falls back to `message.defaultValue` in `MessageLocalization.populateMessagesArray`, so the message appears in English rather than not at all. ## Technical changes Two deliberate departures from the code that was deleted, both because this fork supports region threading and upstream did not. **Chunk coordinates are derived arithmetically.** Upstream's `restoreClaim` iterated `Claim#getChunks()`, which calls `world.getChunkAt(x, z)` and loads chunks on the calling thread — rejected under Folia and Canvas when that thread does not own the region. `restoreClaim` now walks `lesser.getBlockX() >> 4` to `greater.getBlockX() >> 4` directly and never touches a `Chunk` object. `restoreChunk(Chunk, ...)` is kept with upstream's signature for API compatibility and delegates to the coordinate-based path. **Block capture happens on the owning region thread.** Upstream scheduled the whole operation with `runTaskLaterAsynchronously` and read blocks from the async task. The work is now split: ```java SchedulerUtil.runAtLocationLater(this, snapshotOrigin, () -> { // snapshot 18x18 columns on the region thread SchedulerUtil.runAsyncNow(this, task); // analysis off-thread }, delayInTicks); ``` `RestoreNatureProcessingTask` already closes the loop itself, dispatching `RestoreNatureExecutionTask` back through `SchedulerUtil.runAtLocation` before it writes anything. This mirrors how the fork's existing `/restorenature` handler in `PlayerEventHandler` already worked, rather than introducing a second convention. Two smaller details: - The vertical window starts at `seaLevel - 15`, upstream's floor, so caves and mines under a claim are left alone. The fork's `RestoreNatureProcessingTask` treats its `miny` parameter as an array index rather than a world Y, so the snapshot array itself starts at that floor and `0` is passed in — the manual tool, which captures the full column, passes a world minimum that clamps to the same `0`. - The boundary corners describe the chunk proper, `+1` and `+16` off the snapshot origin, not the 18-wide array. The outer ring is reference data the execution task never writes to, and `cleanupEntities` uses those corners to decide which entities are in scope. ## Notes - Nothing happens until `Expiration.ChestClaimDays` or `Expiration.AllClaims.DaysInactive` is non-zero. Restoration is driven by expiry; with expiry disabled the flag has no effect. - Non-aggressive mode is what the automatic path uses, so `RestoreNatureExecutionTask` runs `getClaimAt` per block and skips anything still inside a claim. Neighbouring claims that share a chunk with a deleted one are safe. - Restoration operates per chunk, so it reaches the whole chunk rather than the claim footprint, and for a 3D claim it spans the full column above the floor rather than the claim's Y bounds. The per-block claim check above is what keeps that from mattering. - No data migration. No permission changes. No command changes. ## Tests No new tests. The full suite passes — **226 tests, 0 failures, 0 errors**. The restore path has no unit coverage and does not gain any here. It needs a live world to snapshot, a region scheduler to dispatch through, and real block writes to assert against; the mock harness provides none of the three. What was verified statically: `Claim#getArea`, `getWidth` and `getHeight` were traced through `ClaimBounds` to confirm the upstream size thresholds still describe a 2D footprint in this fork; `miny` was traced through every use in `RestoreNatureProcessingTask` to confirm it is an array index and unused in `RestoreNatureExecutionTask`; and both edited message files were parsed to confirm the apostrophes in the restored string do not break YAML. ## Files Changed ``` M gradle.properties M pom.xml M src/main/java/com/griefprevention/commands/UnifiedAdminClaimCommand.java M src/main/java/me/ryanhamshire/GriefPrevention/Claim.java M src/main/java/me/ryanhamshire/GriefPrevention/CleanupUnusedClaimTask.java M src/main/java/me/ryanhamshire/GriefPrevention/GriefPrevention.java M src/main/java/me/ryanhamshire/GriefPrevention/Messages.java M src/main/resources/messages.yml M src/main/resources/messages_cs_CZ.yml M src/main/resources/messages_de_DE.yml M src/main/resources/messages_en.yml M src/main/resources/messages_en_PT.yml M src/main/resources/messages_es.yml M src/main/resources/messages_fr_FR.yml M src/main/resources/messages_ja_JP.yml M src/main/resources/messages_ms_MY.yml M src/main/resources/messages_pl_PL.yml M src/main/resources/messages_pt_BR.yml M src/main/resources/messages_ru_RU.yml M src/main/resources/messages_tr_TR.yml M src/main/resources/messages_uk_UA.yml M src/main/resources/messages_zh_CN.yml ```

# GriefPrevention3D v18.2.20 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## Features ### Automatic nature restoration is back Upstream deleted the entire restore-nature feature in [GriefPrevention#2332](https://github.com/GriefPrevention/GriefPrevention/pull/2332) (`5d0ebdec`, July 2024). That commit landed here through a routine upstream merge, so servers that had been running automatic cleanup for years lost it on update with nothing in the changelog pointing at it. The manual half came back in `cab3d9cf` — `/restorenature`, `/restorenatureaggressive` and `/restorenaturefill` all work, along with `RestoreNatureProcessingTask` and `RestoreNatureExecutionTask`. The automatic half did not. `restoreClaim` and `restoreChunk` existed nowhere in the source, the `AutomaticNatureRestoration` config key was never read, and `CleanupUnusedClaimTask` deleted expired claims and left the land exactly as the owner abandoned it. There was no setting an admin could flip, because there was no setting. This release reconnects the automatic path to the processing tasks that were already shipping. **Config:** ```yaml GriefPrevention: Claims: Expiration: AutomaticNatureRestoration: SurvivalWorlds: false ``` Defaults to `false`, matching upstream, so no existing server starts editing terrain after updating. It is written back on the next config save. **Where restoration now fires:** | Trigger | Restores when | | --- | --- | | Chest claim expiry (`Expiration.ChestClaimDays`) | creative world, **or** `SurvivalWorlds: true` | | Inactivity expiry (`Expiration.AllClaims.DaysInactive`) | creative world, **or** `SurvivalWorlds: true` | | Staff `/deleteclaim` | creative world, **or** `SurvivalWorlds: true` | | Player `/abandonclaim` | creative world only | That table is upstream's behaviour reproduced exactly, including the asymmetry on the last row. `SurvivalWorlds` was never consulted on the abandon path — upstream gated it on `creativeRulesApply` alone, and the field comment read *"whether survival claims will be automatically restored to nature when auto-deleted."* A survival player abandoning a claim does not get their build flattened. Restoration is silent when it fires automatically. `RestoreNatureExecutionTask.showVisualization` returns immediately on a null player ID, so nothing is drawn and no message is sent; the only trace is the existing expiry line in the admin log. The size guards are upstream's: admin claims are skipped entirely, and so is anything over 10000 blocks of area, 250 wide or 250 deep. `Claim#getArea` resolves to `ClaimBounds#area()` — the 2D footprint, or `polygon.cellCount()` for a shaped claim — and `getWidth`/`getHeight` are X and Z lengths, so these thresholds mean here what they meant upstream despite this fork's 3D claims. ### `Claim#removeSurfaceFluids` and `Messages.UnclaimCleanupWarning` restored Both were collateral in the same upstream removal and are needed by the paths above. `removeSurfaceFluids` clears lava and water above sea level before a claim is deleted, only in creative-rules worlds, never in the Nether, and never for admin or oversized claims. It now bounds its scan with `GriefPrevention.getWorldMaxY` instead of the old `World#getMaxHeight`. `UnclaimCleanupWarning` is back in the enum and translated across all fifteen message files — cs_CZ, de_DE, en, en_PT, es, fr_FR, ja_JP, ms_MY, pl_PL, pt_BR, ru_RU, tr_TR, uk_UA, zh_CN and the base `messages.yml`. Each follows the quoting convention and level of formality already used in that file, and reuses that locale's established word for a claim rather than introducing a new one. Servers with a customised `messages.yml` on disk are unaffected either way: a key absent from the file falls back to `message.defaultValue` in `MessageLocalization.populateMessagesArray`, so the message appears in English rather than not at all. ## Technical changes Two deliberate departures from the code that was deleted, both because this fork supports region threading and upstream did not. **Chunk coordinates are derived arithmetically.** Upstream's `restoreClaim` iterated `Claim#getChunks()`, which calls `world.getChunkAt(x, z)` and loads chunks on the calling thread — rejected under Folia and Canvas when that thread does not own the region. `restoreClaim` now walks `lesser.getBlockX() >> 4` to `greater.getBlockX() >> 4` directly and never touches a `Chunk` object. `restoreChunk(Chunk, ...)` is kept with upstream's signature for API compatibility and delegates to the coordinate-based path. **Block capture happens on the owning region thread.** Upstream scheduled the whole operation with `runTaskLaterAsynchronously` and read blocks from the async task. The work is now split: ```java SchedulerUtil.runAtLocationLater(this, snapshotOrigin, () -> { // snapshot 18x18 columns on the region thread SchedulerUtil.runAsyncNow(this, task); // analysis off-thread }, delayInTicks); ``` `RestoreNatureProcessingTask` already closes the loop itself, dispatching `RestoreNatureExecutionTask` back through `SchedulerUtil.runAtLocation` before it writes anything. This mirrors how the fork's existing `/restorenature` handler in `PlayerEventHandler` already worked, rather than introducing a second convention. Two smaller details: - The vertical window starts at `seaLevel - 15`, upstream's floor, so caves and mines under a claim are left alone. The fork's `RestoreNatureProcessingTask` treats its `miny` parameter as an array index rather than a world Y, so the snapshot array itself starts at that floor and `0` is passed in — the manual tool, which captures the full column, passes a world minimum that clamps to the same `0`. - The boundary corners describe the chunk proper, `+1` and `+16` off the snapshot origin, not the 18-wide array. The outer ring is reference data the execution task never writes to, and `cleanupEntities` uses those corners to decide which entities are in scope. ## Notes - Nothing happens until `Expiration.ChestClaimDays` or `Expiration.AllClaims.DaysInactive` is non-zero. Restoration is driven by expiry; with expiry disabled the flag has no effect. - Non-aggressive mode is what the automatic path uses, so `RestoreNatureExecutionTask` runs `getClaimAt` per block and skips anything still inside a claim. Neighbouring claims that share a chunk with a deleted one are safe. - Restoration operates per chunk, so it reaches the whole chunk rather than the claim footprint, and for a 3D claim it spans the full column above the floor rather than the claim's Y bounds. The per-block claim check above is what keeps that from mattering. - No data migration. No permission changes. No command changes. ## Tests No new tests. The full suite passes — **226 tests, 0 failures, 0 errors**. The restore path has no unit coverage and does not gain any here. It needs a live world to snapshot, a region scheduler to dispatch through, and real block writes to assert against; the mock harness provides none of the three. What was verified statically: `Claim#getArea`, `getWidth` and `getHeight` were traced through `ClaimBounds` to confirm the upstream size thresholds still describe a 2D footprint in this fork; `miny` was traced through every use in `RestoreNatureProcessingTask` to confirm it is an array index and unused in `RestoreNatureExecutionTask`; and both edited message files were parsed to confirm the apostrophes in the restored string do not break YAML. ## Files Changed ``` M gradle.properties M pom.xml M src/main/java/com/griefprevention/commands/UnifiedAdminClaimCommand.java M src/main/java/me/ryanhamshire/GriefPrevention/Claim.java M src/main/java/me/ryanhamshire/GriefPrevention/CleanupUnusedClaimTask.java M src/main/java/me/ryanhamshire/GriefPrevention/GriefPrevention.java M src/main/java/me/ryanhamshire/GriefPrevention/Messages.java M src/main/resources/messages.yml M src/main/resources/messages_cs_CZ.yml M src/main/resources/messages_de_DE.yml M src/main/resources/messages_en.yml M src/main/resources/messages_en_PT.yml M src/main/resources/messages_es.yml M src/main/resources/messages_fr_FR.yml M src/main/resources/messages_ja_JP.yml M src/main/resources/messages_ms_MY.yml M src/main/resources/messages_pl_PL.yml M src/main/resources/messages_pt_BR.yml M src/main/resources/messages_ru_RU.yml M src/main/resources/messages_tr_TR.yml M src/main/resources/messages_uk_UA.yml M src/main/resources/messages_zh_CN.yml ```

# GriefPrevention3D v18.2.19 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## Fixes ### Sulfur cube buckets placed a mob inside anyone's claim A player holding a `SULFUR_CUBE_BUCKET` could empty it anywhere, including inside a claim they had no trust in. No message, no cancellation — the cube simply appeared. The cause is a quirk of how Mojang built the item. Every other mob bucket carries water: ```java // Items, Minecraft 26.2 public static final Item AXOLOTL_BUCKET = registerItem(..., p -> new MobBucketItem(EntityTypes.AXOLOTL, Fluids.WATER, SoundEvents.BUCKET_EMPTY_AXOLOTL, p), ...); public static final Item SULFUR_CUBE_BUCKET = registerItem(..., p -> new MobBucketItem(EntityTypes.SULFUR_CUBE, Fluids.EMPTY, SoundEvents.BUCKET_EMPTY_SULFUR_CUBE, p), ...); ``` A sulfur cube is a land mob, so its bucket is built with `Fluids.EMPTY`. `MobBucketItem` special cases exactly that: ```java @Override public boolean emptyContents(LivingEntity user, Level level, BlockPos pos, BlockHitResult hitResult, Direction direction, BlockPos clicked, ItemStack itemStack, InteractionHand hand) { if (this.content == Fluids.EMPTY) { this.playEmptySound(user, level, pos); return true; // never calls super } return super.emptyContents(user, level, pos, hitResult, direction, clicked, itemStack, hand); } ``` `BucketItem.emptyContents` is the **only** place `CraftEventFactory.callPlayerBucketEmptyEvent` is called. Returning early skips it, and `BucketItem.use` then proceeds to `checkExtraContent` → `MobBucketItem.spawn` → `level.addFreshEntityWithPassengers(mob, SpawnReason.BUCKET)`. So **no `PlayerBucketEmptyEvent` is fired at all** for sulfur cube buckets. GriefPrevention's `onPlayerBucketEmpty` — which has correctly guarded water, lava and every fish bucket for years — was never invoked. There was no event to cancel. **Fix:** check `PlayerInteractEvent` instead, which every mob bucket passes through regardless of what fluid it carries. `ServerPlayerGameMode.useItemOn` records the cancellation: ```java this.interactResult = event.useItemInHand() == Event.Result.DENY; ``` and `ServerGamePacketListenerImpl.handleUseItem` reuses that result for the follow-up `ServerboundUseItemPacket` when the position, hand and stack still match — returning before `useItem`, so `BucketItem.use` never runs. Two details of the implementation matter: - **The check runs ahead of the block-type branches** in `onPlayerInteract`. Shift-right-clicking sets `suppressUsingBlock` in `useItemOn`, which skips block use and empties the bucket instead. A player with container trust but not build trust could otherwise have placed a cube by shift-clicking a chest, because that click is claimed by the container branch first. - **Permission is checked at the block adjacent to the clicked face**, not the clicked block. For an empty-fluid bucket `placePos` is always `directionOffsetPos`, which is where the mob actually spawns. This is the same relative-block rule `onPlayerBucketEmpty` already applies, and it is what makes the check correct against 3D subdivisions rather than only horizontally. The material set is derived by name — anything ending `_BUCKET`, minus the empty bucket, water, lava, milk, powder snow and the `LEGACY_` aliases. On 26.2 that resolves to exactly the seven mob buckets (cod, salmon, pufferfish, tropical fish, axolotl, tadpole, sulfur cube), it is empty on older versions where those materials do not exist, and future mob buckets are picked up with no code change. The water-carrying buckets now have two layers of protection; the fluid-less one has its first. Dispensers were already covered and are unchanged. `SULFUR_CUBE_BUCKET` is registered with the standard `filledBucketBehavior`, and `BlockEventHandler.onDispense` already cancels any dispense that crosses a claim boundary in either direction. ### The punch freeze threw on every swing under region threading `SulfurCubeHandler` undoes an unauthorized push by teleporting the cube back to where it started on the next tick. That teleport used `Entity#teleport`, which Folia and Canvas reject: ``` java.lang.UnsupportedOperationException: Must use teleportAsync while in region threading at org.bukkit.craftbukkit.entity.CraftEntity.teleport0(CraftEntity.java:321) at GriefPrevention3D.jar/me.ryanhamshire.GriefPrevention.SulfurCubeHandler.lambda$onPlayerSwing$0(SulfurCubeHandler.java:60) ``` The entity task was already being scheduled correctly through `SchedulerUtil.runLaterEntity`; the teleport call inside it was the problem. Note where in the sequence this landed: the exception was thrown *after* the permission check had already failed, so the cube was never moved back and `setVelocity` never ran. On a region-threaded server the push protection did nothing at all except fill the console — one stack trace per denied swing. **Fix:** teleports go through a new `CompatUtil.teleportSafely(Entity, Location)`, which resolves `teleportAsync` once via reflection and falls back to the blocking call where it does not exist (Spigot, pre-1.19 Paper). `PlayerEventHandler.teleportFoliaSafe` — a near-identical private copy that only handled `Player` — now delegates to it rather than a second copy being added. ## Notes - No configuration changes, no data migration, no message changes. - Denied bucket placements use the existing no-build message and the existing rate limiter, so a player spamming right-click gets one message rather than a stream. - This affects Minecraft 26.2 and newer, where the sulfur cube and its bucket exist. On older versions the material set is empty and the interact check is a no-op. - The bucket bypass has existed since sulfur cube protection was added in v18.1.4. That release covered the punch and right-click paths but not placement, because the bucket was reasonably assumed to behave like the axolotl bucket, which `onPlayerBucketEmpty` already handled. - Upstream GriefPrevention is affected identically — it guards buckets solely through `PlayerBucketEmptyEvent`, and the sulfur cube bucket never fires it. ## Tests No new tests. The full suite passes — **226 tests, 0 failures, 0 errors**. Neither fix has unit coverage. Both need a live `PlayerInteractEvent` against a real block, and the teleport path additionally needs a region-threaded server to reproduce at all; the mock harness can construct neither. The item construction and event paths were verified by decompiling the shipped server jar rather than inferred: ``` $ cfr canvas-26.2.jar net/minecraft/world/item/Items.class | grep SULFUR_CUBE_BUCKET public static final Item SULFUR_CUBE_BUCKET = Items.registerItem(ItemIds.SULFUR_CUBE_BUCKET, (Item.Properties p) -> new MobBucketItem(EntityTypes.SULFUR_CUBE, Fluids.EMPTY, SoundEvents.BUCKET_EMPTY_SULFUR_CUBE, p), ...); ``` `MobBucketItem.emptyContents`, `BucketItem.emptyContents`, `ServerPlayerGameMode.useItemOn` and `ServerGamePacketListenerImpl.handleUseItem` were each read from the same jar to confirm that no bucket-empty event is fired and that cancelling the interact event does suppress the item use. ## Files Changed ``` M gradle.properties M pom.xml M src/main/java/me/ryanhamshire/GriefPrevention/PlayerEventHandler.java M src/main/java/me/ryanhamshire/GriefPrevention/SulfurCubeHandler.java M src/main/java/me/ryanhamshire/GriefPrevention/compat/CompatUtil.java ```

# GriefPrevention3D v18.2.19 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## Fixes ### Sulfur cube buckets placed a mob inside anyone's claim A player holding a `SULFUR_CUBE_BUCKET` could empty it anywhere, including inside a claim they had no trust in. No message, no cancellation — the cube simply appeared. The cause is a quirk of how Mojang built the item. Every other mob bucket carries water: ```java // Items, Minecraft 26.2 public static final Item AXOLOTL_BUCKET = registerItem(..., p -> new MobBucketItem(EntityTypes.AXOLOTL, Fluids.WATER, SoundEvents.BUCKET_EMPTY_AXOLOTL, p), ...); public static final Item SULFUR_CUBE_BUCKET = registerItem(..., p -> new MobBucketItem(EntityTypes.SULFUR_CUBE, Fluids.EMPTY, SoundEvents.BUCKET_EMPTY_SULFUR_CUBE, p), ...); ``` A sulfur cube is a land mob, so its bucket is built with `Fluids.EMPTY`. `MobBucketItem` special cases exactly that: ```java @Override public boolean emptyContents(LivingEntity user, Level level, BlockPos pos, BlockHitResult hitResult, Direction direction, BlockPos clicked, ItemStack itemStack, InteractionHand hand) { if (this.content == Fluids.EMPTY) { this.playEmptySound(user, level, pos); return true; // never calls super } return super.emptyContents(user, level, pos, hitResult, direction, clicked, itemStack, hand); } ``` `BucketItem.emptyContents` is the **only** place `CraftEventFactory.callPlayerBucketEmptyEvent` is called. Returning early skips it, and `BucketItem.use` then proceeds to `checkExtraContent` → `MobBucketItem.spawn` → `level.addFreshEntityWithPassengers(mob, SpawnReason.BUCKET)`. So **no `PlayerBucketEmptyEvent` is fired at all** for sulfur cube buckets. GriefPrevention's `onPlayerBucketEmpty` — which has correctly guarded water, lava and every fish bucket for years — was never invoked. There was no event to cancel. **Fix:** check `PlayerInteractEvent` instead, which every mob bucket passes through regardless of what fluid it carries. `ServerPlayerGameMode.useItemOn` records the cancellation: ```java this.interactResult = event.useItemInHand() == Event.Result.DENY; ``` and `ServerGamePacketListenerImpl.handleUseItem` reuses that result for the follow-up `ServerboundUseItemPacket` when the position, hand and stack still match — returning before `useItem`, so `BucketItem.use` never runs. Two details of the implementation matter: - **The check runs ahead of the block-type branches** in `onPlayerInteract`. Shift-right-clicking sets `suppressUsingBlock` in `useItemOn`, which skips block use and empties the bucket instead. A player with container trust but not build trust could otherwise have placed a cube by shift-clicking a chest, because that click is claimed by the container branch first. - **Permission is checked at the block adjacent to the clicked face**, not the clicked block. For an empty-fluid bucket `placePos` is always `directionOffsetPos`, which is where the mob actually spawns. This is the same relative-block rule `onPlayerBucketEmpty` already applies, and it is what makes the check correct against 3D subdivisions rather than only horizontally. The material set is derived by name — anything ending `_BUCKET`, minus the empty bucket, water, lava, milk, powder snow and the `LEGACY_` aliases. On 26.2 that resolves to exactly the seven mob buckets (cod, salmon, pufferfish, tropical fish, axolotl, tadpole, sulfur cube), it is empty on older versions where those materials do not exist, and future mob buckets are picked up with no code change. The water-carrying buckets now have two layers of protection; the fluid-less one has its first. Dispensers were already covered and are unchanged. `SULFUR_CUBE_BUCKET` is registered with the standard `filledBucketBehavior`, and `BlockEventHandler.onDispense` already cancels any dispense that crosses a claim boundary in either direction. ### The punch freeze threw on every swing under region threading `SulfurCubeHandler` undoes an unauthorized push by teleporting the cube back to where it started on the next tick. That teleport used `Entity#teleport`, which Folia and Canvas reject: ``` java.lang.UnsupportedOperationException: Must use teleportAsync while in region threading at org.bukkit.craftbukkit.entity.CraftEntity.teleport0(CraftEntity.java:321) at GriefPrevention3D.jar/me.ryanhamshire.GriefPrevention.SulfurCubeHandler.lambda$onPlayerSwing$0(SulfurCubeHandler.java:60) ``` The entity task was already being scheduled correctly through `SchedulerUtil.runLaterEntity`; the teleport call inside it was the problem. Note where in the sequence this landed: the exception was thrown *after* the permission check had already failed, so the cube was never moved back and `setVelocity` never ran. On a region-threaded server the push protection did nothing at all except fill the console — one stack trace per denied swing. **Fix:** teleports go through a new `CompatUtil.teleportSafely(Entity, Location)`, which resolves `teleportAsync` once via reflection and falls back to the blocking call where it does not exist (Spigot, pre-1.19 Paper). `PlayerEventHandler.teleportFoliaSafe` — a near-identical private copy that only handled `Player` — now delegates to it rather than a second copy being added. ## Notes - No configuration changes, no data migration, no message changes. - Denied bucket placements use the existing no-build message and the existing rate limiter, so a player spamming right-click gets one message rather than a stream. - This affects Minecraft 26.2 and newer, where the sulfur cube and its bucket exist. On older versions the material set is empty and the interact check is a no-op. - The bucket bypass has existed since sulfur cube protection was added in v18.1.4. That release covered the punch and right-click paths but not placement, because the bucket was reasonably assumed to behave like the axolotl bucket, which `onPlayerBucketEmpty` already handled. - Upstream GriefPrevention is affected identically — it guards buckets solely through `PlayerBucketEmptyEvent`, and the sulfur cube bucket never fires it. ## Tests No new tests. The full suite passes — **226 tests, 0 failures, 0 errors**. Neither fix has unit coverage. Both need a live `PlayerInteractEvent` against a real block, and the teleport path additionally needs a region-threaded server to reproduce at all; the mock harness can construct neither. The item construction and event paths were verified by decompiling the shipped server jar rather than inferred: ``` $ cfr canvas-26.2.jar net/minecraft/world/item/Items.class | grep SULFUR_CUBE_BUCKET public static final Item SULFUR_CUBE_BUCKET = Items.registerItem(ItemIds.SULFUR_CUBE_BUCKET, (Item.Properties p) -> new MobBucketItem(EntityTypes.SULFUR_CUBE, Fluids.EMPTY, SoundEvents.BUCKET_EMPTY_SULFUR_CUBE, p), ...); ``` `MobBucketItem.emptyContents`, `BucketItem.emptyContents`, `ServerPlayerGameMode.useItemOn` and `ServerGamePacketListenerImpl.handleUseItem` were each read from the same jar to confirm that no bucket-empty event is fired and that cancelling the interact event does suppress the item use. ## Files Changed ``` M gradle.properties M pom.xml M src/main/java/me/ryanhamshire/GriefPrevention/PlayerEventHandler.java M src/main/java/me/ryanhamshire/GriefPrevention/SulfurCubeHandler.java M src/main/java/me/ryanhamshire/GriefPrevention/compat/CompatUtil.java ```

# GriefPrevention3D v18.2.18 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## Fixes ### Block explosions were cancelled entirely inside claims, suppressing knockback and every other effect `BlockExplodeEventHandler` cancelled the whole `BlockExplodeEvent` as soon as any affected block was inside a claim: ```java Claim claim = this.dataStore.getClaimAt(block.getLocation(), false, null); if (claim != null) { explodeEvent.setCancelled(true); return; } ``` Cancelling that event does not merely spare the blocks — it suppresses the entire explosion, including the knockback the server delivers to players. Every non-block effect of a block explosion inside a claim has been silently dropped for as long as this class has existed. The most visible symptom was the mace's **Wind Burst** enchantment: smashing a player inside a claim produced particles, damage, and negated fall damage, but never launched the attacker. The knockback event itself was completely healthy — it reached `MONITOR` priority uncancelled, with a full `(0, 2.2, 0)` vector, and the velocity really was applied to the attacker server-side. What never happened was the packet that carries that motion to the client, because the explosion it belonged to had been cancelled. The server believed the player was flying while their client kept falling. Two settings that should have governed this were never consulted by the class at all, which is why neither provided a workaround: - `GriefPrevention.BlockLandClaimExplosions` — `config_blockClaimExplosions` was never read - `/claimexplosions` — `claim.areExplosivesAllowed` was never read `BlockSurfaceCreeperExplosions` and `BlockSurfaceOtherExplosions` were equally irrelevant here. The only configuration that avoided the bug was disabling claims for the whole world. **Fix:** both branches now strip protected blocks from the explosion instead of cancelling it, matching what `EntityEventHandler` has always done for entity-caused explosions: - `handleExplosion` filters into an allowed-blocks list and honours `config_blockClaimExplosions` and `claim.areExplosivesAllowed`, so **`/claimexplosions` works on this path for the first time** - `handleExplodeInteract` collects protected blocks and calls `blocks.removeAll(removed)`, and now updates `playerData.lastClaim` like its entity-side counterpart - Both use the cached-claim lookup instead of passing `null` on every iteration Block protection is unchanged: claimed blocks still do not break. Everything else the explosion does — knockback, damage, block triggering — now survives. This class is GP3D-only. It was split out of `EntityEventHandler` for 1.8.8 compatibility and the split copy was rewritten to cancel rather than filter. Upstream GriefPrevention routes `BlockExplodeEvent` through the same shared `handleExplosion` / `handleExplodeInteract` methods as entity explosions and is not affected. ### The investigation tool could not be placed on a shelf [#10](https://github.com/castledking/GriefPrevention3D/issues/10) — right-clicking a shelf while holding the investigation tool (a stick by default) ran claim investigation instead of storing the item, so the tool could never be placed on a shelf. Item frames were unaffected because they are entities and never reach this handler. Shelves are `BlockInventoryHolder`s, so the interaction reached the container branch of `PlayerEventHandler.onPlayerInteract`, which hands off to the claim tool dispatcher whenever the player is holding the investigation or modification tool. The dispatcher consumed the click. **Fix:** the claim tools no longer intercept right-clicks on shelf blocks, at both dispatcher call sites. Shelves stay protected exactly as before — they are inventory holders, so the container trust check still applies and untrusted players still cannot store or retrieve items in a claim. This only decides whether the claim tools consume the interaction first. Shelves are matched by name (`_SHELF` suffix, which excludes `BOOKSHELF` and `CHISELED_BOOKSHELF`) so the plugin still compiles and runs on versions predating them, and so future wood variants are covered automatically. ### Duplicate wind-charge knockback handlers were registered alongside the platform handlers `PaperKnockbackHandler` and `SpigotKnockbackHandler` were GP3D-only classes added here on 2025-12-29 (`cab3d9cf`). Upstream solved the same problem independently on 2026-01-26 with [GriefPrevention#2549](https://github.com/GriefPrevention/GriefPrevention/pull/2549), which introduced `com.griefprevention.platform.knockback`. That package arrived via the upstream merge in `b084c943`, but the older classes were never removed — so two independent listeners inspected and could cancel the same knockback event. The Paper one was the worse of the two. Its wind-charge test was: ```java boolean isWindChargeKnockback = causeName.equals("EXPLOSION") && source instanceof Player; ``` which matches any player-sourced explosion knockback, including the mace smash AoE. Both classes are removed; `KnockbackProtectionListener` and its Paper/Spigot handlers are now the only knockback protection path. ### Paper's knockback handler processed the same event twice On Paper, `com.destroystokyo.paper.event.entity.EntityKnockbackByEntityEvent` extends `io.papermc.paper.event.entity.EntityPushedByEntityAttackEvent`, and only the base `io.papermc.paper.event.entity.EntityKnockbackEvent` declares a `HandlerList` — so all three event types share one handler list and both `@EventHandler` methods on `PaperKnockbackProtectionHandler` ran for every `EntityKnockbackByEntityEvent`. That meant duplicate claim lookups and permission checks on every melee hit, and a duplicate `PreventPvPEvent` whenever the first pass did not cancel. `onEntityPushedByEntityAttack` now skips events that are `EntityKnockbackByEntityEvent`. This defect is inherited from upstream, not introduced here — our copy differs from #2549 only in Java 8 desugaring. It has been submitted upstream separately. ## Features ### Knockback tracing under `/gpdebug` Knockback protection now logs its decisions through the existing debug channel. Enable with `/gpdebug on` (permission `griefprevention.debug`); entries are prefixed `[GP Debug] [knockback]` and are suppressed entirely while debug logging is off, including the claim lookups they would otherwise perform. ``` [GP Debug] [knockback] EntityKnockbackByEntityEvent cause=ENTITY_ATTACK entity=Player(bob) hitBy=Player(alice) [GP Debug] [knockback] allow: attacker alice has Access trust in defender's claim 2 [GP Debug] [knockback] [in ] EntityKnockbackEvent cause=EXPLOSION entity=Player(alice) standingIn=claim 2 cancelled=false knockback=0.0,2.2,0.0 [GP Debug] [knockback] [out] EntityKnockbackEvent cause=EXPLOSION entity=Player(alice) standingIn=claim 2 cancelled=false knockback=0.0,2.2,0.0 ``` Traced branches: self-knockback, `ignoreClaims`, Access trust in the defender's claim, GP PvP rules disabled for the world, fresh-spawn immunity, defender in a PvP-safe claim, attacker in a PvP-safe claim, another plugin cancelling `PreventPvPEvent`, and "no GP rule matched". Events GP declines to act on are logged as `ignored:` with the reason. On Paper, the `[in ]` / `[out]` pair additionally traces the base `EntityKnockbackEvent` — which GP does not otherwise subscribe to, and which is how explosion knockback with no source entity arrives — at `LOWEST` on arrival and again at `MONITOR` after every other plugin has run. A knockback that is cancelled or zeroed in between is visible, along with the claim the affected player is standing in. It never modifies the event. This is what isolated the explosion bug above: it proved the knockback event was pristine, which ruled out the entire knockback path and redirected the search to explosion handling. ### Platform listener registration is logged `PlatformListener.register()` now records which handler it registered and on what: ``` [GP Debug] Registered PaperKnockbackProtectionHandler on Paper 26.2 (detected platform: PAPER). ``` Listeners that report themselves unsupported now say so instead of failing silently. ## Notes - No configuration changes, no data migration, no message changes. - `GriefPrevention.BlockLandClaimExplosions` and `/claimexplosions` now take effect for block explosions. Servers that had set either expecting explosions to be permitted in claims will see that setting honoured for the first time — the previous behaviour blocked such explosions regardless. - **Known fragility, not changed this release.** `KnockbackProtectionListener.isSupported()` gates the whole Paper path on `com.destroystokyo.paper.event.entity.EntityKnockbackByEntityEvent` being present; if it ever goes away, `isSupported()` returns `false` and no knockback protection registers on Paper at all, silently. In paper-api 26.2 that class is `@ApiStatus.Obsolete`, not `@Deprecated(forRemoval = true)`, so removal is not currently scheduled. Upstream shares the gate; GP3D additionally requires `io.papermc.paper.event.entity.EntityPushedByEntityAttackEvent`. - **Do not "modernize" onto the Bukkit knockback events on Paper.** In paper-api 26.2 both `org.bukkit.event.entity.EntityKnockbackEvent` and `EntityKnockbackByEntityEvent` carry class-level `@Deprecated(forRemoval = true)`, while Paper's `io.papermc.paper.event.entity.EntityKnockbackEvent` carries no deprecation. In spigot-api 26.2 the same two Bukkit classes carry no class-level annotations and are the current API. The platforms point in opposite directions, which is why the platform split from #2549 is the right shape. - [PaperMC/Paper#13079](https://github.com/PaperMC/Paper/issues/13079) — cancelling `EntityPushedByEntityAttackEvent` does not stop Wind Burst knockback — remains open and limits what GP can protect against. It is unrelated to the bug fixed above, and the two are easy to conflate: #13079 is knockback happening when a plugin tries to block it, this release fixed knockback *not* happening when nothing was trying to block it. ## Tests No new tests. The full suite passes — **224 tests, 0 failures, 0 errors**. The shelf fix has no unit coverage either: `onPlayerInteract` needs a live `PlayerInteractEvent` against a real shelf `BlockState`, which the mock harness cannot construct. It was verified in-game on Paper 26.2 — investigation tool onto a shelf inside a claim, with and without container trust. The explosion fix has no unit coverage because `BlockExplodeEventHandler` needs a live `BlockExplodeEvent` with a populated block list and a `DataStore` with real claims; the current mock harness has no fixture for either. It was verified in-game on Paper 26.2: mace smash with Wind Burst inside a claim, before and after, with the claim abandoned and recreated at identical coordinates as a control. The Paper event hierarchy claim behind the double-dispatch fix was verified against the shipped API jar: ``` $ javap -cp paper-api-26.2.jar com.destroystokyo.paper.event.entity.EntityKnockbackByEntityEvent public class com.destroystokyo.paper.event.entity.EntityKnockbackByEntityEvent extends io.papermc.paper.event.entity.EntityPushedByEntityAttackEvent ``` ## Files Changed ``` M gradle.properties M pom.xml M src/main/java/com/griefprevention/platform/PlatformListener.java M src/main/java/com/griefprevention/platform/knockback/KnockbackProtectionHandler.java M src/main/java/com/griefprevention/platform/knockback/PaperKnockbackProtectionHandler.java M src/main/java/com/griefprevention/platform/knockback/SpigotKnockbackProtectionHandler.java M src/main/java/me/ryanhamshire/GriefPrevention/BlockExplodeEventHandler.java M src/main/java/me/ryanhamshire/GriefPrevention/EntityDamageHandler.java M src/main/java/me/ryanhamshire/GriefPrevention/GriefPrevention.java M src/main/java/me/ryanhamshire/GriefPrevention/PlayerEventHandler.java D src/main/java/me/ryanhamshire/GriefPrevention/PaperKnockbackHandler.java D src/main/java/me/ryanhamshire/GriefPrevention/SpigotKnockbackHandler.java ```

# GriefPrevention3D v18.2.18 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## Fixes ### Block explosions were cancelled entirely inside claims, suppressing knockback and every other effect `BlockExplodeEventHandler` cancelled the whole `BlockExplodeEvent` as soon as any affected block was inside a claim: ```java Claim claim = this.dataStore.getClaimAt(block.getLocation(), false, null); if (claim != null) { explodeEvent.setCancelled(true); return; } ``` Cancelling that event does not merely spare the blocks — it suppresses the entire explosion, including the knockback the server delivers to players. Every non-block effect of a block explosion inside a claim has been silently dropped for as long as this class has existed. The most visible symptom was the mace's **Wind Burst** enchantment: smashing a player inside a claim produced particles, damage, and negated fall damage, but never launched the attacker. The knockback event itself was completely healthy — it reached `MONITOR` priority uncancelled, with a full `(0, 2.2, 0)` vector, and the velocity really was applied to the attacker server-side. What never happened was the packet that carries that motion to the client, because the explosion it belonged to had been cancelled. The server believed the player was flying while their client kept falling. Two settings that should have governed this were never consulted by the class at all, which is why neither provided a workaround: - `GriefPrevention.BlockLandClaimExplosions` — `config_blockClaimExplosions` was never read - `/claimexplosions` — `claim.areExplosivesAllowed` was never read `BlockSurfaceCreeperExplosions` and `BlockSurfaceOtherExplosions` were equally irrelevant here. The only configuration that avoided the bug was disabling claims for the whole world. **Fix:** both branches now strip protected blocks from the explosion instead of cancelling it, matching what `EntityEventHandler` has always done for entity-caused explosions: - `handleExplosion` filters into an allowed-blocks list and honours `config_blockClaimExplosions` and `claim.areExplosivesAllowed`, so **`/claimexplosions` works on this path for the first time** - `handleExplodeInteract` collects protected blocks and calls `blocks.removeAll(removed)`, and now updates `playerData.lastClaim` like its entity-side counterpart - Both use the cached-claim lookup instead of passing `null` on every iteration Block protection is unchanged: claimed blocks still do not break. Everything else the explosion does — knockback, damage, block triggering — now survives. This class is GP3D-only. It was split out of `EntityEventHandler` for 1.8.8 compatibility and the split copy was rewritten to cancel rather than filter. Upstream GriefPrevention routes `BlockExplodeEvent` through the same shared `handleExplosion` / `handleExplodeInteract` methods as entity explosions and is not affected. ### The investigation tool could not be placed on a shelf [#10](https://github.com/castledking/GriefPrevention3D/issues/10) — right-clicking a shelf while holding the investigation tool (a stick by default) ran claim investigation instead of storing the item, so the tool could never be placed on a shelf. Item frames were unaffected because they are entities and never reach this handler. Shelves are `BlockInventoryHolder`s, so the interaction reached the container branch of `PlayerEventHandler.onPlayerInteract`, which hands off to the claim tool dispatcher whenever the player is holding the investigation or modification tool. The dispatcher consumed the click. **Fix:** the claim tools no longer intercept right-clicks on shelf blocks, at both dispatcher call sites. Shelves stay protected exactly as before — they are inventory holders, so the container trust check still applies and untrusted players still cannot store or retrieve items in a claim. This only decides whether the claim tools consume the interaction first. Shelves are matched by name (`_SHELF` suffix, which excludes `BOOKSHELF` and `CHISELED_BOOKSHELF`) so the plugin still compiles and runs on versions predating them, and so future wood variants are covered automatically. ### Duplicate wind-charge knockback handlers were registered alongside the platform handlers `PaperKnockbackHandler` and `SpigotKnockbackHandler` were GP3D-only classes added here on 2025-12-29 (`cab3d9cf`). Upstream solved the same problem independently on 2026-01-26 with [GriefPrevention#2549](https://github.com/GriefPrevention/GriefPrevention/pull/2549), which introduced `com.griefprevention.platform.knockback`. That package arrived via the upstream merge in `b084c943`, but the older classes were never removed — so two independent listeners inspected and could cancel the same knockback event. The Paper one was the worse of the two. Its wind-charge test was: ```java boolean isWindChargeKnockback = causeName.equals("EXPLOSION") && source instanceof Player; ``` which matches any player-sourced explosion knockback, including the mace smash AoE. Both classes are removed; `KnockbackProtectionListener` and its Paper/Spigot handlers are now the only knockback protection path. ### Paper's knockback handler processed the same event twice On Paper, `com.destroystokyo.paper.event.entity.EntityKnockbackByEntityEvent` extends `io.papermc.paper.event.entity.EntityPushedByEntityAttackEvent`, and only the base `io.papermc.paper.event.entity.EntityKnockbackEvent` declares a `HandlerList` — so all three event types share one handler list and both `@EventHandler` methods on `PaperKnockbackProtectionHandler` ran for every `EntityKnockbackByEntityEvent`. That meant duplicate claim lookups and permission checks on every melee hit, and a duplicate `PreventPvPEvent` whenever the first pass did not cancel. `onEntityPushedByEntityAttack` now skips events that are `EntityKnockbackByEntityEvent`. This defect is inherited from upstream, not introduced here — our copy differs from #2549 only in Java 8 desugaring. It has been submitted upstream separately. ## Features ### Knockback tracing under `/gpdebug` Knockback protection now logs its decisions through the existing debug channel. Enable with `/gpdebug on` (permission `griefprevention.debug`); entries are prefixed `[GP Debug] [knockback]` and are suppressed entirely while debug logging is off, including the claim lookups they would otherwise perform. ``` [GP Debug] [knockback] EntityKnockbackByEntityEvent cause=ENTITY_ATTACK entity=Player(bob) hitBy=Player(alice) [GP Debug] [knockback] allow: attacker alice has Access trust in defender's claim 2 [GP Debug] [knockback] [in ] EntityKnockbackEvent cause=EXPLOSION entity=Player(alice) standingIn=claim 2 cancelled=false knockback=0.0,2.2,0.0 [GP Debug] [knockback] [out] EntityKnockbackEvent cause=EXPLOSION entity=Player(alice) standingIn=claim 2 cancelled=false knockback=0.0,2.2,0.0 ``` Traced branches: self-knockback, `ignoreClaims`, Access trust in the defender's claim, GP PvP rules disabled for the world, fresh-spawn immunity, defender in a PvP-safe claim, attacker in a PvP-safe claim, another plugin cancelling `PreventPvPEvent`, and "no GP rule matched". Events GP declines to act on are logged as `ignored:` with the reason. On Paper, the `[in ]` / `[out]` pair additionally traces the base `EntityKnockbackEvent` — which GP does not otherwise subscribe to, and which is how explosion knockback with no source entity arrives — at `LOWEST` on arrival and again at `MONITOR` after every other plugin has run. A knockback that is cancelled or zeroed in between is visible, along with the claim the affected player is standing in. It never modifies the event. This is what isolated the explosion bug above: it proved the knockback event was pristine, which ruled out the entire knockback path and redirected the search to explosion handling. ### Platform listener registration is logged `PlatformListener.register()` now records which handler it registered and on what: ``` [GP Debug] Registered PaperKnockbackProtectionHandler on Paper 26.2 (detected platform: PAPER). ``` Listeners that report themselves unsupported now say so instead of failing silently. ## Notes - No configuration changes, no data migration, no message changes. - `GriefPrevention.BlockLandClaimExplosions` and `/claimexplosions` now take effect for block explosions. Servers that had set either expecting explosions to be permitted in claims will see that setting honoured for the first time — the previous behaviour blocked such explosions regardless. - **Known fragility, not changed this release.** `KnockbackProtectionListener.isSupported()` gates the whole Paper path on `com.destroystokyo.paper.event.entity.EntityKnockbackByEntityEvent` being present; if it ever goes away, `isSupported()` returns `false` and no knockback protection registers on Paper at all, silently. In paper-api 26.2 that class is `@ApiStatus.Obsolete`, not `@Deprecated(forRemoval = true)`, so removal is not currently scheduled. Upstream shares the gate; GP3D additionally requires `io.papermc.paper.event.entity.EntityPushedByEntityAttackEvent`. - **Do not "modernize" onto the Bukkit knockback events on Paper.** In paper-api 26.2 both `org.bukkit.event.entity.EntityKnockbackEvent` and `EntityKnockbackByEntityEvent` carry class-level `@Deprecated(forRemoval = true)`, while Paper's `io.papermc.paper.event.entity.EntityKnockbackEvent` carries no deprecation. In spigot-api 26.2 the same two Bukkit classes carry no class-level annotations and are the current API. The platforms point in opposite directions, which is why the platform split from #2549 is the right shape. - [PaperMC/Paper#13079](https://github.com/PaperMC/Paper/issues/13079) — cancelling `EntityPushedByEntityAttackEvent` does not stop Wind Burst knockback — remains open and limits what GP can protect against. It is unrelated to the bug fixed above, and the two are easy to conflate: #13079 is knockback happening when a plugin tries to block it, this release fixed knockback *not* happening when nothing was trying to block it. ## Tests No new tests. The full suite passes — **224 tests, 0 failures, 0 errors**. The shelf fix has no unit coverage either: `onPlayerInteract` needs a live `PlayerInteractEvent` against a real shelf `BlockState`, which the mock harness cannot construct. It was verified in-game on Paper 26.2 — investigation tool onto a shelf inside a claim, with and without container trust. The explosion fix has no unit coverage because `BlockExplodeEventHandler` needs a live `BlockExplodeEvent` with a populated block list and a `DataStore` with real claims; the current mock harness has no fixture for either. It was verified in-game on Paper 26.2: mace smash with Wind Burst inside a claim, before and after, with the claim abandoned and recreated at identical coordinates as a control. The Paper event hierarchy claim behind the double-dispatch fix was verified against the shipped API jar: ``` $ javap -cp paper-api-26.2.jar com.destroystokyo.paper.event.entity.EntityKnockbackByEntityEvent public class com.destroystokyo.paper.event.entity.EntityKnockbackByEntityEvent extends io.papermc.paper.event.entity.EntityPushedByEntityAttackEvent ``` ## Files Changed ``` M gradle.properties M pom.xml M src/main/java/com/griefprevention/platform/PlatformListener.java M src/main/java/com/griefprevention/platform/knockback/KnockbackProtectionHandler.java M src/main/java/com/griefprevention/platform/knockback/PaperKnockbackProtectionHandler.java M src/main/java/com/griefprevention/platform/knockback/SpigotKnockbackProtectionHandler.java M src/main/java/me/ryanhamshire/GriefPrevention/BlockExplodeEventHandler.java M src/main/java/me/ryanhamshire/GriefPrevention/EntityDamageHandler.java M src/main/java/me/ryanhamshire/GriefPrevention/GriefPrevention.java M src/main/java/me/ryanhamshire/GriefPrevention/PlayerEventHandler.java D src/main/java/me/ryanhamshire/GriefPrevention/PaperKnockbackHandler.java D src/main/java/me/ryanhamshire/GriefPrevention/SpigotKnockbackHandler.java ```

# GriefPrevention3D v18.2.17 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## Features ### Shaped 2D subdivisions Subdivisions can now be drawn as free-form orthogonal polygons inside a claim, matching the shaped-claims tooling but scoped to a parent claim. Run `/shapedsubdivideclaims` (aliases: `shapedsubdivideclaim`, `ssc`, `shapedsubdivide`) or `/claim mode shapedsubdivide` to enter the mode: - Right-click inside one of your claims to place corners, then click your first corner again to close the subdivision. - Click an existing shaped subdivision's boundary to enter a reshape session for it. - A shaped subdivision must stay inside the claim it subdivides. - Shaped subdivisions work inside top-level 2D claims only; a 3D claim cannot be subdivided with this mode, and a shaped subdivision spans the same vertical range as its parent claim. The mode is gated by a new `GriefPrevention.Claims.AllowShapedSubClaims` setting, which defaults to `false`. Both `/shapedsubdivideclaims` and `/claim mode shapedsubdivide` refuse to enter the mode while it is disabled. Overlap checks between a shaped polygon and other claims are now column-exact: a 3D claim sitting only inside the shaped claim's rectangular bounding box but over a cavity (a concave notch the polygon does not actually cover) is no longer treated as an overlap, while Y separation between claims is still respected. ### Admin-controlled subdivisions Staff can flag an individual subdivision as administered by the server, taking its editing and trust management away from the claim owner. Use `/aclaim makeadmin` and `/aclaim makebasic` (or the standalone `/makeadmin` and `/makebasic`) on a subdivision. Staff need `griefprevention.adminclaims.convert`. The subdivision has to be selected first by right-clicking one of its corners with the golden shovel; running the command without a selection tells you to select one and run it again. Once a subdivision is administrative: - The claim owner loses **Edit** and **Manage** inside it, and cannot resize it, hand out trust inside it, or abandon the claim containing it. - Staff holding `griefprevention.adminclaims` keep full Edit and Manage inside it. - The owner still controls the claim around it, so an administrative subdivision is not an admin claim — it is a subclaim whose interior is staff-managed. - `/aclaim makebasic` (or `makeadmin` on an already-admin subdivision) converts it back. The flag is persisted in both storage backends: the flat-file claim codec carries an `Admin Subdivision` field on the shared claim file, and the database schema grows `griefprevention_claimdata.adminsubdivision` via the usual `ADD COLUMN IF NOT EXISTS` migration, so existing files and tables upgrade in place and the two backends stay feature-for-feature. ## Fixes ### Items dropped during combat could be silently deleted when the main inventory was full During PvP combat with `GriefPrevention.PvP.AllowCombatItemDrop` at its default `false`, GriefPrevention cancels item drops so the items stay in the player's inventory. Cancelling a drop only works when the server can put the stack back: the server returns a cancelled drop to the **main** inventory, so anything dropped from the cursor or an armor or offhand slot — with no main slot to return to — was destroyed when the 36 main slots were full or could not absorb the stack. This is upstream [GriefPrevention issue #2619](https://github.com/GriefPrevention/GriefPrevention/issues/2619), rooted in the server behavior described in [PaperMC/Paper#7726](https://github.com/PaperMC/Paper/issues/7726). **Fix:** the drop is stopped at the click instead of after the fact, using the community-accepted workaround from [PaperMC/Paper#12475](https://github.com/PaperMC/Paper/pull/12475): - `InventoryClickEvent` drop actions (`DROP_ONE_SLOT`/`DROP_ALL_SLOT`/`DROP_ONE_CURSOR`/ `DROP_ALL_CURSOR`) are cancelled at `LOWEST` priority during combat, so the click is never applied and the item simply stays where it is. - Closing an inventory during combat with an item on the cursor moves that item into the main inventory instead of letting the server drop it; only the portion that cannot fit stays on the cursor. - A leftover drop that still reaches `PlayerDropItemEvent` (a hack client, or the small cursor remainder on inventory close) falls like vanilla — the item lands on the ground — rather than being deleted. Main-hand Q-drops remain safe: the server splits the stack out of the hotbar slot, so the existing block keeps the item in hand. The fix is being contributed back to upstream GriefPrevention. ## Notes - New configuration: `GriefPrevention.Claims.AllowShapedSubClaims` (default `false`). - Existing claims need no conversion: shaped subdivisions and admin flags are new fields, and both flat-file and database stores read them with safe defaults when absent. - The combat-drop fix is not 3D-specific; it ships in GriefPrevention3D and is also queued as an upstream pull request. - `MyCommand` was added to the plugin's soft-depend list. - Localization: all existing locale files (`de_DE`, `en_PT`, `es`, `fr_FR`, `ja_JP`, `ms_MY`, `pl_PL`, `pt_BR`, `ru_RU`, `tr_TR`, `uk_UA`, `zh_CN`) picked up translations for the shaped-subdivision, admin-subdivision, and combat-drop messages introduced this release. A new `messages_cs_CZ.yml` (Czech) locale file was added with a full translation of all 330 message keys. ## Tests - `ShapedSubdivisionTest` covers drawing a shaped subdivision inside a parent claim, requiring the parent to be a top-level 2D claim, containment within the parent, and reshaping an existing shaped subdivision. - `ClaimBoundsTest` covers column-exact overlap for shaped polygons: cavity columns are not part of a shaped claim, while Y separation between claims is preserved. - `AdminSubdivisionTest` covers the owner losing Edit/Manage inside an admin subdivision (while still controlling the surrounding claim), staff keeping both inside it, and normal subdivisions inheriting owner control. - `PlayerDropItemEventHandlerTest` covers the combat-drop handlers: drop-click cancellation in combat, cursor-on-close being moved into the main inventory, the full-inventory safety net that drops instead of deleting, and combat state being ignored when `AllowCombatItemDrop` is enabled. ## Files Changed ``` M gp3d-core/src/main/java/com/griefprevention/claims/ClaimBounds.java M gp3d-core/src/main/java/com/griefprevention/claims/editor/ClaimEditTargetType.java M gp3d-core/src/main/java/com/griefprevention/claims/editor/ClaimEditorSkeleton.java M gp3d-core/src/main/java/com/griefprevention/claims/persistence/ClaimDataSchema.java M gp3d-core/src/test/java/com/griefprevention/claims/ClaimBoundsTest.java M gp3d-core/src/test/java/com/griefprevention/fabric/FabricClaimFileStoreTest.java M src/main/java/com/griefprevention/commands/UnifiedAdminClaimCommand.java M src/main/java/com/griefprevention/commands/UnifiedClaimCommand.java M src/main/java/me/ryanhamshire/GriefPrevention/Alias.java M src/main/java/me/ryanhamshire/GriefPrevention/Claim.java M src/main/java/me/ryanhamshire/GriefPrevention/ClaimToolDispatcher.java M src/main/java/me/ryanhamshire/GriefPrevention/DataStore.java M src/main/java/me/ryanhamshire/GriefPrevention/DatabaseDataStore.java M src/main/java/me/ryanhamshire/GriefPrevention/EquipShovelProcessingTask.java M src/main/java/me/ryanhamshire/GriefPrevention/FlatFileDataStore.java M src/main/java/me/ryanhamshire/GriefPrevention/GriefPrevention.java M src/main/java/me/ryanhamshire/GriefPrevention/Messages.java M src/main/java/me/ryanhamshire/GriefPrevention/PlayerEventHandler.java M src/main/java/me/ryanhamshire/GriefPrevention/ShovelMode.java M src/main/java/me/ryanhamshire/GriefPrevention/StartupHeader.java M src/main/resources/alias.yml M src/main/resources/messages.yml M src/main/resources/messages_de_DE.yml M src/main/resources/messages_en.yml M src/main/resources/messages_en_PT.yml M src/main/resources/messages_es.yml M src/main/resources/messages_fr_FR.yml M src/main/resources/messages_ja_JP.yml M src/main/resources/messages_ms_MY.yml M src/main/resources/messages_pl_PL.yml M src/main/resources/messages_pt_BR.yml M src/main/resources/messages_ru_RU.yml M src/main/resources/messages_tr_TR.yml M src/main/resources/messages_uk_UA.yml M src/main/resources/messages_zh_CN.yml M src/main/resources/plugin.yml A src/main/resources/messages_cs_CZ.yml A src/test/java/me/ryanhamshire/GriefPrevention/AdminSubdivisionTest.java A src/test/java/me/ryanhamshire/GriefPrevention/PlayerDropItemEventHandlerTest.java A src/test/java/me/ryanhamshire/GriefPrevention/ShapedSubdivisionTest.java ```

# GriefPrevention3D v18.2.17 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## Features ### Shaped 2D subdivisions Subdivisions can now be drawn as free-form orthogonal polygons inside a claim, matching the shaped-claims tooling but scoped to a parent claim. Run `/shapedsubdivideclaims` (aliases: `shapedsubdivideclaim`, `ssc`, `shapedsubdivide`) or `/claim mode shapedsubdivide` to enter the mode: - Right-click inside one of your claims to place corners, then click your first corner again to close the subdivision. - Click an existing shaped subdivision's boundary to enter a reshape session for it. - A shaped subdivision must stay inside the claim it subdivides. - Shaped subdivisions work inside top-level 2D claims only; a 3D claim cannot be subdivided with this mode, and a shaped subdivision spans the same vertical range as its parent claim. The mode is gated by a new `GriefPrevention.Claims.AllowShapedSubClaims` setting, which defaults to `false`. Both `/shapedsubdivideclaims` and `/claim mode shapedsubdivide` refuse to enter the mode while it is disabled. Overlap checks between a shaped polygon and other claims are now column-exact: a 3D claim sitting only inside the shaped claim's rectangular bounding box but over a cavity (a concave notch the polygon does not actually cover) is no longer treated as an overlap, while Y separation between claims is still respected. ### Admin-controlled subdivisions Staff can flag an individual subdivision as administered by the server, taking its editing and trust management away from the claim owner. Use `/aclaim makeadmin` and `/aclaim makebasic` (or the standalone `/makeadmin` and `/makebasic`) on a subdivision. Staff need `griefprevention.adminclaims.convert`. The subdivision has to be selected first by right-clicking one of its corners with the golden shovel; running the command without a selection tells you to select one and run it again. Once a subdivision is administrative: - The claim owner loses **Edit** and **Manage** inside it, and cannot resize it, hand out trust inside it, or abandon the claim containing it. - Staff holding `griefprevention.adminclaims` keep full Edit and Manage inside it. - The owner still controls the claim around it, so an administrative subdivision is not an admin claim — it is a subclaim whose interior is staff-managed. - `/aclaim makebasic` (or `makeadmin` on an already-admin subdivision) converts it back. The flag is persisted in both storage backends: the flat-file claim codec carries an `Admin Subdivision` field on the shared claim file, and the database schema grows `griefprevention_claimdata.adminsubdivision` via the usual `ADD COLUMN IF NOT EXISTS` migration, so existing files and tables upgrade in place and the two backends stay feature-for-feature. ## Fixes ### Items dropped during combat could be silently deleted when the main inventory was full During PvP combat with `GriefPrevention.PvP.AllowCombatItemDrop` at its default `false`, GriefPrevention cancels item drops so the items stay in the player's inventory. Cancelling a drop only works when the server can put the stack back: the server returns a cancelled drop to the **main** inventory, so anything dropped from the cursor or an armor or offhand slot — with no main slot to return to — was destroyed when the 36 main slots were full or could not absorb the stack. This is upstream [GriefPrevention issue #2619](https://github.com/GriefPrevention/GriefPrevention/issues/2619), rooted in the server behavior described in [PaperMC/Paper#7726](https://github.com/PaperMC/Paper/issues/7726). **Fix:** the drop is stopped at the click instead of after the fact, using the community-accepted workaround from [PaperMC/Paper#12475](https://github.com/PaperMC/Paper/pull/12475): - `InventoryClickEvent` drop actions (`DROP_ONE_SLOT`/`DROP_ALL_SLOT`/`DROP_ONE_CURSOR`/ `DROP_ALL_CURSOR`) are cancelled at `LOWEST` priority during combat, so the click is never applied and the item simply stays where it is. - Closing an inventory during combat with an item on the cursor moves that item into the main inventory instead of letting the server drop it; only the portion that cannot fit stays on the cursor. - A leftover drop that still reaches `PlayerDropItemEvent` (a hack client, or the small cursor remainder on inventory close) falls like vanilla — the item lands on the ground — rather than being deleted. Main-hand Q-drops remain safe: the server splits the stack out of the hotbar slot, so the existing block keeps the item in hand. The fix is being contributed back to upstream GriefPrevention. ## Notes - New configuration: `GriefPrevention.Claims.AllowShapedSubClaims` (default `false`). - Existing claims need no conversion: shaped subdivisions and admin flags are new fields, and both flat-file and database stores read them with safe defaults when absent. - The combat-drop fix is not 3D-specific; it ships in GriefPrevention3D and is also queued as an upstream pull request. - `MyCommand` was added to the plugin's soft-depend list. - Localization: all existing locale files (`de_DE`, `en_PT`, `es`, `fr_FR`, `ja_JP`, `ms_MY`, `pl_PL`, `pt_BR`, `ru_RU`, `tr_TR`, `uk_UA`, `zh_CN`) picked up translations for the shaped-subdivision, admin-subdivision, and combat-drop messages introduced this release. A new `messages_cs_CZ.yml` (Czech) locale file was added with a full translation of all 330 message keys. ## Tests - `ShapedSubdivisionTest` covers drawing a shaped subdivision inside a parent claim, requiring the parent to be a top-level 2D claim, containment within the parent, and reshaping an existing shaped subdivision. - `ClaimBoundsTest` covers column-exact overlap for shaped polygons: cavity columns are not part of a shaped claim, while Y separation between claims is preserved. - `AdminSubdivisionTest` covers the owner losing Edit/Manage inside an admin subdivision (while still controlling the surrounding claim), staff keeping both inside it, and normal subdivisions inheriting owner control. - `PlayerDropItemEventHandlerTest` covers the combat-drop handlers: drop-click cancellation in combat, cursor-on-close being moved into the main inventory, the full-inventory safety net that drops instead of deleting, and combat state being ignored when `AllowCombatItemDrop` is enabled. ## Files Changed ``` M gp3d-core/src/main/java/com/griefprevention/claims/ClaimBounds.java M gp3d-core/src/main/java/com/griefprevention/claims/editor/ClaimEditTargetType.java M gp3d-core/src/main/java/com/griefprevention/claims/editor/ClaimEditorSkeleton.java M gp3d-core/src/main/java/com/griefprevention/claims/persistence/ClaimDataSchema.java M gp3d-core/src/test/java/com/griefprevention/claims/ClaimBoundsTest.java M gp3d-core/src/test/java/com/griefprevention/fabric/FabricClaimFileStoreTest.java M src/main/java/com/griefprevention/commands/UnifiedAdminClaimCommand.java M src/main/java/com/griefprevention/commands/UnifiedClaimCommand.java M src/main/java/me/ryanhamshire/GriefPrevention/Alias.java M src/main/java/me/ryanhamshire/GriefPrevention/Claim.java M src/main/java/me/ryanhamshire/GriefPrevention/ClaimToolDispatcher.java M src/main/java/me/ryanhamshire/GriefPrevention/DataStore.java M src/main/java/me/ryanhamshire/GriefPrevention/DatabaseDataStore.java M src/main/java/me/ryanhamshire/GriefPrevention/EquipShovelProcessingTask.java M src/main/java/me/ryanhamshire/GriefPrevention/FlatFileDataStore.java M src/main/java/me/ryanhamshire/GriefPrevention/GriefPrevention.java M src/main/java/me/ryanhamshire/GriefPrevention/Messages.java M src/main/java/me/ryanhamshire/GriefPrevention/PlayerEventHandler.java M src/main/java/me/ryanhamshire/GriefPrevention/ShovelMode.java M src/main/java/me/ryanhamshire/GriefPrevention/StartupHeader.java M src/main/resources/alias.yml M src/main/resources/messages.yml M src/main/resources/messages_de_DE.yml M src/main/resources/messages_en.yml M src/main/resources/messages_en_PT.yml M src/main/resources/messages_es.yml M src/main/resources/messages_fr_FR.yml M src/main/resources/messages_ja_JP.yml M src/main/resources/messages_ms_MY.yml M src/main/resources/messages_pl_PL.yml M src/main/resources/messages_pt_BR.yml M src/main/resources/messages_ru_RU.yml M src/main/resources/messages_tr_TR.yml M src/main/resources/messages_uk_UA.yml M src/main/resources/messages_zh_CN.yml M src/main/resources/plugin.yml A src/main/resources/messages_cs_CZ.yml A src/test/java/me/ryanhamshire/GriefPrevention/AdminSubdivisionTest.java A src/test/java/me/ryanhamshire/GriefPrevention/PlayerDropItemEventHandlerTest.java A src/test/java/me/ryanhamshire/GriefPrevention/ShapedSubdivisionTest.java ```

# GriefPrevention3D v18.2.16 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## Fixes ### Interacting with a Citizens horse NPC could erase its equipment GriefPrevention inherited an old interaction-time repair for untamed inventory-bearing animals. When a player clicked one, the handler reset its owner and cleared its inventory. Citizens horse NPCs can legitimately present as untamed Bukkit horses, so clicking an NPC could silently remove its saddle and armor even though Citizens had configured both correctly. **Fix:** GriefPrevention no longer mutates an untamed horse while handling interaction. The horse's owner and inventory are left untouched, while the normal claim access checks continue to run. This does not add a Citizens dependency or bypass protection for NPCs; it removes the unrelated destructive repair behavior for Citizens and other plugin-managed horses. Reported by @RocketYota in upstream [GriefPrevention issue #2623](https://github.com/GriefPrevention/GriefPrevention/issues/2623). ## Experimental Fabric preview The `GriefPrevention3D.jar` release asset now also contains the first native Fabric adapter. It can be installed as a Bukkit/Paper plugin or placed unchanged in a Fabric server's `mods` directory. The Fabric side of v18.2.16 is **experimental and still in development**: - Fabric is currently limited to Minecraft 1.21.11, Java 21, and a server-side installation. - Fabric API is required. - Stick inspection and golden-shovel create/resize sessions now show client-only fake-block claim boundaries to the player using the tools. No client mod is required. - The adapter reads and writes the shared `plugins/GriefPreventionData` flat-file layout so the same claim graph can be tested when moving between Paper and Fabric. - Existing player and group files are preserved byte-for-byte, including claim-block balances, but Fabric does not enforce claim-block balances yet. - Protection and command parity with the Bukkit plugin is not complete. Back up `GriefPreventionData` and test this preview away from a production server. The stable Bukkit/Paper behavior remains available from the same jar across its existing supported version range. Fabric support in this release is advertised only for 1.21.11. ## Notes No configuration or data migration is required for the Citizens fix. The fix is on the Bukkit side because Citizens is a Bukkit plugin; Fabric has no equivalent horse-inventory mutation path. ## Tests A handler-level regression test models an untamed horse with an inventory and fails if an interaction calls either `Inventory.clear()` or `Tameable.setOwner(null)`. The universal jar checks also load the Bukkit entry classes on Java 8 and boot the exact same artifact on a Fabric 1.21.11 server. ## Issue Fix Files ```text M src/main/java/me/ryanhamshire/GriefPrevention/PlayerEventHandler.java A src/test/java/me/ryanhamshire/GriefPrevention/PlayerInteractEntityEventHandlerTest.java ```

# GriefPrevention3D v18.2.16 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## Fixes ### Interacting with a Citizens horse NPC could erase its equipment GriefPrevention inherited an old interaction-time repair for untamed inventory-bearing animals. When a player clicked one, the handler reset its owner and cleared its inventory. Citizens horse NPCs can legitimately present as untamed Bukkit horses, so clicking an NPC could silently remove its saddle and armor even though Citizens had configured both correctly. **Fix:** GriefPrevention no longer mutates an untamed horse while handling interaction. The horse's owner and inventory are left untouched, while the normal claim access checks continue to run. This does not add a Citizens dependency or bypass protection for NPCs; it removes the unrelated destructive repair behavior for Citizens and other plugin-managed horses. Reported by @RocketYota in upstream [GriefPrevention issue #2623](https://github.com/GriefPrevention/GriefPrevention/issues/2623). ## Experimental Fabric preview The `GriefPrevention3D.jar` release asset now also contains the first native Fabric adapter. It can be installed as a Bukkit/Paper plugin or placed unchanged in a Fabric server's `mods` directory. The Fabric side of v18.2.16 is **experimental and still in development**: - Fabric is currently limited to Minecraft 1.21.11, Java 21, and a server-side installation. - Fabric API is required. - Stick inspection and golden-shovel create/resize sessions now show client-only fake-block claim boundaries to the player using the tools. No client mod is required. - The adapter reads and writes the shared `plugins/GriefPreventionData` flat-file layout so the same claim graph can be tested when moving between Paper and Fabric. - Existing player and group files are preserved byte-for-byte, including claim-block balances, but Fabric does not enforce claim-block balances yet. - Protection and command parity with the Bukkit plugin is not complete. Back up `GriefPreventionData` and test this preview away from a production server. The stable Bukkit/Paper behavior remains available from the same jar across its existing supported version range. Fabric support in this release is advertised only for 1.21.11. ## Notes No configuration or data migration is required for the Citizens fix. The fix is on the Bukkit side because Citizens is a Bukkit plugin; Fabric has no equivalent horse-inventory mutation path. ## Tests A handler-level regression test models an untamed horse with an inventory and fails if an interaction calls either `Inventory.clear()` or `Tameable.setOwner(null)`. The universal jar checks also load the Bukkit entry classes on Java 8 and boot the exact same artifact on a Fabric 1.21.11 server. ## Issue Fix Files ```text M src/main/java/me/ryanhamshire/GriefPrevention/PlayerEventHandler.java A src/test/java/me/ryanhamshire/GriefPrevention/PlayerInteractEntityEventHandlerTest.java ```

# GriefPrevention3D v18.2.15 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## Fixes ### Two rectangular claims could merge into a narrow Manhattan path Running `/mergeclaims` on two rectangular claims could produce a thin, bent connection between them instead of one usable rectangle. The disconnected-polygon union already knew how to make a valid Manhattan connection, so the later bounding-box fallback was never reached. Whether another claim occupied part of the larger rectangle could therefore indirectly change which geometry survived. **Fix:** a direct merge now chooses its geometry before the generic polygon union runs. When both selected claims have four-corner rectangular boundaries, the result is always the single global bounding rectangle covering both claims: - The rectangle uses the minimum and maximum X/Z coordinates of both selected claims. - `GriefPrevention.Claims.AllowShapedClaims` does not change this rule. - A claim which carries shaped-claim metadata but still has an actual four-corner boundary is treated as a rectangle. - If the proposed rectangle overlaps another claim, the merge fails with the normal overlap conflict instead of silently falling back to a Manhattan or other non-rectangular shape. This can require more claim blocks than the old narrow connection. The existing final-area claim-block check still runs before anything is changed and reports insufficient blocks in the normal way. ### Shaped claims keep their Manhattan route, widened by the selected nib depth The Manhattan route remains the useful behavior for non-rectangular shaped claims, but its old fixed-width path could look and behave like a tiny road between otherwise substantial claim sections. Shaped merges now record the selected boundary edge and the player's position at **both** ends. A new platform-neutral `MergeCorridor` geometry helper uses that information to build one straight rectangle or two rectangles forming an L-shaped Manhattan route: - The player's distance inward from the selected edge controls how deeply the corridor is inset into that nib. - The selected nib keeps its own width while the chosen depth remains inside the narrow section. - If that depth reaches a wider connected parent section, the parent section becomes the width of that corridor leg. - Diagonal claims keep the Manhattan turn; each leg uses the width measured from the nib it leaves or enters. - A shaped claim must have a resolvable boundary edge at both ends, preventing missing nib data from dropping back to an unintended thin connector. The cross-claim shaped-editor/roundabout path already supplies its own connection cells and continues using that path unchanged. This new corridor selection applies to direct `/mergeclaims` operations. ### Populated-area overlap checks now cover the whole proposed result The old merge check looked for claims near the first claim's corner. A long rectangle or shaped corridor can extend through chunks well beyond that local search, allowing a claim in the middle or near the second endpoint to be missed. **Fix:** collision candidates are collected from every chunk beneath the complete proposed merge boundary. The exact polygon intersection check then rejects: - A third claim belonging to another player. - A third claim belonging to the same owner. Only the two explicitly selected claims are collapsed; swallowing a separate same-owner claim would otherwise leave two live claims on the same blocks. - A claim crossing a shaped corridor even when neither polygon has a corner inside the other, such as a narrow horizontal claim crossing a vertical corridor. The two claims explicitly selected for the merge and their subdivisions are still excluded from this conflict list. On conflict, no claim geometry is mutated and the conflicting claim is shown with the existing conflict visualization. ### The command completion path now checks the second claim's edit permission Right-click completion already checked edit permission on the second claim, but running `/mergeclaims` again while standing inside the second claim could reach the merge directly. That alternate command path now performs the same edit-permission check before measuring a nib or calling the data store, so a claim the player cannot edit is never absorbed. ## Notes No configuration or claim-data migration is required. Existing rectangular claims remain rectangular, existing shaped boundaries remain valid, and stored claim IDs and subdivisions are handled as before. ## Tests Eleven regression cases were added across `MergeClaimsTest` and `MergeCorridorTest`, covering: - The mandatory global bounding rectangle for two rectangular claims, even when edge/depth metadata is present. - Four-corner claims carrying shaped metadata. - Shallow nib depth and widening when that depth reaches a larger parent section. - The complete widened Manhattan route between diagonal shaped claims. - Clear populated areas containing nearby same-owner and other-player claims. - Overlap rejection for both same-owner and other-player claims. - Candidate discovery across the full multi-chunk proposed boundary. - Crossing-polygon conflicts where corner-only intersection checks would fail. - Rejection when the player cannot edit the second selected claim. The full Gradle `check` lifecycle passes for the Bukkit plugin, `gp3d-core`, and the Fabric module. ## Files Changed ``` A gp3d-core/src/main/java/com/griefprevention/geometry/MergeCorridor.java A gp3d-core/src/test/java/com/griefprevention/geometry/MergeCorridorTest.java M src/main/java/me/ryanhamshire/GriefPrevention/ClaimToolDispatcher.java M src/main/java/me/ryanhamshire/GriefPrevention/DataStore.java M src/main/java/me/ryanhamshire/GriefPrevention/GriefPrevention.java M src/main/java/me/ryanhamshire/GriefPrevention/PlayerEventHandler.java A src/test/java/me/ryanhamshire/GriefPrevention/MergeClaimsTest.java ```

# GriefPrevention3D v18.2.14 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## Fixes ### Extra spaces after the colon were read as part of the message v18.2.13 stopped parsing message files as YAML so that color codes work without quoting. The new reader consumes exactly **one** space or tab after `Key:` as the separator and takes the rest of the line literally — which means a value that had been lined up in a column kept its padding as text: ```yaml BookDisabledChestClaims: Auf diesem Server beansprucht das Platzieren einer Kiste NICHT automatisch Land für dich. ``` ``` Auf diesem Server beansprucht das Platzieren einer Kiste NICHT automatisch Land für dich. ``` YAML treats every space between the colon and the first non-space character as separator, so this is a regression against how the same file read before v18.2.13. It only affects hand-edited files — Bukkit's YAML writer always emits exactly one space, so anything the plugin had written itself was unaffected. `messages_de_DE.yml` is the one bundled locale that hits it, on `BookDisabledChestClaims`. **Fix:** leading spaces and tabs between the colon and the value are dropped, matching YAML. Padding a file into columns is now cosmetic, exactly like quoting. Leading spaces that are *inside* quotes are still preserved, because the quote is the first non-space character and everything after it is the value: ```yaml Padded: ' two leading spaces, on purpose' ``` ``` two leading spaces, on purpose ``` That is how `en_PT`, `fr_FR` and `uk_UA` indent the same book line, and it read the same way before and after this fix. ## Notes No message file needs editing, and saving remains append-only, so your customizations, comments and ordering are left alone. ## Tests `MessageFileTest` — 15 cases. New this release: `ignoresExtraSpacesBetweenTheColonAndTheValue`, covering both a padded plain value and a padded quoted value whose own leading spaces are kept. The existing `readsBackEveryValueBukkitWouldHaveWritten` sweep still round-trips every message in `messages_en.yml` through Bukkit's YAML writer and back through the reader, and `bundledLocaleFilesParseIntoKnownMessages` parses all 13 bundled locale files. ## Files Changed ``` M gradle.properties M pom.xml M src/main/java/me/ryanhamshire/GriefPrevention/MessageFile.java M src/test/java/me/ryanhamshire/GriefPrevention/MessageFileTest.java ```

# GriefPrevention3D v18.2.13 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## Fixes ### A color code at the start of a message ate the word after it Putting a formatting code at the front of a message did not colorize it — it deleted the next word: ```yaml Messages: IgnoringClaims: &1Now ignoring claims. ``` ``` ignoring claims. ``` The message files were being read by a YAML parser, and to YAML a leading `&` is not text — it is an **anchor declaration**. `&1Now` was consumed as an anchor named `1Now`, and the value became whatever followed it. Nothing was logged, because as far as YAML was concerned the file was perfectly valid. Quoting the value (`IgnoringClaims: '&1Now ignoring claims.'`) worked around it, but only until the next `/gpreload`: the plugin re-serialized the whole file through SnakeYAML on load, and SnakeYAML emits scalars unquoted whenever quoting is not strictly required. The quotes were stripped, the value was re-read as an anchor, and the word disappeared again. The same parser rules silently swallowed other perfectly reasonable message text — a `#` started a comment, and backslashes were escape sequences inside double-quoted values. **Fix:** message files are no longer parsed as YAML. A new `MessageFile` reader takes everything after `Key:` **literally**: - `&1`, `&a`, `$e` and hex codes such as `&#ff0000` work anywhere in a message, including the very first character, with no quoting. - `#`, `\`, `:` and quote characters inside a message are just text. - Quotes are still **optional**: if a value is wrapped in `'…'` or `"…"` the quotes are stripped (with `''` → `'` and `\"` → `"`), so every existing customized `messages.yml` keeps working exactly as it did. - The legacy nested format (`SomeMessage:` → `Text:` / `Notes:`) still reads. - Indentation, comments and blank lines are handled as before. ### Message files were rewritten on every load Loading messages re-serialized the active file and saved it back. That is what stripped quoting, but it also normalized comments and key order, and it had a more damaging edge: if a server had **both** a locale file (`messages_de_DE.yml`) and a `messages.yml`, the locale file's contents were saved *over* `messages.yml` on every load, discarding customizations in it. **Fix:** saving is now **append-only**. Existing lines — comments, ordering, whatever quoting style the admin prefers — are left byte-for-byte intact, and only keys that are missing from the file are appended, written single-quoted with the message's notes as a `#` comment above them. `messages.yml` is never written unless it is the file actually in use and it is missing keys. ### Action bar messages ignored the default message colors Messages listed under `GriefPrevention.ActionBarMessages` were sent as raw legacy text, while the chat path prefixes the message's `TextMode` color. Any action bar message that did not hard-code a color of its own therefore rendered plain white — `/gpreload` output, warnings and errors all looked identical. **Fix:** the action bar path now prefixes the same `TextMode` color chat uses, so warnings arrive gold, errors red, successes green and info aqua by default. A color code inside the message still comes after the prefix and still wins, so any custom color an admin has already set is unaffected. `UnprotectedChestWarning` is the one default action bar message this changes — it is `TextMode.Warn` with no color of its own, so it is now gold instead of white. The four boundary-violation messages already carry `&6` in their text and are unchanged. ## Upstream - **Rename `/permissiontrust` to `/managetrust` ([#2618](https://github.com/GriefPrevention/GriefPrevention/pull/2618))**: merged upstream commit `a873b55d`, which renames the command and removes the last non-hierarchical trust structures left over from #2507. `/permissiontrust`, `/pt` and `/mt` remain as aliases in GriefPrevention3D, so existing commands, macros and signs keep working. The `griefprevention.permissiontrust` permission node is unchanged. The message key `NoPermissionTrust` is now `NoManageTrust` — if you customized that message, rename the key in your message file; otherwise the default is used. ## Notes Quoting message values is now purely cosmetic. Both of these produce the same result: ```yaml IgnoringClaims: &1Now ignoring claims. IgnoringClaims: '&1Now ignoring claims.' ``` The one behavior change to be aware of: a value that both begins *and* ends with a quote character loses those quotes, since that is how existing quoted files are supported. Write `He said "hi" now` rather than `"hi"` if the quotes are meant to be visible. A handful of entries in the English message files still contain doubled apostrophes (`You don''t have permission`) inherited from upstream's `MessageFormat` era. Message arguments are substituted with a plain string replace, not `MessageFormat`, so those render literally as `don''t` on unquoted lines. Cosmetic only, and unchanged by this release. ## Tests `MessageFileTest` — 9 cases covering unquoted color codes, quote stripping for legacy files, literal `#`/backslash/colon handling, the nested `Text:` format, append-only saving, no-write when nothing is missing, section creation, and a parse sweep over all 13 bundled locale files. ## Files Changed ``` M gradle.properties M pom.xml M src/main/java/me/ryanhamshire/GriefPrevention/GriefPrevention.java A src/main/java/me/ryanhamshire/GriefPrevention/MessageFile.java M src/main/java/me/ryanhamshire/GriefPrevention/MessageLocalization.java A src/test/java/me/ryanhamshire/GriefPrevention/MessageFileTest.java ```

# GriefPrevention3D v18.2.12 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## Fixes ### Trust commands freeze the region/main thread on claims with many subdivisions Reported in [issue #9](https://github.com/castledking/GriefPrevention3D/issues/9) on Folia 26.1.2: running `/trust <player>` on a parent claim with a large number of subdivisions stopped the affected region from ticking for 15+ seconds, with the Folia watchdog dumping a stack parked inside SnakeYAML's emitter at 5s, 10s and 15s: ``` org.yaml.snakeyaml.emitter.Emitter.writeLineBreak(Emitter.java:1344) ... org.bukkit.configuration.file.YamlConfiguration.saveToString(YamlConfiguration.java:92) FlatFileDataStore.getYamlForClaim(FlatFileDataStore.java:731) FlatFileDataStore.writeClaimToStorage(FlatFileDataStore.java:810) FlatFileDataStore.writeClaimToStorage(FlatFileDataStore.java:804) DataStore.saveClaim(DataStore.java:831) GriefPrevention.propagateTrustToChildren(GriefPrevention.java:3699) ``` Two separate problems combined here, and both are fixed. #### 1. Quadratic saves — one full claim-tree serialization per subdivision Flat file storage keeps subdivisions **inside their root claim's `.yml` file**, not in files of their own. `writeClaimToStorage` reflects that: given a subdivision, it walks up to the root claim and serializes the *entire* tree — parent plus every child and grandchild — into one document. `propagateTrustToChildren` saved each child as it modified it: ```java childClaim.setPermission(identifier, permissionLevel); this.dataStore.saveClaim(childClaim); // rewrites the whole tree, once per child ``` So a claim with N subdivisions performed N full-tree YAML serializations and N file writes, each one proportional to N — quadratic work, all of it on the calling thread, which on Folia is the region thread that owns the player. That is the watchdog stall. **Fix:** `propagateTrustToChildren` now only mutates children in memory and collects them into a list. The caller hands that list to the data store in a single batch, at all three call sites (`/trust`, `/accesstrust`, `/containertrust`, `/permissiontrust` via `handleTrustCommand`, plus both `/untrust` paths). Batching is done through a new `DataStore.saveClaims(Collection<Claim>)`: - The **default** implementation saves each claim individually. This is required for the database backend, which stores one row per claim — saving only the parent there would silently drop the children's permission changes. - `FlatFileDataStore` **overrides** it to collapse the batch down to the distinct root claims involved and write each root exactly once. Claim IDs are still assigned per claim, so nothing that depended on `saveClaim`'s ID assignment changes. N subdivisions now cost **one** write instead of N. #### 2. YAML serialization and disk I/O ran on the tick thread Even a single write of a large claim tree does real work — SnakeYAML emitting, then a blocking file write — and it happened inline on whichever thread ran the command. **Fix:** `writeClaimToStorage` now builds the `YamlConfiguration` on the calling thread, where the claim data cannot change underneath it, then hands that finished document to a dedicated single daemon writer thread which performs `saveToString()` and the file write. Claim data is never read off-thread, so this introduces no race with claim mutation. The writer pipeline: - **Coalesces** writes per claim — if a claim is saved several times before the writer catches up, only the newest data is written and the superseded ones are dropped. - **Orders deletes behind writes** on the same thread, and drops any pending write for a claim being deleted, so a queued write can never resurrect a deleted claim file. - **Drains on shutdown** — `FlatFileDataStore.close()` (called from `onDisable`) waits for the writer, then writes anything still pending on the calling thread. If the writer is already shut down, saves and deletes fall back to running synchronously, so no claim data is lost during a normal stop or restart. - Also flushes before `migrateData`, which renames the claim data folder out from under the writer. This benefits every claim save, not just trust changes — resizes, subdivisions, transfers and abandons no longer serialize YAML or touch disk on a tick thread. ## Notes Claim saves are now durable a few milliseconds after the command returns, rather than at the moment it returns. A normal `stop`/restart, plugin disable, or `/reload` flushes everything; only an abrupt `kill -9` could lose that sub-second window. `DataStore.mergeClaims` still saves each moved subdivision individually when merging two claims. That path is much cheaper now that serialization and I/O are off-thread, but it is the same pattern and remains a candidate for `saveClaims` in a later release. ## Files Changed ``` M gradle.properties M pom.xml M src/main/java/me/ryanhamshire/GriefPrevention/DataStore.java M src/main/java/me/ryanhamshire/GriefPrevention/FlatFileDataStore.java M src/main/java/me/ryanhamshire/GriefPrevention/GriefPrevention.java ```

# GriefPrevention3D v18.2.11 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## Fixes ### Dynamically registered commands failing with "Unknown or incomplete command" This resolves the `/acb` issue carried as a known issue in v18.2.10, where the command produced a client-side **"Unknown or incomplete command"** error with **nothing at all in the console** — no exception, no warning, no permission denial. `registerDynamicStandaloneCommand` and `registerDynamicRootCommand` registered commands by reflecting into `SimpleCommandMap`'s `knownCommands` map and calling `put()` directly: ```java knownCommands.remove(lowerName); knownCommands.put(lowerName, dynamicCommand); knownCommands.put(prefix + ":" + lowerName, dynamicCommand); ``` On Paper (and its forks), commands injected this way never pass through the server's Brigadier command registration, so they are absent from the **client's** command tree. The client then rejects the command locally and never sends it to the server at all — which is exactly why the console stayed silent. `CommandMap.register()` performs the Brigadier-aware registration; a raw map `put()` does not. This failure mode was already known in the codebase: `syncShapedCommandRegistration` carries the comment *"Use CommandMap.register() so the implementation (Paper/Brigadier) stays consistent with plugin.yml aliases. Raw knownCommands.put() can leave /shapedclaim broken…"* — that call site had been fixed, but the dynamic standalone and dynamic root command paths were still using raw puts. **Fix:** both paths now call `CommandMap.register()` first. Reflection is used only as a fallback when the plain command name is genuinely already taken, in which case the displaced command is still recorded so `unregisterAllDynamicCommands()` can restore it (behavior added in v18.2.9). When the name is taken and the map cannot be read, a warning is logged noting the command is still reachable as `/griefprevention3d:<command>` instead of failing silently. ### Command map reflection broken on server forks (DivineMC, Purpur, etc.) Two reflection lookups in `UnifiedCommandHandler` assumed an exact class layout and threw on any server whose implementation classes sit deeper in the hierarchy: 1. `getCommandMap()` called `Bukkit.getServer().getClass().getDeclaredField("commandMap")` — a `getDeclaredField` lookup on the *leaf* runtime class. A fork that subclasses `CraftServer` has no such declared field on the subclass, so this returned `null` and dynamic registration was skipped entirely. 2. All three `knownCommands` lookups used `map.getClass().getSuperclass().getDeclaredField("knownCommands")`, assuming the field lives exactly one level up. That holds for vanilla CraftBukkit (`CraftCommandMap extends SimpleCommandMap`) but throws `NoSuchFieldException` on any fork that inserts its own `CommandMap` subclass. Notably, `GriefPrevention.findKnownCommandsMap()` already walked the full class hierarchy correctly — `UnifiedCommandHandler` simply had not been brought in line with it. **Fix:** - `getCommandMap()` now prefers Paper's `Server#getCommandMap()` API (reflectively, so Spigot compatibility is retained), and otherwise walks the server class hierarchy instead of inspecting only the leaf class. - Added a `findKnownCommands(CommandMap)` helper that walks the command map's class hierarchy, mirroring `findKnownCommandsMap`. All three former single-level reflection sites (dynamic standalone registration, dynamic root registration, and `unregisterAllDynamicCommands`) now use it. - `unregisterAllDynamicCommands()` logs a warning instead of proceeding when the command map cannot be read. These are the reflection assumptions most likely to break on a non-vanilla server jar, and they fail in a way that produces no diagnostic output — hardening them removes a class of silent, fork-specific command breakage. ## Notes The plugin does **not** platform-detect between Bukkit and Fabric at runtime. The Fabric support in `platforms/fabric-1.21.11` is a separate Gradle subproject producing a separate artifact; those classes are not present in the Bukkit jar. The only runtime class detection is feature detection for knockback handlers. A Paper-family fork is always driven through the normal Bukkit code path. ## Files Changed ``` M gradle.properties M pom.xml M src/main/java/com/griefprevention/commands/UnifiedCommandHandler.java ```

# GriefPrevention3D v18.2.10 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## Fixes ### `/abandonclaim` NullPointerException when any admin claim exists **This is the real cause of the `/abandonclaim` crash.** The null guard added in v18.2.9 was in `abandonClaimHandler` and was a genuine latent bug, but it was *not* what players were hitting — the crash happens earlier in the call chain, and is unrelated to the `AbandonReturnRatio` config value. Full stack trace from a v18.2.9 server: ``` Caused by: java.lang.NullPointerException: Cannot invoke "java.util.UUID.equals(Object)" because the return value of "Claim.getOwnerID()" is null at DataStore.cleanupAutoNeighborsOnDelete(DataStore.java:1434) at DataStore.deleteClaimUnchecked(DataStore.java:948) at DataStore.deleteClaimWithResult(DataStore.java:893) at GriefPrevention.abandonClaimHandler(GriefPrevention.java:3609) ``` `cleanupAutoNeighborsOnDelete` runs on every claim deletion. It correctly null-checks the *deleted* claim's owner, then scans every top-level claim in the datastore looking for other claims owned by the same player: ```java for (Claim otherClaim : this.claims) { if (!otherClaim.inDataStore) continue; if (otherClaim.parent != null) continue; if (otherClaim.id.equals(deletedClaim.id)) continue; if (!otherClaim.getOwnerID().equals(deletedOwner)) continue; // <-- NPE ``` **Administrative claims have a null `ownerID`.** As soon as that scan reached any admin claim, it threw. The sibling method `autoGrantNeighborTrust` guards exactly this case (`if (otherClaim.getOwnerID() == null) continue;`) — the guard was simply omitted in the deletion path. Conditions to trigger it (all common, which is why it looked like "nobody can abandon claims"): - `MinimumDistance` greater than `0` (otherwise auto-neighbor cleanup returns early), - at least one administrative claim anywhere in the datastore, - the abandoning player having at least one auto-neighbor entry — which happens automatically between any two nearby claims owned by different players, so it is the norm on a server with adjacent claims. Because the exception is thrown *after* `deleteClaimUnchecked` has already removed the claim from memory and from storage, the abandon itself partially succeeded — the player got no success message, no claim blocks refunded message, and a console stack trace, making it look like the command did nothing. **Fix:** added the missing `otherClaim.getOwnerID() == null` guard, matching `autoGrantNeighborTrust`. Admin claims can never match a specific deleted owner, so skipping them is the correct behavior. ### Not caused by the migration or by `AbandonReturnRatio` For the record, since this was initially suspected: auto-neighbor trust (`cleanupAutoNeighborsOnDelete`, `autoGrantNeighborTrust`, `addAutoNeighbor`) is a **GriefPrevention3D-only feature** — it does not exist anywhere in upstream GriefPrevention. Upstream's `deleteClaim` path has no equivalent code and cannot throw this exception, which is why the crash appeared only after migrating to GP3D. It is triggered purely by having an admin claim plus `MinimumDistance > 0`; no migrated data, storage backend (File or MySQL), or `AbandonReturnRatio` setting is involved. ## Known issue still under investigation ### `/acb` producing no output Still unresolved. The command-map corruption fixed in v18.2.9 (dynamic standalone registration permanently overwriting a `plugin.yml` command, so `plugin.getCommand("acb")` returned `null` forever and the legacy handler silently attached to nothing) is a real bug and remains fixed, but it has not been confirmed as the cause here. v18.2.9 added a console warning for that exact failure mode. To diagnose, run `/gpdebug` and restart, then check startup output for: ``` Could not register legacy standalone command 'acb': plugin.getCommand(...) returned null. ``` - If that warning appears, the registration collision is the cause. Removing any `standalone:` entry containing `acb` from the `blocks` subcommand in `alias.yml` will resolve it, since it is redundant with the dedicated legacy `/acb` handler. - If it does not appear, `/acb` is attached correctly and the failure is elsewhere — the exact observed behavior (silence vs. usage text vs. permission denial) is needed to narrow it down further. ## Files Changed ``` M gradle.properties M pom.xml M src/main/java/me/ryanhamshire/GriefPrevention/DataStore.java ```

# GriefPrevention3D v18.2.9 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## Fixes ### `/abandonclaim` throwing a NullPointerException (unfixed since migration) `abandonClaimHandler` adjusts a player's accrued claim blocks when `AbandonReturnRatio` is configured below `1.0`, using: ```java claim.ownerID.equals(playerData.playerID) ``` `claim.ownerID` is `null` for administrative claims (and any claim whose owner UUID failed to parse on load), and this line dereferenced it with no null check. On any server with `GriefPrevention.Claims.AbandonReturnRatio` set to something other than the default `1.0` — a common setting used to penalize abandoning claims — this threw an NPE for every `/abandonclaim` call: ``` org.bukkit.command.CommandException: Unhandled exception executing command 'abandonclaim' Caused by: java.lang.NullPointerException ``` The claim was already deleted by this point (`deleteClaimWithResult` runs earlier in the same method), so the abandon itself succeeded — only the claim-block refund step crashed, leaving the player with no success message and a confusing failure. **Fix:** added the missing `claim.ownerID != null` guard before the equality check. ### Claim merge could push an owner's claim blocks negative `DataStore.mergeClaims` validates the block-limit before applying a merge by computing the union polygon's area (`mergedPolygon.cellCount()`) and checking it against the acting player's remaining claim blocks. Two issues let this validation be bypassed: 1. **Wrong player checked.** The check only ran `if (player.getUniqueId().equals(firstClaim.ownerID))` — if the person performing the merge had `Edit`/manage trust on the claim but wasn't the owner, the block-limit check was skipped entirely, and the merge applied against the real owner's blocks with no validation at all. 2. **Checked area could differ from the applied area.** The limit check validated the real union polygon's area, but the shape is later applied via `updateClaimPolygon()`, which calls `claim.setShapedCorners(...)`. If the merged polygon's corners failed shape validation (e.g. a concave or otherwise irregular union), `updateClaimPolygon` silently fell back to the full bounding-box rectangle spanning the merged region — which can be larger than the polygon that was actually checked. The merge would pass the block-limit check, then apply a bigger shape than was validated, driving the owner's remaining claim blocks negative. **Fix:** - The block-limit check now validates against the claim **owner's** `PlayerData` (falling back to the acting player's data only when they are the owner), so trust-based merges by non-owners are checked correctly. - Before any state is mutated, the merged polygon's corners are now validated the same way `setShapedCorners` would validate them. If that validation would fail, the merge is aborted up front with `"Failed to merge claims: invalid resulting shape."` instead of silently substituting an oversized bounding-box rectangle after the block check has already passed. ### `/acb` permanently hijacked by `/aclaim blocks` after a `/gpreload` `/acb` (`adjustbonusclaimblocks`) is registered twice in `UnifiedAdminClaimCommand`: once as a standalone name for the `/aclaim blocks` subcommand (`Alias.AClaimBlocks`, driven by `alias.yml`), and once directly as the legacy 2-argument command (`/acb <player> <amount>`). At clean boot both resolve to the same real `PluginCommand` declared in `plugin.yml`, and since the legacy registration runs second, it wins. `/gpreload` broke this permanently, via `UnifiedCommandHandler`: 1. `registerDynamicStandaloneCommand` has a fallback path for standalone names that aren't found via `plugin.getCommand(name)`: it force-registers a raw `DynamicStandaloneCommand` directly into Bukkit's `CommandMap`, overwriting whatever was at that name. 2. `plugin.getCommand(name)` only ever returns objects that are `instanceof PluginCommand`. Once `acb`'s slot in the command map holds a `DynamicStandaloneCommand` instead, every future `plugin.getCommand("acb")` call returns `null` — including the legacy registration's own lookup. 3. `registerLegacyStandaloneCommand` had no `else` branch for that case — if `plugin.getCommand(name)` returned `null`, it silently registered nothing. No warning, no log line, nothing in the console. 4. `unregisterAllDynamicCommands()` (run at the top of every `/gpreload`, before commands are re-registered) only ever *deleted* the dynamic command's map entry — it never restored whatever real command had been overwritten to make room for it. Put together: the first time `acb`'s name ever got claimed by the dynamic path (e.g. during a `/gpreload` after editing `alias.yml`), it was gone for good. Every reload after that recreated `acb` as a `DynamicStandaloneCommand` bound to whatever `/aclaim blocks` standalone config `alias.yml` specified, and the legacy 2-arg handler could never reattach — with no error anywhere to explain why. This also explains the "no permission" reports even for OP/wildcard players: the dynamic command's permission falls back to a hardcoded `griefprevention.claims` when `alias.yml`'s `blocks` subcommand entry doesn't specify one, which is a different node than the `griefprevention.adjustclaimblocks` the legacy handler and most permission setups expect. Console senders bypass permission checks entirely, which is why running it from console "worked." **Fix:** - `registerDynamicStandaloneCommand` now snapshots any real command it's about to overwrite before replacing it. - `unregisterAllDynamicCommands()` now restores that original command on cleanup instead of just deleting the map entry, so a legitimate `plugin.yml` command/alias can no longer be permanently orphaned by a reload. - `registerLegacyStandaloneCommand` now logs a warning instead of silently registering nothing when it can't resolve the target command, so this failure mode is visible in the console going forward. If you have a custom `standalone:` entry for `acb` under `/aclaim blocks` in `alias.yml`, remove it — it's redundant with the dedicated legacy `/acb` handler and is what triggers the collision in the first place. ## Files Changed ``` M src/main/java/me/ryanhamshire/GriefPrevention/GriefPrevention.java M src/main/java/me/ryanhamshire/GriefPrevention/DataStore.java M src/main/java/com/griefprevention/commands/UnifiedCommandHandler.java ```

# GriefPrevention3D v18.2.8 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## Fixes ### Raid Omen bypass of `RaidTriggersRequireBuildTrust` (GriefPrevention#2622) When `RaidTriggersRequireBuildTrust` was enabled, `RaidTriggerEventHandler` only checked the claim at the **player's** location at the moment the raid fired. Because Raid Omen converts to an active raid a few seconds after it is acquired, a player could: 1. Drink an ominous bottle **outside** the claim boundary to gain Bad Omen. 2. Step toward the village until Bad Omen converted to Raid Omen inside the claim. 3. Walk back **outside** the claim boundary before the raid started. 4. Have the raid trigger anyway — the player was no longer standing in a claim, so no build-trust check applied. The raid actually centers on the village, not the player, so the location that matters for protection is the raid's location. ### Fix `RaidTriggerEventHandler` now resolves the claim at **`event.getRaid().getLocation()`** (the village / raid center) first, and only falls back to the player's location if the raid center is unclaimed. The build-trust check and cancellation are otherwise unchanged: - Raid center inside a claim where the player lacks `Build` trust → raid cancelled, regardless of where the player is standing. - Raid center unclaimed but player standing in a claim → falls back to the player's claim (preserves prior behavior). - Player has `Build` trust on the claim the raid centers on → raid proceeds. ### Ender pearl / chorus fruit no longer force the player's camera direction When teleporting via ender pearl or chorus fruit, some server software overwrites the player's yaw/pitch to match the projectile's direction instead of preserving the player's original look direction. `PlayerEventHandler` now copies the player's **from** yaw/pitch onto the teleport destination so the camera direction is preserved: - On the teleport itself, the destination location's yaw/pitch are set from `event.getFrom()` before the access check runs. - On a denied-pearl rollback, the rollback location keeps the player's **current** yaw/pitch rather than snapping back to the pre-pearl direction. ### Wilderness movement no longer blocked in claims-required worlds In `Creative` / `SurvivalRequiringClaims` worlds, `ProtectionHelper.checkPermission` previously returned a "no build outside claims" denial for **any** permission checked in the wilderness. This also denied `Access` permission, which disrupted movement and ender pearls in the wilderness. The wilderness denial is now scoped to `Build`, `Container`, and `Inventory` only. `Access` (walking, teleporting) is always allowed in wilderness, so enderpearls and movement are no longer interrupted. The automatic-claim chest-placement exception is preserved within the build/container/inventory path. ## Files Changed ``` M gradle.properties M pom.xml M src/main/java/com/griefprevention/protection/ProtectionHelper.java M src/main/java/me/ryanhamshire/GriefPrevention/PlayerEventHandler.java M src/main/java/me/ryanhamshire/GriefPrevention/RaidTriggerEventHandler.java ```

# GriefPrevention3D v18.2.7 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## New Features ### Per-Claim Alert Toggle (`/claim alerts`) - New `alertsEnabled` field on `Claim` (default `true`) - `/claim alerts [on|off]` — toggles alerts for the claim you're standing in - `/claimtogglealerts [on|off]` — toggles alerts for **all** your claims at once - `/toggleclaimalerts` — alias for `/claimtogglealerts` - Boundary violation messages (liquid/piston) respect the per-claim toggle: if alerts are disabled for the claim at the violation location, the message is suppressed ### Action Bar Message Routing - New config option `ActionBarMessages` (string list under `GriefPrevention.`) - Default value: `[UnprotectedChestWarning, ExternalLiquidBoundaryViolation, InternalLiquidBoundaryViolation, ExternalPistonBoundaryViolation, InternalPistonBoundaryViolation]` - These messages render in the **action bar** (above the hotbar) instead of chat - Graceful fallback to chat if `spigot().sendMessage(ChatMessageType.ACTION_BAR)` is unavailable - `ClaimBoundaryViolationTracker` routes through `GriefPrevention.sendMessage` so action bar dispatch works automatically ### Rate-Limited Chest Warning - New config options: - `GriefPrevention.Claims.UnprotectedChestWarningCooldownSeconds` — default `300` (5 min) - `GriefPrevention.Claims.UnprotectedChestWarningDistance` — default `100` (blocks) - "This chest is NOT protected" message only repeats after the cooldown expires **or** the player moves farther than the distance threshold from the last warned chest ### Lava Placement Near Claims (`PreventLavaPlaceNearClaims`) - New config option `GriefPrevention.Claims.PreventLavaPlaceNearClaims` — default `true` - When enabled and `MinimumDistance > 0`, lava placement is blocked if within `MinimumDistance` of any claim - Claim owners bypass the check for their own claims - Players with **neighbor trust** on the nearby claim can also place lava - New message: `NoLavaNearClaim` ("You are too close to a claim to do that!") ## Persistence ### Database Schema v11 - New column `alertsenabled` (BOOLEAN DEFAULT 1) in `griefprevention_claimdata` - `SQL_INSERT_CLAIM` updated to include `alertsenabled` - Schema migration auto-adds column if missing ### FlatFile (YAML) - New field `Alerts Enabled` in claim YAML files - Defaults to `true` when reading legacy files without the field ## New Messages (all locales updated) | Key | English Value | |-----------------------|-------------------------------------------------------------------------------| | `NoLavaNearClaim` | "You are too close to a claim to do that!" | | `ClaimAlertsEnabled` | "Alerts enabled for this claim." | | `ClaimAlertsDisabled` | "Alerts disabled for this claim." | | `ClaimAlertsEnabledGlobal` | "Alerts enabled for all claims." | | `ClaimAlertsDisabledGlobal` | "Alerts disabled for all claims." | | `ClaimAlertsUsage` | "Use /claimtogglealerts on\|off to toggle alerts for ALL claims, or stand in a specific claim and try again." | Translated versions added to all 14 bundled locale files (`messages_*.yml`). ## Files Changed ``` M src/main/java/com/griefprevention/commands/UnifiedClaimCommand.java M src/main/java/com/griefprevention/protection/ClaimBoundaryViolationTracker.java M src/main/java/me/ryanhamshire/GriefPrevention/Alias.java M src/main/java/me/ryanhamshire/GriefPrevention/BlockEventHandler.java M src/main/java/me/ryanhamshire/GriefPrevention/Claim.java M src/main/java/me/ryanhamshire/GriefPrevention/DataStore.java M src/main/java/me/ryanhamshire/GriefPrevention/DatabaseDataStore.java M src/main/java/me/ryanhamshire/GriefPrevention/FlatFileDataStore.java M src/main/java/me/ryanhamshire/GriefPrevention/GriefPrevention.java M src/main/java/me/ryanhamshire/GriefPrevention/Messages.java M src/main/java/me/ryanhamshire/GriefPrevention/PlayerData.java M src/main/resources/messages.yml M src/main/resources/messages_*.yml (13 locale files) M src/main/resources/plugin.yml ```

# GriefPrevention3D v18.2.6 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## Highlights ### PvP toggle messages synced in every non-English locale The 16 PvP-toggle message keys introduced in v18.2.5 had only been added to the default `messages.yml` and `messages_en.yml`. The 12 non-English locale files still carried the old single `_NoFee` / `_WithFee` keys and were missing the new split / state / error / usage keys, causing every PvP toggle prompt (confirmation, fee, success, error) to silently fall back to English on a non-English server. This release adds all 16 new keys, with localized translations, in: - `messages_de_DE.yml` (German) - `messages_es.yml` (Spanish) - `messages_fr_FR.yml` (French) - `messages_ja_JP.yml` (Japanese) - `messages_ms_MY.yml` (Malay) - `messages_pl_PL.yml` (Polish) - `messages_pt_BR.yml` (Portuguese - Brazil) - `messages_ru_RU.yml` (Russian) - `messages_tr_TR.yml` (Turkish) - `messages_uk_UA.yml` (Ukrainian) - `messages_zh_CN.yml` (Chinese - Simplified) - `messages_en_PT.yml` (English - Pirate) ### Message keys added | Key | English default | |---|---| | `ConfirmPvpToggleEnabledNoFee` | `Do you want to enable PvP in this {0}?` | | `ConfirmPvpToggleDisabledNoFee` | `Do you want to disable PvP in this {0}?` | | `ConfirmPvpToggleEnabledWithFee` | `Do you want to pay {0} to enable PvP in this {1}?` | | `ConfirmPvpToggleDisabledWithFee` | `Do you want to pay {0} to disable PvP in this {1}?` | | `PvPToggleEnabled` | `PvP enabled in this {0}.` | | `PvPToggleDisabled` | `PvP disabled in this {0}.` | | `PvPToggleEnabledWithFee` | `PvP enabled in this {0} for {1}.` | | `PvPToggleDisabledWithFee` | `PvP disabled in this {0} for {1}.` | | `PvpToggleNotEnabled` | `PvP toggle commands are not enabled.` | | `PvpToggleNotEnabledForClaimType` | `PvP cannot be toggled in this type of claim.` | | `NoPendingPvpToggle` | `No pending PvP toggle to confirm.` | | `PendingPvpToggleExpired` | `Your pending PvP toggle has expired. Please try again.` | | `ConfirmPvpToggleInstruction` | `Type /claim pvp {0} confirm or /claimpvpconfirm to confirm.` | | `PvpToggleUsage` | `Usage: /claim pvp [true|false|on|off] [confirm]` | | `PvpToggleAlreadyEnabled` | `PvP is already enabled in this {0}.` | | `PvpToggleAlreadyDisabled` | `PvP is already disabled in this {0}.` | ## Fixes ### Removes orphan PvP toggle keys from locales The pre-v18.2.5 generic keys are no longer referenced by the plugin (the `/claim pvp` flow now uses the four split `_Enabled` / `_Disabled` variants) and were removed from all 12 non-English locale files so they match the default `messages.yml`: - `ConfirmPvpToggleNoFee` (removed) - `ConfirmPvpToggleWithFee` (removed)

# GriefPrevention3D v18.2.5 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## Features ### Improved `/claim pvp` command UX The PvP toggle command has been significantly refactored for better usability and code clarity. #### Clearer confirmation flow The confirmation messages have been rewritten to be more explicit about what action will be taken: - `ConfirmPvpToggleEnabledNoFee` - "Do you want to enable PvP in this {0}?" - `ConfirmPvpToggleDisabledNoFee` - "Do you want to disable PvP in this {0}?" - `ConfirmPvpToggleEnabledWithFee` - "Do you want to pay {0} to enable PvP in this {1}?" - `ConfirmPvpToggleDisabledWithFee` - "Do you want to pay {0} to disable PvP in this {1}?" Previously all fee/no-fee variants used a single templated message with "enable"/"disable" as a parameter. Now they are separate messages with clear instructions. #### Already-toggled handling Running `/claim pvp true` on a claim where PvP is already enabled now shows a specific message instead of silently succeeding. #### `/claimpvpconfirm` improvements The `/claimpvpconfirm` command now validates that the player still has edit permission for the claim before executing the toggle, and shows proper error messages (`NoPendingPvpToggle`, `PendingPvpToggleExpired`) instead of hardcoded English strings. ### Vault economy formatting Added `VaultEconomyFormatting` utility class that formats currency amounts using the active Vault economy provider. When Vault is available, it uses `economy.format()` for locale-aware currency display; falls back to `String.format("%.2f", amount)` otherwise. Fee amounts in PvP toggle confirmation and success messages now use this formatted display instead of raw `String.format("%.2f", fee)`. ## Technical changes - Refactored `handlePvpCommand()` into smaller helper methods: `parsePvpToggleArg()`, `getPvpToggleContext()`, `getPvpToggleClaimTypeLabel()`, `sendPvpToggleConfirmation()`, `chargePvpToggleFee()`, `sendPvpToggleSuccess()`, `clearPendingPvpToggle()` - Introduced `PvpToggleContext` inner class to bundle fee and claim-type info - Added `VaultEconomyFormatting` utility with `format(Server, double)` and `format(Economy, double)` overloads - Updated `DataStore.createClaim()` to inherit PvP state when `config_pvp_subdivisionPvpState` is `INHERIT` - Updated `handleClaimPvpConfirmCommand()` to validate edit permission and use message enums - Removed `PvPToggleSuccess`/`PvPToggleSuccessWithFee` message keys (replaced by separate enable/disable variants) - Added `ClaimLabel`, `SubdivisionLabel` in Messages enum and resource files - Added `griefprevention.claimpvp` permission node as a child of `griefprevention.claims` - Fixed missing `&r` reset code in `startups.txt` template

# GriefPrevention3D v18.2.4 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## Features ### PvP toggle command improvements Fixed several bugs in the `/claim pvp` command to improve usability and reliability. #### Optional confirm suffix The `confirm` suffix is now optional. Players can use: - `/claim pvp true` - Shows confirmation message, then type `/claim pvp true confirm` to execute - `/claim pvp true confirm` - Executes immediately without confirmation prompt This matches the behavior of other confirmation-based commands in the plugin. #### Fixed empty argument handling Previously, running `/claim pvp` with no arguments would throw an error. It now shows proper usage: ```text Usage: /claim pvp <true|false> [confirm] ``` #### Improved localization Added translatable messages for PvP state descriptions: - `PvPToggleEnable` - Localizable "enable" text - `PvPToggleDisable` - Localizable "disable" text These are used in confirmation messages instead of hardcoded English text, allowing proper translation. #### Fixed placeholder documentation Added proper placeholder documentation to confirmation messages: - `ConfirmPvpToggleNoFee` - Documents placeholders {0}, {1}, {2}, {3} - `ConfirmPvPToggleWithFee` - Documents placeholders {0}, {1}, {2}, {3}, {4} ### PvP prevention now actually works The per-claim PvP toggle was previously stored but not enforced. The `claimIsPvPSafeZone()` method now checks the `pvpEnabled` field before falling back to global config settings. When PvP toggling is enabled and a claim has `pvpEnabled = false`, it is treated as a PvP safe zone and prevents PvP combat regardless of global config settings. ### Startup header improvements Minor formatting improvements to the startup header display: - Updated `PluginTag` message to use newline instead of space for better formatting - Removed extra newline from `startups.txt` template - Removed extra newline from `StartupHeader.buildStartupBlock()` method ### Shaped claim merge improvements Improved the merge claims feature when working with shaped claims. When merging shaped claims while standing in the nibbed (indented) portions, the system now creates a rectangle between the claims instead of using a Manhattan path. This approach follows the Minkowski sum principle, resulting in more intuitive and efficient claim merging for complex shaped claims. Added new fields to track merge state for shaped claims: - `mergeSecondEdgeIndex` - Tracks the second claim's edge index for shaped claim merge - `mergeFirstDepthPoint` - Player position when first claim merge edge was selected (for nib depth) - `mergeSecondDepthPoint` - Player position when second claim merge edge was selected (for nib depth) ## Technical changes - Added `PvPToggleEnable` and `PvPToggleDisable` messages to Messages enum - Updated `handlePvpCommand()` to handle optional confirm suffix - Added empty argument check in `handlePvpCommand()` - Updated confirmation messages to use translatable state strings - Updated placeholder documentation in `ConfirmPvpToggleNoFee` and `ConfirmPvPToggleWithFee` - Modified `claimIsPvPSafeZone()` to check `pvpEnabled` field before global config - Updated `PluginTag` message format in Messages.java - Removed extra newline from startups.txt template - Removed extra newline from `StartupHeader.buildStartupBlock()` method - Updated plugin.yml usage for claimpvp command to show `[confirm]` as optional

# GriefPrevention3D v18.2.3 **Wiki:** [GriefPrevention3D Wiki](https://github.com/castledking/GriefPrevention3D/wiki) ## Fixes ### `/claim pvp` subcommand now works in the alias system The `/claim pvp` subcommand was missing from both the alias configuration and the unified command handler. Running `/claim pvp` returned "Unknown subcommand" and the generated `alias.yml` had no PvP section. **Fix:** - Added `ClaimPvp` entry to `Alias.java` with default alias YAML (commands: `[pvp]`, standalone: `[claimpvp]`) - Registered the `pvp` subcommand in `UnifiedClaimCommand.java` with tab completion for `true`/`false`/`confirm` - Registered `ClaimPvp` standalone alias so the alias system can manage `/claimpvp` - The `config_pvp_toggleCost*` gate remains — admins must opt in by setting `Claims.PvPToggle.Claim.Enabled: true` (or Subdivision) in `config.yml` ### Startup console output is now a single log line The startup header was previously split into individual `sendMessage()` calls per line, producing separate timestamps. It now sends the entire block as one call, keeping the console log clean. ## Features ### Malay (ms_MY) locale support The existing `messages_ms_MY.yml` file was not registered in `MessageLocalization.BUNDLED_LOCALE_FILES` or `SUPPORTED_LOCALE_CODES`. It is now active. Players and servers with `config_locale: ms_MY` will receive localized messages including the new startup strings. ### Per-locale startup console messages Four new message keys were added to `Messages.java`: | Key | English default | |---|---| | `AuthorTag` | `&7by castledking, RoboMWM and BigScary` | | `PluginTag` | `&6The self-service anti-griefing plugin for Minecraft servers &b- Now with full 3D subdivisions` | | `StartupDetails` | `&fStartup details: {0}` | | `BootFinished` | `&7Boot finished in: &a{0}` | The startup header in `startups.txt` was redesigned around these messages. Instead of hardcoding locale-specific text in each `en1[]` / `es1[]` / `pt1[]` block, the file now contains only the locale-agnostic ASCII art (p1/p2/p3) with a single `${startup}` placeholder. The combined startup block — author, plugin tag, details header, and boot time — is built at runtime from the configured locale's translations. This means all 13 supported locales now have localized startup output: | File | Language | |---|---| | `messages_en.yml` | English | | `messages_es.yml` | Spanish | | `messages_pt_BR.yml` | Portuguese (Brazil) | | `messages_fr_FR.yml` | French | | `messages_de_DE.yml` | German | | `messages_ru_RU.yml` | Russian | | `messages_zh_CN.yml` | Chinese (Simplified) | | `messages_ja_JP.yml` | Japanese | | `messages_ms_MY.yml` | Malay | | `messages_pl_PL.yml` | Polish | | `messages_tr_TR.yml` | Turkish | | `messages_uk_UA.yml` | Ukrainian | | `messages_en_PT.yml` | English (Pirate) | Adding or customizing startup text for any locale is now a one-line change in the corresponding `messages_XX.yml` — no need to edit `startups.txt` or the `StartupHeader.java` code. ## Technical changes - `Alias.java`: Added `ClaimPvp` enum entry with YAML defaults and subcommand arguments - `UnifiedClaimCommand.java`: Registered `pvp` subcommand, standalone alias, `handlePvp()` delegating to `plugin.handleClaimPvpCommand()`, and `createPvpTabExecutor()` with tab completion - `MessageLocalization.java`: Added `messages_ms_MY.yml` to `BUNDLED_LOCALE_FILES` and `ms_MY` to `SUPPORTED_LOCALE_CODES` - `Messages.java`: Added `AuthorTag`, `PluginTag`, `StartupDetails`, `BootFinished` with docs - `StartupHeader.java`: Rewrote to build `${startup}` from locale messages; removed `${details}` / `${startup.time}` / `${LANG_CODE}` replacements (now part of the combined block); added locale-fallback-to-any-entry for p1/p2/p3; removed `COL_WIDTH` and `formatLine`/`pad` dead code - `startups.txt`: Stripped 9 locale-specific entries (en1-3, es1-3, pt1-3); only p1/p2/p3 remain with `${startup}` placeholder - `messages_XX.yml` (all 13 locales + root): Added `AuthorTag`, `PluginTag`, `StartupDetails`, `BootFinished` with localized translations - `GriefPrevention.java`: `displayEnabledHeader()` sends one combined `sendMessage()` instead of splitting by newline

# GriefPrevention3D v18.2.2 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## Features ### PvP can now be toggled per claim and subdivision Added a new `/claim pvp` command that allows claim owners to enable or disable PvP inside their claims. The command works in both top-level claims and subdivisions, allowing different PvP rules for individual subdivisions if desired. ```text /claim pvp <true|false> confirm ``` A standalone alias is also available: ```text /claimpvp <true|false> confirm ``` Like `/abandonclaim`, the command requires a `confirm` suffix before making any changes. ### Configurable claim and subdivision support PvP toggling is disabled by default and can be enabled independently for main claims and subdivisions. ```yaml Claims: PvPToggle: Claim: Enabled: true Price: 0.0 Subdivision: Enabled: true Price: 0.0 DefaultState: INHERIT ``` Each scope has its own configurable economy cost, allowing servers to charge different prices (or no price at all) for claim and subdivision PvP changes. ### Subdivision inheritance New subdivisions can either inherit their parent claim's current PvP state or always use a configured default. **`INHERIT` (default)** - New subdivisions copy the parent claim's current PvP state. - Existing subdivisions are unaffected if the parent is changed later. **`DEFAULT`** - Every new subdivision starts with the configured default PvP state regardless of its parent. ### Economy integration If a toggle price greater than `0` is configured: - Requires Vault and a supported economy plugin. - Players must have enough money before confirming. - Payment is only taken after confirmation. - Clear error messages are shown if payment fails. ### Persistence The PvP state is persisted across server restarts in both flatfile and database storage. ### Alias system support The `/claim pvp` subcommand is fully integrated with the alias system: - Available as `/claim pvp` through the unified command handler - Standalone `/claimpvp` command can be disabled via `standalone: false` in alias.yml - Tab completion support for `true`/`false` arguments ## Technical changes - Added `Claim.pvpEnabled` field to store per-claim PvP state (default: `true`) - Added configurable PvP toggle settings under `Claims.PvPToggle` in config.yml - Added `handlePvpCommand()` for unified command handling - Registered `/claim pvp` subcommand in the unified command handler - Added standalone `/claimpvp` command in plugin.yml - Added Vault economy integration with balance checks and withdrawals - Added `pvpenabled` column to database schema (schema version 10) - Added `PvP Enabled` key to flatfile YAML serialization - Added pvpEnabled loading in both flatfile and database storage - Updated alias.yml with `/claim pvp` subcommand and `/claimpvp` standalone - Added "merge" option to `/claim mode` in alias.yml documentation - Updated wiki documentation (Commands.md, Key-Features.md, Configuration.md)

# GriefPrevention3D v18.2.1 **Wiki:** [GriefPrevention3D Wiki](https://github.com/castledking/GriefPrevention3D/wiki) ## Fixes ### `/claimlist` no longer shows duplicate claims; claim blocks no longer go negative Fixed a bug where a player's claims could appear duplicated in `/claimlist` and their available claim blocks would drift negative. The issue affected players after logout or server restart (whenever their `PlayerData` was freshly created). **Root cause:** `DataStore.addClaim()` added the claim to the global `this.claims` list first, then called `ownerData.getClaims()`. When the player's `PlayerData` was newly created (claims vector == null), `getClaims()` lazy-initialized by scanning `this.claims` — finding the same claim — then the caller added it a **second** time. Each duplicate caused `getRemainingClaimBlocks()` to subtract the claim's area twice, and `/claimlist` showed the claim twice. The same bug existed in `changeClaimOwner()` (claim transfer). **Fix:** Guard both `.add()` calls with a `contains()` check so a claim is never double-added to the owner's vector after lazy init already picked it up. - `DataStore.java`: `addClaim()` and `changeClaimOwner()` now check `!ownerClaims.contains(claim)` before adding.

# GriefPrevention3D v18.2.0 **Wiki:** [GriefPrevention3D Wiki](https://github.com/castledking/GriefPrevention3D/wiki) ## Features ### DatabaseDataStore now matches FlatFileDataStore feature-for-feature `DatabaseDataStore` was missing three persisted fields that `FlatFileDataStore` has supported for some time. Database users will now get identical behaviour. #### 3D claims (`is3d`) The `is3d` boolean is now persisted in the `griefprevention_claimdata` table. Claims created with 3D enabled (subdivisions that respect Y boundaries) will correctly reload after a restart. - Schema migration v7: `ALTER TABLE griefprevention_claimdata ADD COLUMN IF NOT EXISTS is3d BOOLEAN DEFAULT 0` - `DatabaseDataStore.java`: passes `is3d` from `ResultSet` to `new Claim(…)` instead of hardcoding `false` #### Shaped claims (`shapecorners`) Shaped claim geometry (non-rectangular orthogonal polygons) is now serialized to a `shapecorners TEXT` column as semicolon-delimited `x,z` pairs. Existing rectangular claims are unaffected. - Schema migration v8: `ALTER TABLE griefprevention_claimdata ADD COLUMN IF NOT EXISTS shapecorners TEXT DEFAULT ''` - `DatabaseDataStore.java`: `serializeCornersForDb()` / `parseCornersFromDb()` helpers convert between `List<OrthogonalPoint2i>` and the DB text format - Reads are passed to `claim.setShapedCorners()` on load #### Modified date (`modifieddate`) Each claim's last-modified timestamp is stored as a `BIGINT` (epoch millis). On first save after migration, existing claims without a timestamp will get the current time. - Schema migration v9: `ALTER TABLE griefprevention_claimdata ADD COLUMN IF NOT EXISTS modifieddate BIGINT DEFAULT 0` - `DatabaseDataStore.java`: `claim.modifiedDate` is set from `modifieddate` column on load (when > 0) and written on every save ### Technical details | Schema version | What changed | |---|---| | 7 | Added `griefprevention_claimdata.is3d` | | 8 | Added `griefprevention_claimdata.shapecorners` | | 9 | Added `griefprevention_claimdata.modifieddate` | | 10 | Current `latestSchemaVersion` | All migrations use `ALTER TABLE … ADD COLUMN IF NOT EXISTS` — zero-touch upgrade for existing database users.

# GriefPrevention3D v18.1.10 **Wiki:** [GriefPrevention3D Wiki](https://github.com/castledking/GriefPrevention3D/wiki) ## Fixes ### Locale resolution no longer falls back to `en_PT` for English players Fixed a bug where players with a standard English client locale (`en_US`, `en_GB`) could receive messages in Pirate Speak (`en_PT`) instead of plain English. **Root cause:** The per-player locale resolver's prefix-matching fallback iterated over a `HashMap` and returned the first key sharing the same 2-letter language prefix. Since both `en` and `en_PT` start with `en`, players whose client locale didn't exactly match a loaded locale could non-deterministically receive pirate speak. **Fix:** The prefix fallback now prefers the exact base locale code (`en`) over variants (`en_PT`). A variant is only used when no exact base match exists. English-speaking players will always get `en`, and `en_PT` is only selected when the player's client locale is explicitly `en_PT`. - `DataStore.java`: `resolvePlayerLocale()` prefix loop now tracks exact-base and variant matches separately, returning the exact base first.

# GriefPrevention3D v18.1.9 **Wiki:** [GriefPrevention3D Wiki](https://github.com/castledking/GriefPrevention3D/wiki) ## New Features ### 9 New Locale Files Eight new languages added, expanding from 3 to 12 supported locales: | Locale | Language | | ------ | -------- | | `fr_FR` | French | | `de_DE` | German | | `ru_RU` | Russian | | `zh_CN` | Chinese (Simplified) | | `ja_JP` | Japanese | | `pl_PL` | Polish | | `tr_TR` | Turkish | | `uk_UA` | Ukrainian | | `en_PT` | English (Pirate Speak ☠️) | Per-player locale will now automatically match the user's Minecraft client language setting for all new locales. All locale files are bundled — no manual file copying required. ### Allium Integration for Tab Completion When the [Allium](https://github.com/castledking/Allium) plugin (with PartyManager) is installed and enabled, tab completions for player names now use Allium's visibility-aware list instead of Bukkit's raw online player list. This means: - **Genuinely vanished players** are excluded from tab completion - **Distance-hidden players** (in party by distance) are still included - Falls back to default Bukkit behavior when Allium is absent or disabled Implemented via reflection — zero hard dependency on Allium. ### Manage-Permission Subdivision Creation Players with **Manage** permission on a claim can now create subdivisions inside it, even without **Edit** permission. This lets server owners grant subdivision management to trusted players without giving them full build/edit rights over the parent claim. - Works with shovel right-click (both `ClaimToolDispatcher` and `PlayerEventHandler` paths) - The creating player is automatically added as a manager of the new subdivision so they can further subdivide or manage permissions (cascading trust) - Subdivision visualization now correctly draws the initial zone marker for non-3D subdivisions ## Fixes - **Missing visualization on non-3D subdivision start**: Fixed a bug where starting a subdivision in normal (2D) mode would not show the initial block visualization

# GriefPrevention3D v18.1.8 **Wiki:** [GriefPrevention3D Wiki](https://github.com/castledking/GriefPrevention3D/wiki) ## New Features ### Per-Player Locale Players now receive messages in their own language based on their Minecraft client locale — no administrator effort required. Enabled by default with `PerPlayerLocale: true` in config.yml: - **Spanish** client locale (`es_*`) → Spanish messages - **Portuguese** client locale (`pt_*`) → Brazilian Portuguese messages - **All other locales** → server's configured language (`GriefPrevention.Locale`, default `en`) - Console output always uses the server's configured language No additional locale files need to be copied — the plugin bundles all supported translations (`en`, `es`, `pt_BR`). Disable with `PerPlayerLocale: false` to revert to the old behavior where every player sees the same language. ### Plugin Rename to GriefPrevention3D - Plugin name changed from `GriefPrevention` to `GriefPrevention3D` and JAR renamed accordingly. - Added `provides: [GriefPrevention]` so servers with plugins depending on the old name continue to work. ## Fixes - **Self-intersection false positives for C/notch/L shaped claims**: Polygon validation now passes known polygon corners to intersection detection so legitimate vertex touches (where boundary segments share a corner on the same axis line) are not flagged as self-intersections. This allows valid orthogonal shapes like C, notch, and L profiles that were previously rejected.

# GriefPrevention3D v18.1.7 **Wiki:** [GriefPrevention3D Wiki](https://github.com/castledking/GriefPrevention3D/wiki) ## Highlights - **Cross-Claim Shaped Merge** — Use `/shapedclaims` to reshape your claim and merge it into a neighboring claim. Click the boundary of your claim, draw a path that overlaps the target claim, and close the path. The tool handles the merge automatically — overlapping land is claimed, disconnected components are bridged with a Manhattan path, and the target claim is deleted. - **`/mergeclaims` Command** — Standalone command that toggles merge mode on your shovel. Visualize nearby claims with a sneak-click, then click the boundary of your target claim to select it. Works with `/claim mode merge` as well. - **`/claim mode merge`** — New merge mode option for the shovel, accessible via `/claim mode merge`, `/mergeclaims`, or `/shapedclaims` (which enters merge mode automatically when drawing cross-claim paths). - **Nearby Claim Visualization** — Nearby claims are now highlighted with visible borders during shaped edit and merge operations, making it easy to see which claims can be merged into.

# GriefPrevention3D v18.1.6 **Full Release Notes:** [v18.1.6.md](https://github.com/castledking/GriefPrevention3D/blob/master/.release/latest/v18.1.6-full.md) ## Highlights - **Minimum Distance Between Claims** — New config option `MinimumDistance` (default 0 = disabled). When set, players can't create claims within the configured distance of other claims. Conflicting claims are visualized with a CONFLICT_ZONE boundary. - **Neighbor Trust** — New trust level that lets specific players bypass minimum distance. Use `/claim trust <player> neighbor` or `/neighbortrust <player>`. Toggle per-claim allow-all with `/claim distance toggle`. - **Auto-Neighbor Trust** — Existing claims too close together automatically grant neighbor trust to each other. Auto-removed when claims are abandoned. - **Granular Permissions** — 27 individual permissions (e.g. `griefprevention.neighbortrust`, `griefprevention.checkclaimdistance`) now available under `griefprevention.claims`. All default to `true` via parent permission. - **New Commands** — `/claim distance check` (visualize nearby claims), `/claim distance toggle` (per-claim bypass), `/neighbortrust` (alias: `/distancetrust`). - **Translations** — Spanish (`messages_es.yml`) and Portuguese-BR (`messages_pt_BR.yml`) updated with all new messages.

# GriefPrevention3D v18.1.5 **Wiki:** [GriefPrevention3D Wiki](https://github.com/castledking/GriefPrevention3D/wiki) ## Fixes - **Startup banner on pre-1.16 servers**: Replaced all hex color codes (`&#RRGGBB`) in `startups.txt` headers and detail lines with legacy Minecraft color codes (`&a`, `&c`, `&7`, `&6`, etc.) so the banner displays correctly on servers before 1.16 where `§x` is not supported. - **Claim selection session support added for `/transferclaim`, `/checkclaimexpiry`, `/restrictsubclaim`**: These commands now respect an active claim resize/selection session, targeting the selected claim instead of the claim at the player's location. [View Docs](https://github.com/castledking/GriefPrevention3D/wiki/Key-Features#claim-selection) - **IncompatibleClassChangeError on pre-1.16 servers**: Wrapped `player.getOpenInventory()` call in try-catch for `IncompatibleClassChangeError` since `InventoryView` is a class (not interface) before 1.16. - **Add Player to SaveTrappedPlayerEvent (#2617)**: Merged upstream commit that adds the trapped `Player` reference to `SaveTrappedPlayerEvent` for downstream API consumers.

# GriefPrevention3D v18.1.4 **Wiki:** [GriefPrevention3D Wiki](https://github.com/castledking/GriefPrevention3D/wiki) ## Fixes ### YAML string escaping in messages_en.yml Fixed incorrect YAML quoting across `messages_en.yml`. Strings using double quotes with embedded literal quotes (`"`...`\"...\"...`"`) were replaced with single-quoted strings and proper apostrophe escaping (`''`). This eliminates YAML parser warnings and ensures message text renders correctly. Example fix: ```yaml # Before (double-quoted with escaped quotes) NoDamageClaimedEntity: "That belongs to {0}." NoDeletePermission: "You don't have permission to delete claims." # After (single-quoted, internal quotes escaped with '') NoDamageClaimedEntity: 'That belongs to {0}.' NoDeletePermission: 'You don''t have permission to delete claims.' ``` ### MessageLocalization package relocation `MessageLocalization.java` moved from `me.thiagorigonatti.griefprevention.util` to `me.ryanhamshire.GriefPrevention`, removing stale imports for `InputStream`, `Properties`, `StandardCharsets`, and `List`. The locale normalization utility (`normalizeLocale`) and language folder initializer (`ensureLanguageFiles`) now live in the main package, consistent with the rest of the localization loading in `DataStore.loadMessages()`. ## Features ### Sulfur cube claim protection (Minecraft 26.2+) Added full claim-based protection for the new Sulfur Cube mob introduced in Minecraft 26.2 "Chaos Cubed". Since sulfur cubes use a unique physics-based push mechanic (not standard entity damage events), two intercept points are required: **Punch (left-click) protection** — `SulfurCubeHandler.java` - Listens for `PlayerAnimationEvent` (ARM_SWING) and raycasts for `SULFUR_CUBE` entities in the player's line of sight - Checks Build permission in the claim at the cube's location - If denied, the push is undone by teleporting the cube back to its original position and resetting velocity on the next tick - Sends existing `NoDamageClaimedEntity` message - Handles both survival (3-block) and creative (5-block) reach distances **Right-click protection** — `PlayerEventHandler.onPlayerInteractEntity` - Blocks block insert/swap/retrieve interactions on sulfur cubes inside claims without Container permission - Gated behind `config_claims_preventTheft`, consistent with Animals/Fish/CopperGolem protection - Uses the same `NoDamageClaimedEntity` + `IgnoreClaimsAdvertisement` message pattern **Version compatibility**: No version detection needed. All checks use `EntityType.name().equals("SULFUR_CUBE")` string comparison. On pre-26.2 servers, no entity will match — the handlers are no-ops. ## Compatibility | Category | Support | | ------------------ | ------------- | | Minecraft Versions | 1.8.8 -> 26.2.x | | Minimum Java | Java 8 | | Bukkit API Target | 1.13 |

# GriefPrevention3D v18.1.3 **Wiki:** [GriefPrevention3D Wiki](https://github.com/castledking/GriefPrevention3D/wiki) ## Features ### Locale-based message localization Messages are now loaded from YAML files based on the `GriefPrevention.Locale` config setting, replacing the single `messages.yml` approach. **File layout:** - `GriefPreventionData/messages_{locale}.yml` — active locale files (e.g., `messages_en.yml`, `messages_es.yml`, `messages_pt_BR.yml`) - `GriefPreventionData/Lang/` — reference copies extracted from JAR on every reload (users copy from here) - `GriefPreventionData/messages.yml` — legacy file, still supported as fallback **Priority order:** 1. `messages_{locale}.yml` matching `config_locale` — respects user's locale setting 2. `messages.yml` — legacy fallback for migrated servers 3. Auto-detect — scans for any `messages_*.yml` if config locale file is missing 4. Extract from JAR — creates the file automatically if nothing exists **Auto-detection:** If `config_locale` is set to `en` but only `messages_es.yml` exists, the plugin auto-switches to `es` and logs: ``` Locale 'en' didn't match provided messages_es.yml. Auto-switched to 'es' ``` **Key merging:** On every startup, missing keys from the JAR bundled version are merged into the user's locale file and saved, so new messages are automatically available after JAR updates. ### Startup header with localized details The server startup header now displays localized detail lines with consistent two-column alignment: ``` Platform: Paper 26.1.2 3D Subdivisions: ON 3D Admin Claims: ON Nested Claims: OFF Shaped Claims: OFF Locale: es Messages loaded: 276 Storage: File Claims Loaded: 0 ``` - Detail block generated in code via `${details}` placeholder — consistent formatting across all languages - `TextColor` utility consolidates `$`/`&` color codes and `&#RRGGBB`/`#RRGGBB` hex to Minecraft legacy format - `PlatformDetection.getServerVersion()` shows actual server platform (e.g., "Paper 26.1.2") instead of boolean ON/OFF - Startup header locale matches `config_locale` (with fallback: `pt_BR` → `pt`) ### MessagesLoaded message New `MessagesLoaded` enum constant outputs localized "Messages loaded: N" in the startup details via `${locale.info}` placeholder. ### Claim expiration permissions Two new permissions added to `plugin.yml`: - `griefprevention.checkclaimexpiry` — allows players to check claim expiration status - `griefprevention.dontexpire` — prevents a player's claims from expiring ## Compatibility | Category | Support | | ------------------ | ------------- | | Minecraft Versions | 1.8.8 -> 26.1.x | | Minimum Java | Java 8 | | Bukkit API Target | 1.13 | ## Migration No data migration is required. Existing `messages.yml` files continue to work as legacy fallback. To use localized messages, copy `messages_{locale}.yml` from `GriefPreventionData/Lang/` to `GriefPreventionData/` and set `GriefPrevention.Locale` in config.yml.

# GriefPrevention3D v18.1.2 **Wiki:** [GriefPrevention3D Wiki](https://github.com/castledking/GriefPrevention3D/wiki) ## Feature ### Permissiontrust users can now toggle claim subdivision restrictions Previously, only the claim owner could use `/restrictsubclaim` on the main claim to toggle whether new subdivisions inherit permissions by default. Now, players with `Manage` trust (granted via `/permissiontrust`) can also toggle this flag. **Before:** The command checked only for owner UUID match or the `griefprevention.adminclaims` permission. **After:** The command also checks for `Manage` trust level via `claim.checkPermission(player, ClaimPermission.Manage, null)`, which grants access to: - The claim owner (implicitly) - Players given `/permissiontrust` by the owner - Players with the `griefprevention.deleteclaims` bypass permission The other claim flag commands (`/claimexplosions`, `/witherexplosions`) already required only `Build` trust, which `Manage` grants — so those were already accessible to permissiontrust users without changes. ## Compatibility | Category | Support | | ------------------ | ------------- | | Minecraft Versions | 1.8.8 -> 26.1.x | | Minimum Java | Java 8 | | Bukkit API Target | 1.13 | ## Migration No data migration is required.

# GriefPrevention3D v18.1.1 **Wiki:** [GriefPrevention3D Wiki](https://github.com/castledking/GriefPrevention3D/wiki) Thanks to [@thiagorigonatti](https://github.com/thiagorigonatti) for [fixing this issue](https://github.com/thiagorigonatti/GriefPrevention/commit/1da25d5be6cb5eefd266a3e93b2b3f1a6634496b)! ## Upstream Issue Fixes ### Chest force-rotation near claim borders When placing a chest near a claim border, the plugin's chest connection logic could select a neighboring chest as a valid connection target based solely on claim ownership, without checking whether the two chests could naturally form a double chest in vanilla Minecraft. This caused the plugin to force-rotate the existing chest's facing direction to match the placed chest — producing a visual and functional state that would never occur naturally. **Before:** The plugin called `setFacing()` on the neighboring chest, rotating it to match the placed chest even when the neighbor was oriented in a different direction. **After:** The plugin: - Only considers a neighboring chest as a valid connection target if both chests face the same direction (matching vanilla behavior). - Verifies that both chests can connect on the relevant faces before establishing a double chest. - Resets the placed chest to `SINGLE` before reconnecting, preventing stale connection state. - Removes all `setFacing()` calls on existing chests — the plugin no longer force-rotates neighbors. ## Compatibility | Category | Support | | ------------------ | ------------- | | Minecraft Versions | 1.8.8 -> 26.1.x | | Minimum Java | Java 8 | | Bukkit API Target | 1.13 | ## Migration No data migration is required. ## See Also - [Fix commit](https://github.com/thiagorigonatti/GriefPrevention/commit/1da25d5be6cb5eefd266a3e93b2b3f1a6634496b) by @thiagorigonatti

# GriefPrevention3D v18.1.0 **Wiki:** [GriefPrevention3D Wiki](https://github.com/castledking/GriefPrevention3D/wiki) Thanks to [@thiagorigonatti](https://github.com/thiagorigonatti) for [fixing this issue](https://github.com/GriefPrevention/GriefPrevention/issues/2611)! ## Upstream Issue Fixes ### Inconsistent chest connection choice near claim borders (`#2611`) When placing a chest near a claim border with two possible single chest neighbors (one inside the claim and one outside), Minecraft's natural double-chest connection priority sometimes chose the wrong side, resulting in a double chest that crossed the claim boundary. **Before:** The plugin detected the cross-claim connection and forcibly split both chests to `SINGLE`, which could break valid connections and produce inconsistent behavior depending on placement direction. **After:** The plugin: - Detects which side Minecraft already connected to and checks whether that connection crosses a claim boundary. - If the connected side is denied but another valid single chest exists inside the same claim, the plugin reconnects the placed chest to the allowed side, forming a proper double chest within the claim. - If no valid connection exists, the cross-claim double chest is split cleanly. - Handles normal vs. trapped chest type mismatches and only considers left/right sides for valid connection faces. This also fixes visual ghost blocks on the denied connection side. ## Compatibility | Category | Support | | ------------------ | ------------- | | Minecraft Versions | 1.8.8 -> 26.1.x | | Minimum Java | Java 8 | | Bukkit API Target | 1.13 | ## Migration No data migration is required. ## See Also - [Issue #2611](https://github.com/GriefPrevention/GriefPrevention/issues/2611) — Inconsistent chest connection choice near claim borders - [Fix commit](https://github.com/thiagorigonatti/GriefPrevention/commit/b0773e58997bf1d47a3368a9f726a84b1aae1d29) by @thiagorigonatti

# GriefPrevention3D v18.0.10 **Wiki:** [GriefPrevention3D Wiki](https://github.com/castledking/GriefPrevention3D/wiki) Thanks to [@thiagorigonatti](https://github.com/thiagorigonatti) for [fixing these issues](https://github.com/GriefPrevention/GriefPrevention/pull/2608)! ## Upstream Issue Fixes ### Placing a chest next to a claimed double chest breaks the double chest (`#2606`) **Before:** Placing a single chest outside a claim adjacent to a double chest fully inside the claim would forcibly split the double chest into two singles — even though no cross-claim double chest was actually formed. **After:** The double chest is left untouched. Only adjacent single chests are candidates for the cross-claim split logic; existing double chests inside the claim is preserved. The fix adds a guard that skips neighboring chests that are not `Chest.Type.SINGLE`, preventing modifications to existing valid double chests fully inside a claim. ### Single chests on claim borders can be extended into double chests from outside claims (`#2609`) **Before:** A player without build permission could place a chest outside an admin claim next to a claimed single chest, and the claimed chest would be extended into a double chest crossing the claim boundary. This happened because both wilderness and admin claims have a `null` owner ID, and the boundary check treated them as the same owner. **After:** The chests are kept as separate single chests. A `sameClaimOwner` helper uses reference equality for null claims, ensuring wilderness and admin claims are only considered the "same owner" when both are literally null (both wilderness). ## Compatibility | Category | Support | | ------------------ | ------------- | | Minecraft Versions | 1.8.8 -> 26.1.x | | Minimum Java | Java 8 | | Bukkit API Target | 1.13 | ## Migration No data migration is required. ## See Also - [Issue #2606](https://github.com/GriefPrevention/GriefPrevention/issues/2606) — Double chest split bug - [Issue #2609](https://github.com/GriefPrevention/GriefPrevention/issues/2609) — Admin claim chest boundary bug - [PR #2608](https://github.com/GriefPrevention/GriefPrevention/pull/2608) — Double chest split fix by @thiagorigonatti - [PR #2610](https://github.com/GriefPrevention/GriefPrevention/pull/2610) — Admin claim owner comparison fix by @thiagorigonatti

# GriefPrevention3D v18.0.9 **Wiki:** [GriefPrevention3D Wiki](https://github.com/castledking/GriefPrevention3D/wiki) Thanks to [@thiagorigonatti](https://github.com/thiagorigonatti) for [fixing this issue](https://github.com/GriefPrevention/GriefPrevention/pull/2610)! ## Upstream Issue Fix ### Single chests on claim borders can be extended into double chests from outside claims (`#2609`) **Before:** A player without build permission could place a chest outside a claim adjacent to a single chest inside the claim, and the claimed chest would be extended into a double chest crossing the claim boundary. This was especially exploitable with admin claims: because both wilderness and admin claims have a `null` owner ID, the boundary check treated them as the same owner and allowed the connection. **After:** The chests are kept as separate single chests when the placed chest would connect to a chest in a claim where the player does not have permission. ### What changed (and what v18.0.8 already fixed) The previous release (v18.0.8, porting [PR #2607](https://github.com/GriefPrevention/GriefPrevention/pull/2607)) fixed a related but different bug ([#2606](https://github.com/GriefPrevention/GriefPrevention/issues/2606)): placing a single chest outside a claim adjacent to a double chest *inside* the claim would forcibly split the double chest. That fix added a guard to skip splitting when the placed chest remains `Chest.Type.SINGLE`. However, v18.0.8's port did **not** include the `sameClaimOwner` helper that PR #2607 also introduced. The method still used `Objects.equals(claimOwner, relativeClaimOwner)` to decide whether two chests should be allowed to connect. This comparison returns `true` when both owners are `null`, which means wilderness (`null` owner) and admin claims (`null` owner`) were incorrectly treated as the same owner — allowing cross-claim double chests to form. v18.0.9 ports the missing piece: a `sameClaimOwner` method that uses reference equality for null claims, so that wilderness and admin claims are only considered the "same owner" when they are literally the same object (both null = both wilderness). An admin claim and wilderness are now correctly treated as different, preventing the cross-claim extension. ## Compatibility | Category | Support | | ------------------ | ------------- | | Minecraft Versions | 1.8.8 -> 26.1.x | | Minimum Java | Java 8 | | Bukkit API Target | 1.13 | ## Migration No data migration is required. ## See Also - [Issue #2609](https://github.com/GriefPrevention/GriefPrevention/issues/2609) — Upstream bug report - [PR #2610](https://github.com/GriefPrevention/GriefPrevention/pull/2610) — Upstream fix by @thiagorigonatti - [PR #2607](https://github.com/GriefPrevention/GriefPrevention/pull/2607) — Previous chest fix (v18.0.8) by @thiagorigonatti - [v18.0.8 release notes](v18.0.8.md) — Previous release

# GriefPrevention3D v18.0.8 **Wiki:** [GriefPrevention3D Wiki](https://github.com/castledking/GriefPrevention3D/wiki) Thanks to [@thiagorigonatti](https://github.com/thiagorigonatti) for [fixing this issue](https://github.com/GriefPrevention/GriefPrevention/pull/2607)! ## Upstream Issue Fix ### Placing a chest next to a claimed double chest breaks the double chest (`#2606`) **Before:** Placing a single chest outside a claim adjacent to a double chest fully inside the claim would forcibly split the double chest into two singles — even though no cross-claim double chest was actually formed. **After:** The double chest is left untouched when the placed chest remains single. The root cause was in `denyConnectingDoubleChestsAcrossClaimBoundary`: it assumed any chest placed near a double chest had connected to it, and unconditionally split both blocks. The fix adds a guard that checks the placed chest's type after placement — if it is still `Chest.Type.SINGLE`, the method returns early and the neighboring double chest is preserved. ## Compatibility | Category | Support | | ------------------ | ------------- | | Minecraft Versions | 1.8.8 -> 26.1.x | | Minimum Java | Java 8 | | Bukkit API Target | 1.13 | ## Migration No data migration is required. ## See Also - [Issue #2606](https://github.com/GriefPrevention/GriefPrevention/issues/2606) — Upstream bug report - [PR #2607](https://github.com/GriefPrevention/GriefPrevention/pull/2607) — Upstream fix by @thiagorigonatti

# GriefPrevention3D v18.0.7 **Wiki:** [GriefPrevention3D Wiki](https://github.com/castledking/GriefPrevention3D/wiki) ## Highlights - **Added PlaceholderAPI trust status placeholders** — Scoreboards can now show whether a player is trusted in the claim or subdivision they are standing in, and what effective trust level they have there. - **Customizable trust-level labels** — The text returned by `%gp3d_trust_level%` is backed by `messages.yml` so servers can localize or restyle the displayed labels. ## PlaceholderAPI ### New Placeholders | Placeholder | Result | | --- | --- | | `%gp3d_is_trusted%` | `true` when the player has at least access trust in the claim/subdivision they are standing in, otherwise `false`. | | `%gp3d_trust_level%` | Returns the player's effective claim trust label for the claim/subdivision they are standing in. | `%gp3d_trust_level%` uses the innermost claim at the player's location, so 3D subdivisions and regular subdivisions are reported instead of only the top-level claim. Effective trust is resolved from highest to lowest: - `Owner` - `Manager` - `Builder` - `Container` - `Access` - `Untrusted` When the player is not standing in any claim, `%gp3d_trust_level%` returns `Unclaimed`. ## New Messages The following `messages.yml` keys are added automatically on startup or reload: ```yaml Messages: PlaceholderTrustLevelUnclaimed: "Unclaimed" PlaceholderTrustLevelOwner: "Owner" PlaceholderTrustLevelManager: "Manager" PlaceholderTrustLevelBuilder: "Builder" PlaceholderTrustLevelAccess: "Access" PlaceholderTrustLevelContainer: "Container" PlaceholderTrustLevelUntrusted: "Untrusted" ``` ## Compatibility | Category | Support | | ------------------ | ------------- | | Minecraft Versions | 1.8.8 -> 26.1.x | | Minimum Java | Java 8 | | Bukkit API Target | 1.13 | ## Migration No data migration is required. Existing `messages.yml` files will receive the new trust-level keys automatically the next time GP3D loads messages.

# GriefPrevention3D v18.0.6 **Wiki:** [GriefPrevention3D Wiki](https://github.com/castledking/GriefPrevention3D/wiki) ## Highlights - **Java 8 Bytecode** — The plugin now compiles to Java 8 bytecode (class version 52.0), allowing it to load on servers running Java 8. This resolves `UnsupportedClassVersionError` on 1.8.8 servers that cannot upgrade beyond Java 8. ## Java 8 Migration - Replaced all `List.of()` / `List.of(a)` / `List.of(a, b, c)` with `Collections.emptyList()` / `Collections.singletonList()` / `Arrays.asList()` - Replaced all `Set.of()` / `Set.of(a)` / `Set.of(a, b)` with `Collections.emptySet()` / `Collections.singleton()` / `Collections.unmodifiableSet(new HashSet<>(Arrays.asList(...)))` - Replaced all `Map.of()` / `Map.of(k, v)` with `Collections.emptyMap()` / `Collections.singletonMap()` - Replaced all `Map.copyOf()` and `List.copyOf()` with `Collections.unmodifiableMap(new HashMap<>(...))` and `Collections.unmodifiableList(new ArrayList<>(...))` - Replaced `String.isBlank()` with `Compat.isBlank()` (trim + isEmpty) - Replaced `String.repeat(n)` with `Compat.repeat()` (StringBuilder loop) - Replaced `Files.writeString()` and `Files.readString()` with `Files.write()` / `Files.readAllBytes()` + String constructor - Replaced `FileReader(File, Charset)` with `InputStreamReader(new FileInputStream(file), charset)` - Replaced `var` with explicit types - Replaced `@Deprecated(since = ...)` / `@Deprecated(forRemoval = true, ...)` with plain `@Deprecated` - Created `Compat` utility class (`com.griefprevention.compat.Compat`) for `isBlank()`, `repeat()` ## Compatibility | Category | Support | | ------------------ | ------------- | | Minecraft Versions | 1.8.8 -> 26.1.x | | Minimum Java | Java 8 | | Bukkit API Target | 1.13 | ## Migration No data migration is required. Existing claims, configs, and player data remain compatible.

# GriefPrevention3D v18.0.5 **Wiki:** [GriefPrevention3D Wiki](https://github.com/castledking/GriefPrevention3D/wiki) ## Highlights - **1.8.8 Runtime Error Fixes** — Fixed several runtime errors that occurred when running the plugin on Minecraft 1.8.8 servers with Java 11+. - **Expanded PvP Configuration** — Added config options to allow container access and respawn anchor usage during PvP combat. - **AFK Accrual Bypass Permission** — Added permission to bypass AFK checks for claim block accrual. - **Claim Tool Bypass Permission** — Added permission to allow creating claims via command without holding the modification tool. ### 1.8.8 Compatibility - Fixed `NoSuchMethodError: EntityExplodeEvent.getExplosionResult()` — Added compatibility methods in `CompatUtil` to safely access explosion results, which don't exist in 1.8.8. - Fixed `NoClassDefFoundError: org.bukkit.event.block.BlockExplodeEvent` — Created separate `BlockExplodeEventHandler` with conditional registration, as this event doesn't exist in 1.8.8 Spigot. - Fixed `NoClassDefFoundError: org.bukkit.event.entity.ItemMergeEvent` — Created separate `ItemMergeEventHandler` with conditional registration, as this event doesn't exist in 1.8.8 Spigot. - Fixed `NoSuchMethodError: PlayerInventory.getItemInMainHand()` — Replaced direct calls with `CompatUtil.getItemInMainHand()` throughout the codebase for 1.8.8 compatibility. ### Netty Compatibility - **Note:** PaperSpigot 1.8.8 has incompatible Netty epoll transport with Java 11+. Users experiencing "Unable to access address of buffer" errors should: - Switch to regular Spigot 1.8.8 (recommended), or - Add `-Dio.netty.transport.noNative=true` JVM flag (may not work on all PaperSpigot builds) ## New Config Options Two new options under `GriefPrevention.PvP` in `config.yml`: | Key | Default | Effect | | --- | --- | --- | | `AllowContainerAccess` | `false` | When `true`, players can access containers (chests, shulker boxes, etc.) during PvP combat. | | `AllowRespawnAnchor` | `false` | When `true`, players can use respawn anchors during PvP combat. | Existing servers will pick up the defaults on first load and have the keys persisted to `config.yml` automatically. ## New Permissions | Permission | Default | Effect | | --- | --- | --- | | `griefprevention.accruals.afkbypass` | `op` | Bypasses the AFK check for claim block accrual. Players with this permission will accrue claim blocks even if they are idle. | | `griefprevention.accruals` | `true` | Controls whether a player receives claim blocks at the configured hourly rate when not AFK. Negating this permission disables accruals entirely. | | `griefprevention.createclaims.toolbypass` | `true` | Bypasses the need to hold the modification tool when creating claims via command. | ## Compatibility | Category | Support | | ------------------ | ------------- | | Minecraft Versions | 1.8.8 -> 26.1.x | | Minimum Java | Java 11 | | Bukkit API Target | 1.13 | ## Migration No data migration is required. Existing claims, configs, and player data remain compatible.

# GriefPrevention3D v18.0.4 **Wiki:** [GriefPrevention3D Wiki](https://github.com/castledking/GriefPrevention3D/wiki) ## Highlights - **Fixed a post-death item pickup regression** — Players who respawned with PvP fresh-spawn immunity could sometimes be unable to pick up their own items until they left and rejoined. ## Bugfixes ### Item Pickup - Fixed `EntityPickupItemEvent` handling so fresh-spawn PvP immunity ends when an immune player picks up an item instead of cancelling the pickup. - This resolves a deadlock where an empty-inventory player was expected to pick up an item to lose immunity, but the pickup itself was blocked by that same immunity state. - Hardened locked death-drop ownership checks to compare player UUIDs directly, avoiding server-version differences in `Player` / `OfflinePlayer` equality behavior. ## Affected Config This regression only applied when PvP fresh-spawn protection was active: ```yaml GriefPrevention: PvP: ProtectFreshSpawns: true ``` No config migration is required. ## Compatibility | Category | Support | | ------------------ | ------------- | | Minecraft Versions | 1.8.8 -> 26.1.x | | Minimum Java | Java 11 | | Bukkit API Target | 1.13 | ## Migration No data migration is required. Existing claims, configs, and player data remain compatible.

# GriefPrevention3D v18.0.3 **Wiki:** [GriefPrevention3D Wiki](https://github.com/castledking/GriefPrevention3D/wiki) ## Highlights - **Public visualization API surface** — Ported the boundary-visualization extension points from the `feature/gpapiaddon-workspace` branch so addons can drive their own claim visuals without reflection. - **Improved 3D claim raytrace logic** — Fixed a regression where the second click of a 3D subclaim resize could snap back to an existing claim corner, causing the resize to no-op or collapse the claim into a 1-block sliver. - **New claim-selection sessions** — Selecting a claim with the modification tool can now keep that claim as the implicit target for follow-up commands (`/trust`, `/abandonclaim`, etc.) until the visualization clears. - **Configurable selected-claim messaging** — Optional alternate selection messages so addons can present richer "claim selected" UX without overriding `ResizeStart`. ## Visualization API The `com.griefprevention.visualization` and `com.griefprevention.events` packages are now part of the supported public API. Addons can: - Listen for `BoundaryVisualizationEvent` to mutate the boundary set, swap the `VisualizationProvider`, or short-circuit drawing entirely. - Implement `VisualizationProvider` / `VisualizationStyle` to render claims using their own block palettes, particle effects, glow displays, or packet pipelines. - Call `BoundaryVisualization.visualizeClaim(...)`, `visualizeArea(...)`, and `visualizeNearbyClaims(...)` directly to trigger the same visuals GP uses internally. - Reuse the built-in `FakeBlockVisualization`, `LegacyFakeBlockVisualization` (1.8.8), `AntiCheatCompatVisualization`, and `GlowingVisualization` (1.19.3+) implementations. See `Public Api.txt` for the full surface and code examples. ## Bugfixes ### Claim Tools - Fixed `ClaimToolDispatcher.handleModificationTool` running the 3D-corner snap raycast unconditionally on the second click of a resize. The snap is now gated by `ClaimToolInteractionState.shouldAttempt3DCornerSelection`, mirroring the `PlayerEventHandler` path. - This resolves the report where dragging a 3D subclaim corner down through transparent blocks (e.g. leaves) did nothing, or occasionally collapsed the claim to a 1-block-thin layer. - Fetches `PlayerData` once before the corner raycast so the gate reflects the actual resize/subdivide state. ## New Config Options Two new options under `GriefPrevention.Claims` in `config.yml`: | Key | Default | Effect | | --- | --- | --- | | `UseClaimSelectSessions` | `true` | When you start resizing a claim with the modification tool, that claim becomes the implicit target for subsequent commands until the visualization reverts. | | `UseClaimSelectedMessages` | `false` | When `true` (and sessions are enabled), replaces the legacy `ResizeStart` instruction with the contextual `ClaimSelected` / `ClaimSelectedTopLevel` / `SubdivisionSelected` messages. | Existing servers will pick up the defaults on first load and have the keys persisted to `config.yml` automatically. ## Compatibility | Category | Support | | ------------------ | ------------- | | Minecraft Versions | 1.8.8 -> 26.1.x | | Minimum Java | Java 11 | | Bukkit API Target | 1.13 | ## Migration No data migration is required. Existing claims, configs, and player data remain compatible. If you want the new selection behavior off, set: ```yaml GriefPrevention: Claims: UseClaimSelectSessions: false UseClaimSelectedMessages: false ``` ## Pairing Pairs with **GPExpansion v1.1.1** for claim block accrual profile controls. Visualization addons targeting the new public surface should depend on `GriefPrevention3D >= 18.0.3`.

# GriefPrevention3D v18.0.2 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## Highlights - **Fixed golden shovel grass-pathing regression** — Right-clicking close grass blocks with the claim modification tool no longer turns them into dirt/grass path blocks while selecting claim corners. - **Fixed path-block visualization snapping** — Dirt path and legacy grass path blocks are no longer treated as transparent for boundary visualization placement. - **Version sync** — Updated release metadata to `18.0.2` in both `pom.xml` and `gradle.properties`. ## Fixes ### Claim Tools - Fixed a regression introduced during legacy compatibility work where claim-tool right-clicks could still trigger the shovel's vanilla block interaction. - Claim creation, resizing, subdivision editing, and claim inspection clicks now consume the right-click before Bukkit applies item behavior to the target block. - This prevents accidental terrain changes when selecting claim corners on grass blocks at close range. ### Visualizations - Fixed Y-snapped visualizations treating `DIRT_PATH` and legacy `GRASS_PATH` as transparent. - Boundary markers now snap above path blocks instead of dropping below them. - The fix applies to standard, legacy, anti-cheat, and glow plus anti-cheat visualization paths. ## Compatibility | Category | Support | | ------------------ | --------------- | | Minecraft Versions | 1.8.8 -> 26.1.x | | Minimum Java | Java 11 | | Bukkit API Target | 1.13 | ## Migration No data migration is required. Existing claims, configs, and player data remain compatible.

# GriefPrevention3D v18.0.1 **Wiki:** [GriefPrevention3D Wiki](https://github.com/castledking/GriefPrevention3D/wiki?utm_source=chatgpt.com) ## Highlights * **Fixed additional 1.8.8 runtime crashes** — Removed more direct references to modern Bukkit enum values from active legacy event paths. * **Added `/gpdebug`** — Server admins can now toggle debug logging without editing config.yml or running `/gpreload`. * **Added release safeguards** — Gradle now fails verification if `gradle.properties` and `pom.xml` versions drift apart. * **Prepared CurseForge automation** — Release workflows now include an optional CurseForge upload target for the GP3D project. ## Fixes ### Legacy Servers (1.8.8) * Fixed `EntityDamageByEntityEvent` and `EntityCombustByEntityEvent` errors caused by direct `AREA_EFFECT_CLOUD` enum access. * Fixed related modern entity checks for shulkers, tridents, raiders, vexes, and evoker fangs so they do not crash older Bukkit runtimes. * Fixed `EntityInteractEvent` crop-trample handling on 1.8.8 by supporting the legacy `SOIL` material name alongside modern `FARMLAND`. * Fixed restore-nature player block classification for farmland across legacy and modern material names. ## Admin Tools * Added `/gpdebug`. * Added `griefprevention.debug`, defaulting to operators and included under `griefprevention.admin.*`. * `/gpdebug` toggles `GriefPrevention.Abridged Logs.Included Entry Types.Debug` immediately and persists it to config.yml. * `/gpdebug on` and `/gpdebug off` are supported for explicit state changes. ## Release Workflow * Added a Gradle `checkPomVersion` verification task to protect addon compatibility metadata in `pom.xml`. * Wired `checkPomVersion` into Gradle's normal `check` lifecycle. * Added CurseForge release automation for project `1552252`. * Added workflow input `run_curseforge` so CurseForge publishing can be enabled or disabled during manual release runs. ## Compatibility | Category | Support | | ------------------ | -------------- | | Minecraft Versions | 1.8.8 -> 26.1.x | | Minimum Java | Java 11 | | Bukkit API Target | 1.13 | ## Migration No data migration is required. Existing claims, configs, and player data remain compatible.

# GriefPrevention3D v18.0 **Wiki:** [GriefPrevention3D Wiki](https://github.com/castledking/GriefPrevention3D/wiki?utm_source=chatgpt.com) ## Highlights * **Single build for all supported versions** — Minecraft 1.8.8 through 26.1.x now supported with one Java 11 build. * **Major legacy compatibility fixes** — Improved claim tool behavior and far-away click handling on older Bukkit/Spigot servers. * **Improved raycast accuracy** — Fixed water click offset issues and inconsistent targeting across versions. * **Removed unstable packet injection path** — Disabled legacy Netty interception that could interfere with commands and interactions on 1.8.8. ## Compatibility | Category | Support | | ------------------ | -------------- | | Minecraft Versions | 1.8.8 → 26.1.x | | Minimum Java | Java 11 | | Bukkit API Target | 1.13 | ## Fixes ### Legacy Servers (1.8.8–1.12.2) * Fixed far-away golden shovel/stick interactions. * Fixed duplicate claim creation paths. * Fixed delayed/bursty camera update behavior. * Fixed incorrect claim tool detection with unrelated items. * Removed problematic Netty packet injection behavior. ### Modern Servers (1.13+) * Fixed Material API compatibility issues. * Fixed water click offset and fluid raycast inconsistencies. * Refactored Java 21-only features for Java 11 compatibility. ## Migration No data migration is required. Existing claims, configs, and player data remain compatible. **Recommended:** Test v18.0 in a production-clone or staging environment before deploying to a live server, especially on heavily customized or legacy setups. ## Pairing Pairs with **GPExpansion v1.1.1** for claim block accrual profile controls. ## Roadmap * Fabric/Forge ports * Additional compatibility improvements * Raycast and visualization performance optimizations

# GriefPrevention3D v17.5.4 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## Highlights - **Restored `ClaimPermission.Inventory` for plugin compatibility** - External plugins like BiggerBarrels that reference `ClaimPermission.Inventory` will no longer crash with `NoSuchFieldError`. - **Added deprecation notice** - `Inventory` is now a deprecated alias for `Container`; plugin developers should migrate to `Container` for future compatibility. ## Bug Fixes The enum constant `ClaimPermission.Inventory` was removed during previous refactoring work, breaking plugins compiled against older versions of GriefPrevention3D. This release restores it as a deprecated alias pointing to `Container`. Plugins affected: - BiggerBarrels (and any plugin referencing `ClaimPermission.Inventory`) The fix ensures backward compatibility while guiding developers toward the new `Container` permission name. ## Pairing This release pairs with **GPExpansion v1.1.1** for the new claim block accrual profile controls documented at: https://github.com/castledking/GPExpansion/wiki/Claim-Block-Accruals ## Migration No data migration required. Existing configs are unchanged. **Note for plugin developers:** Update your code to use `ClaimPermission.Container` instead of `ClaimPermission.Inventory`. The `Inventory` constant will be removed in a future major release.

# GriefPrevention3D v17.5.3 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## Highlights - **Fixed claim resize bug** - Resizing claims via `/resizeclaim` or shovel corner-click no longer incorrectly marks 2D claims as 3D claims. - **Fixed visualization issues after resize** - Claims now display the correct golden terrain-snapped visualization instead of white wool blocks submerged underground. - **Fixed potential claim duplication** - The resize operation now correctly preserves the original claim's 3D status, preventing duplicate or overlapping claim entries. ## Bug Fixes When we added 3D admin claims and 3D initialize points in previous releases, we introduced a new `is3D` parameter to the `DataStore.createClaim()` method. The `resizeClaim()` method was still calling the 12-parameter overload, causing the `dryRun=true` flag to be misinterpreted as `is3D=true`. This meant that resizing any 2D claim would incorrectly mark it as 3D, leading to: - Incorrect visualization (white iron/wool blocks at specific Y levels instead of golden terrain-snapped blocks) - Potential claim duplication or overlapping entries in the chunk cache - Confusion when trying to abandon or reclaim the affected area The fix updates `resizeClaim()` to use the correct 13-parameter overload, preserving the original claim's 3D status. ## Pairing This release pairs with **GPExpansion v1.1.1** for the new claim block accrual profile controls documented at: https://github.com/castledking/GPExpansion/wiki/Claim-Block-Accruals ## Migration No data migration required. Existing configs are unchanged. **Note for affected claims:** If you have claims that were resized while running v17.4.4 through v17.5.2 and are experiencing weird visualization or overlap issues, an admin may need to manually inspect the claims data file to clean up any duplicate entries.

# GriefPrevention3D v17.5.2 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## Highlights - **Removed command registration console noise when debug is off** - Alias and standalone command setup messages now respect the debug logging setting instead of printing every startup. - **Restored legacy claim block command tab completion** - `/acb`, `/adjustbonusclaimblocks`, `/scb`, and related legacy commands now complete online player names and amount arguments again. - **Lowered the declared Bukkit API version to 1.20** - Paper 1.20.6 no longer rejects the plugin for declaring `api-version: 1.21`. ## Bug Fixes The unified command registration path was logging every command initialization and standalone registration at normal info level. Those messages are now routed through debug logging, so production consoles stay quiet unless debug logging is enabled. Legacy standalone claim block commands were registered without tab completion metadata after the unified command work. They now provide player-name completion for player-targeted commands and numeric completion for amount arguments. The plugin descriptor now declares `api-version: "1.20"` instead of `1.21`, allowing the same jar to load on supported 1.20.x servers while still running on newer servers. ## Pairing This release pairs with **GPExpansion v1.1.1** for the new claim block accrual profile controls documented at: https://github.com/castledking/GPExpansion/wiki/Claim-Block-Accruals ## Migration No data migration required. Existing configs are unchanged.

# GriefPrevention3D v17.5.1 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## Highlights - **Added configurable `/claim` and `/aclaim` fallbacks** - `alias.yml` can now define which subcommand runs when a player executes the root command without arguments, such as `fallback: 'help'`. - **Fixed configurable claim help entries** - `ClaimHelpEntry` and `AClaimHelpEntry` in `messages.yml` now control the formatting of each `/claim help` and `/aclaim help` row. - **Allowed messages to be disabled with empty strings** - Leaving a message blank now suppresses it instead of sending a visually empty chat line. ## Bug Fixes Blank help-related messages are no longer restyled into color-only or newline-only strings during message loading. This lets server owners disable any configured message by setting it to an empty string. The unified claim help renderer now uses the `ClaimHelpEntry` and `AClaimHelpEntry` message templates instead of hardcoding each help row. This allows server owners to change colors, separators, and row formatting from `messages.yml`. ## Configuration `alias.yml` now supports a root command `fallback` option: ```yaml commands: claim: fallback: 'help' aclaim: fallback: 'help' ``` Leave `fallback` empty to keep the previous built-in root command behavior. ## Migration No data migration required. Existing `alias.yml` files will continue to work; add `fallback: 'help'` under `commands.claim` or `commands.aclaim` if you want root commands to open help by default.

# GriefPrevention3D v17.5.0 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## Highlights - **Fixed negative claim block balance on `/expandclaim`** - Expanding a claim no longer silently bypasses the block-sufficiency check when the player's name lookup returns an unexpected value, which could leave players with a negative block balance. ## Bug Fix The block-sufficiency guard in `resizeClaimWithChecks` compared `player.getName()` against `claim.getOwnerName()`. `getOwnerName()` resolves the owner's name through an offline player lookup, which can return `"Unknown"` or a cached display name that does not exactly match the online player's `getName()`. When the comparison failed, the entire block check was skipped and the resize was allowed to proceed regardless of available blocks — leaving the player with a negative balance after the fact. The check now compares `player.getUniqueId()` against `claim.ownerID` directly, which is reliable regardless of name resolution state. ## Migration No data migration or configuration changes required. Players who ended up with a negative balance will need an admin to restore their blocks via `/givepet` or `/setblocks`.

# GriefPrevention3D v17.4.9 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## Highlights - **Fixed a resize selection regression** - Very small 3D subdivisions and 3D admin claims can be right-clicked with the golden shovel again to start resize selection. - **Restored thin claim corner clicks** - Claims with a one-block X, Y, or Z dimension no longer silently consume the shovel click without showing the selection message. - **Preserved shaped-claim behavior** - The fix restores rectangular claim corner handling without changing shaped-claim corner selection. ## Regression Fix Recent corner-selection changes regressed resize selection for thin 3D claims. Affected claims could consume the golden shovel right-click without sending the resize/selection message, making them appear impossible to resize. This affected 3D subdivisions and 3D admin claims with any one-block dimension, including `1x1x1`, `1x1x2`, `1x2x1`, and single-layer `2x2x1` claims. The selection path now recognizes rectangular corners directly, even when the rectangle collapses to a single X or Z coordinate, and shovel targeting resolves visible single-layer markers back to the real claim corner. ## Technical Changes - Added regression coverage for one-block X/Z rectangular corner detection. - Kept shaped-claim corner detection on the existing polygon path. - This is not gated by `GriefPrevention.Claims.AllowShapedClaims`; the affected corner-selection path is shared by normal rectangular claim resizing. ## Migration No data migration or configuration changes required.

# GriefPrevention3D v17.4.8 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## Highlights - **Fixed WelcomeTask memory leak** ([#2483](https://github.com/GriefPrevention/GriefPrevention/issues/2483)) — The scheduled welcome task no longer holds a hard reference to the `Player` object, preventing leaked `CraftPlayer` instances when players disconnect before the task runs. - **Disable welcome task via config** — Setting `ManualDeliveryDelaySeconds` to `0` or a negative value now skips scheduling the welcome task entirely. ## WelcomeTask Memory Leak Fix `WelcomeTask` previously stored a direct `Player` reference. On high-volume servers with a large `ManualDeliveryDelaySeconds` value, every new player who joined and left before the task fired would leave a leaked `CraftPlayer` in memory until the task eventually ran. The task now stores the player's `UUID` and resolves it via `Bukkit.getPlayer()` at execution time. If the player is offline, the task exits immediately with no retained references. ## Disabling the Welcome Task Servers that don't want the welcome message can now set `ManualDeliveryDelaySeconds` to `0` (or any negative value) in `config.yml` to prevent the task from being scheduled at all. Previously, some server operators worked around this by setting extremely high delay values, which caused the leak described above. ## Migration No data migration required. Existing `ManualDeliveryDelaySeconds` values continue to work as before. Set to `0` to disable.

# GriefPrevention3D v17.4.7 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## Highlights - **New `INITIALIZE_ZONE_3D` visualization** — First-click diamond markers for 3D admin claims and 3D subdivisions now render at the exact clicked Y coordinate instead of snapping to the terrain surface. - **Proper visualization pipeline** — Replaced a raw `sendBlockChange` hack with a real visualization type that supports cleanup tracking, glow mode, and event firing. ## INITIALIZE_ZONE_3D Visualization 3D claims are placed at the exact block the player targets — that's the core difference from 2D claims, which snap to terrain. Previously, the first-click diamond marker didn't respect this: it either used `INITIALIZE_ZONE` (which terrain-snaps to the surface) or bypassed the visualization system entirely with a raw `sendBlockChange`. The new `INITIALIZE_ZONE_3D` type renders the diamond marker at the exact Y of the clicked block. It routes through `drawRespectingYBoundaries` in `FakeBlockVisualization` and uses exact placement in `GlowingVisualization`, consistent with how `SUBDIVISION_3D` and `ADMIN_CLAIM_3D` boundary types already work. Both 3D admin claims and 3D subdivisions now use this type for their first-click marker. ## Migration No data migration or configuration changes required.

# GriefPrevention3D v17.4.6 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## Bug Fixes ### 3D Admin Claim Visualization (bottom half) Fixed 3D admin claim subdivisions rendering with ADMIN_CLAIM_3D visual (pumpkin/glowstone) instead of SUBDIVISION_3D (white/iron) until refreshed. The `defineBoundaries()` method now checks `claim.parent == null` alongside `claim.isAdminClaim()`, so child subdivisions of admin claims inherit the correct visualization type immediately. Also applied the same fix to `visualizeNearbyClaims()` for consistency. ### `visualizeNearbyClaims` Horizontal Search Radius Fixed `DataStore.getNearbyClaims()` only checking the player's single chunk (1×1×1 bounding box), ignoring claims in adjacent chunks. Pulled in upstream's 300-block X/Z search radius (`location.clone().subtract(150, 0, 150)` to `location.clone().add(150, 0, 150)`). 3D admin claims in neighboring chunks are now found during sneak+stick inspection. ### Vertical Range Filter for 3D Claims in `visualizeNearbyClaims` Added a 16-block vertical range filter so 3D claims far above or below the player are excluded from sneak+stick visualization. 2D claims (full height) are always included. This prevents showing 3D claims hundreds of blocks away while still catching those starting +1 above the target point. ### 3D Subdivision Admin Claim Visual on First Render Fixed a brief window where 3D subdivisions inside admin claims would show with the admin claim visual (`ADMIN_CLAIM_3D`) until the player refreshed the visualization. The `defineBoundaries()` method now correctly identifies child subdivisions regardless of owner, so the first render is always correct. ### Admin3D Initialization Visual at Wrong Y Fixed `visualizeArea()` rendering the initialization marker at the player's eye Y instead of the clicked block's Y. Added an overload accepting a block-specific Y. Admin3D first/second clicks now use `getTargetBlock()` to resolve through replaceable blocks (snow layers), so the marker and claim corners land on the solid block instead. ### `griefprevention.extendclaim.toolbypass` Permission Default Changed `griefprevention.extendclaim.toolbypass` permission default from `false` to `op`. This restores the expected behavior where server operators can extend claims without a modification tool by default. ### 3D Claim `/extendclaim` Vertical Extension Fixed `/extendclaim` blocking vertical extension for 3D claims with the "Land claims auto-extend deeper into the ground when you place blocks under them." message. 3D claims can now extend upward (looking up) or downward (looking down) using the command. For 3D subdivisions, the extension is validated to stay within parent claim Y bounds; overlapping another subdivision or exiting parent bounds shows the appropriate error. ## Pairing This release should be paired with **GPExpansion v1.0.9**. ## Migration No data migration required. No configuration changes needed.

# GriefPrevention3D v17.4.5 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## Upstream Merge: Don't block knockback when GP PvP rules are disabled (#2600) Admins who disable GP PvP rules for a world (to opt out of safe zones, fresh spawn immunity, etc.) but keep world PvP on were seeing knockback silently blocked. GP now skips PvP checks without cancelling the knockback event, matching how `EntityDamageHandler` already handles this case. Cherry-picked from upstream GriefPrevention commit `75ed5c7`. Affected file: `KnockbackProtectionHandler.java`. ## Migration No data migration required. No configuration changes needed.

# GriefPrevention3D v17.4.4 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## Highlights - **3D admin claims** — New `Admin3D` shovel mode creates free, height-bounded administrative claims. Includes `/3dadminclaims` command and `/aclaim mode admin3d` subcommand. - **Verbose piston feedback** — When a piston is broken by a claim boundary, the nearest player with build permission now receives a message explaining where and why, with a conflict-zone visualization of the blocking claim. - **Trapped command fixes** — `handleTrappedCommand` brought to parity with the inline handler: correct check ordering, proper GPFlags destination forwarding, nether/end guard, and silent pending-rescue suppression. - **New command aliases** — Added `/3dsc`, `/sc3d`, `/subdivide3d`, `/3dsubdivide`, `/adminclaim3d`, `/adminclaims3d`, and others to match the tau fork's alias set. ## 3D Admin Claims A new `Admin3D` shovel mode lets administrators create free, height-limited claims using exact Y coordinates (not the usual ground-extension offset). ### Commands | Command | Aliases | Description | |---------|---------|-------------| | `/3dadminclaims` | `adminclaim3d`, `adminclaims3d`, `3dadminclaim` | Switch shovel to 3D admin claim mode | | `/aclaim mode admin3d` | — | Same via unified command | Requires the `griefprevention.adminclaims` permission. ### Behavior - Claims created in `Admin3D` mode use the clicked Y coordinates directly as the vertical bounds — no ground-extension offset is applied. - Free to create (no claim blocks consumed) and owner ID is null, making them standard admin claims. - Minimum size and claim block checks are bypassed, identical to regular `Admin` mode. Affected files: `ShovelMode.java`, `Messages.java`, `GriefPrevention.java`, `UnifiedAdminClaimCommand.java`, `Alias.java`, `PlayerEventHandler.java`, `plugin.yml`. ## Verbose Piston Feedback Previously, when a piston was broken by a claim boundary in precise mode, the player who placed it received no feedback — only the claim owner on the other side was notified via `ClaimBoundaryViolationTracker`. GP3D now also notifies the **piston owner side**: the nearest online player with build permission in the piston's claim (or within 32 blocks if the piston is outside any claim) receives: - A warning message: *"The piston at x, y, z exploded because it couldn't enter the claim at [location]"* - A `CONFLICT_ZONE` boundary visualization of the claim that blocked the push The existing `ClaimBoundaryViolationTracker` dedup/burst notifications to the invaded claim's owner are preserved unchanged. Affected file: `BlockEventHandler.java`, `Messages.java`. ## Trapped Command Fix `handleTrappedCommand` (used by the unified `/claim` command handler) had several divergences from the inline `onCommand` implementation: - **Wrong pending message** — sent `RescueAbortedMoved` when `/trapped` was already pending; it now silently returns (consistent with tau and the inline handler). - **Lost GPFlags destination** — `SaveTrappedPlayerEvent` was fired but its destination was discarded; the destination is now forwarded to `PlayerRescueTask`. - **Missing nether/end guard** — rescue is now blocked in the nether and end when no external destination is provided. - **Check order** — `pendingTrapped` is now checked before the claim/permission checks, matching the upstream order. - **Spurious event cancellation check** — `SaveTrappedPlayerEvent` is not cancellable; the dead `isCancelled()` branch was removed. Affected file: `GriefPrevention.java`. ## New Aliases Added missing aliases to match the tau fork's command set: | Command | New aliases added | |---------|------------------| | `3dsubdivideclaims` | `3dsc`, `sc3d`, `subdivide3d`, `3dsubdivide` | | `adminclaims` | `aclaims` | | `3dadminclaims` *(new)* | `adminclaim3d`, `adminclaims3d`, `3dadminclaim` | | `/aclaim mode` standalone | `3dadminclaims` | Affected files: `plugin.yml`, `Alias.java`. ## Migration No data migration required. The new `3dadminclaims` command and its aliases are registered automatically on server start. No config changes are needed. New permission used (inherits existing `griefprevention.adminclaims` node — no new node required): - `griefprevention.adminclaims` — now also gates `/3dadminclaims` and `/aclaim mode admin3d`.

# GriefPrevention3D v17.4.3 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## Highlights - **Unified command hardening** — Fixed several standalone command edge cases and permission checks. - **PlaceholderAPI support** — Added a small optional GP3D PlaceholderAPI expansion. - **More claim protections** — Added protections for animal mounting, entity unleashing, hanging entities, and weaving cobwebs. - **QuickShop-Hikari compatibility** — Restore-nature now preserves QuickShop shop signs. - **Claim expiration exemption** — Players with the griefprevention.dontexpire permission are now skipped by inactive-claim cleanup when Vault is installed. ## Unified Commands The unified command handler now handles standalone aliases more carefully: - Explicit empty `standalone:` lists in `alias.yml` now disable standalone aliases for that subcommand instead of falling back to enum defaults. - Standalone no-argument commands now reject extra arguments instead of forwarding unexpected input. - Standalone commands can now use custom tab completion where needed. - Unified subcommands now check their configured permission before execution. - `/shapedclaims`, `/claim mode shaped`, `/3dsubdivideclaims`, and `/claim mode 3d` now consistently enforce their dedicated permissions. Affected files: `CommandAliasConfiguration.java`, `UnifiedCommandHandler.java`, `UnifiedClaimCommand.java`, `UnifiedAdminClaimCommand.java`, `GriefPrevention.java`, `plugin.yml`. ## PlaceholderAPI Added optional PlaceholderAPI integration with identifier `gp3d`. New placeholders: - `%gp3d_in_subdivision%` — `true` when the player is inside any subdivision. - `%gp3d_in_3d_subdivision%` — `true` when the player is inside a 3D subdivision. PlaceholderAPI is a soft dependency. The expansion registers automatically when PlaceholderAPI is installed. Affected files: `pom.xml`, `plugin.yml`, `PlaceholderAPIExpansion.java`, `GriefPrevention.java`. ## Protection Fixes ### Animal mounting requires access trust Players now need Access trust to mount claimed rideable animals. `/ignoreclaims` still bypasses this for administrators. Affected file: `PlayerEventHandler.java`. ### Entity unleashing requires container trust When theft prevention is enabled, players now need Container trust to unleash entities inside claims. `/ignoreclaims` still bypasses this for administrators. Affected file: `PlayerEventHandler.java`. ### Hanging entity protection Item frames, paintings, and other hanging entities are now protected from additional edge cases: - physics breaks caused by projectiles or nearby updates while the supporting block still exists - direct non-player damage - player/projectile damage without Build permission - explosion damage events Affected file: `EntityEventHandler.java`. ### Weaving cobwebs no longer trip block-change protection The Weaving potion effect can now create cobwebs from living-entity deaths without being caught by unrelated entity block-change protections. Affected file: `EntityEventHandler.java`. ## QuickShop-Hikari Compatibility Restore-nature now detects QuickShop shop signs by their persistent data key and preserves both: - the shop sign itself - the block supporting the shop sign This prevents GP3D restore-nature operations from silently removing QuickShop shop signs through direct block restoration. Affected files: `BlockSnapshot.java`, `RestoreNatureProcessingTask.java`. ## Claim Expiration Bypass If Vault is installed, claim expiration now honors: - `griefprevention.dontexpire` Players with that permission are skipped by the inactive-claim cleanup task. Affected files: `CleanupUnusedClaimPreTask.java`, `plugin.yml`. ## Migration No data migration required. New optional integrations: - Install PlaceholderAPI to use the new `%gp3d_*%` placeholders. - Install Vault plus a permissions provider to use `griefprevention.dontexpire`. New permissions from v17.4.2 remain default-true: - `griefprevention.shapedclaims` - `griefprevention.3dsubdivideclaims`

# GriefPrevention3D v17.4.1 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki This release pulls in fixes for a batch of long-standing upstream GriefPrevention bugs that hadn't been merged in their tracker yet. ## Upstream Issue Fixes ### Workstations no longer treated as theft (`#2587`) Grindstones, looms, stonecutters, and cartography tables are now usable in claims by players without trust — same as crafting tables. These are pure crafting workstations with no persistent inventory (any items left in them drop to the floor on close), so the **PreventTheft** path no longer applies to them. Affected file: `PlayerEventHandler.java`. ### TNT-above-sea-level chat spam fixed (`#2586`) The "TNT will not destroy blocks above sea level" warning is now rate-limited per-player to once every 10 seconds. Map-art builders and large TNT placements no longer flood chat with one message per block. Implementation: a new `tntAboveSeaLevelWarningTimestamp` field on `PlayerData` gates the message in `BlockEventHandler.onBlockPlace`. ### Ender Dragon breath now damages players in PvP-protected claims (`#2577`) The PvP "lingering potion" handler used to cancel **any** `AreaEffectCloud` damage when the defender was inside a PvP-protected claim. That accidentally included the Ender Dragon's breath attack, which made dragon fights trivial whenever the End island was an admin claim. The handler now only intervenes when the cloud's source is a `Player`. Mob-sourced clouds (the dragon, plus any future mob that produces an `AreaEffectCloud`) pass through normally. Affected file: `EntityDamageHandler.handlePvpDamageByLingeringPotion`. ### Copper trapdoors honor `LockTrapDoors` (`#2550`) The trapdoor-locking path now uses a robust `isLockableTrapdoor()` helper that checks both `Tag.TRAPDOORS` **and** falls back to a `_TRAPDOOR` name suffix match. Copper trapdoors (and any future trapdoor variants) are protected even on Bukkit API versions where `Tag.TRAPDOORS` doesn't yet include them. Affected file: `PlayerEventHandler.java`. ### Player data corruption on storage read failure (`#2589` / `#666`) When the data store (database or flat-file) failed to read a player's record — most commonly a transient MySQL `wait_timeout` / `EOFException` — the failure was silently swallowed and a fresh `PlayerData` with default values was returned. On the player's next save, those defaults were written back, **permanently destroying** the player's accrued and bonus claim blocks. This has been a long-standing upstream bug that resets players to zero blocks even when their actual claims are still on disk. GP3D now flags failed reads via a new `loadFailedFromStorage` field on `PlayerData`. Both `DatabaseDataStore` and `FlatFileDataStore` set this flag when a read genuinely fails (vs. legitimately returning no row for a brand-new player). The save path in both backends refuses to persist a flagged `PlayerData`, so the on-disk record is preserved until a successful re-load happens. The player can still play this session with conservative defaults; their real record stays intact. Affected files: `PlayerData.java`, `DatabaseDataStore.java`, `FlatFileDataStore.java`. ### Brushing loophole closed The previous brush protection only ran on `PlayerInteractEvent`, which fires once when the player starts brushing. Because brushing is tick-driven and the targeted block can change while the player keeps right-click held, players could start brushing a block outside a claim, walk into the claim, and let the brush complete on a claimed `SUSPICIOUS_SAND`/`SUSPICIOUS_GRAVEL` block — bypassing the original check. GP3D now also listens to `EntityChangeBlockEvent` and re-checks Build permission at the moment the suspicious block transitions to its loot result. The check is restricted to actual brushing transitions (`SUSPICIOUS_SAND -> SAND`, `SUSPICIOUS_GRAVEL -> GRAVEL`) with a held-brush guard, so unrelated entity-driven block changes are not affected. Affected file: `PlayerEventHandler.onPlayerBrushComplete`. ## Migration No configuration changes or data migration required. All fixes are behavior changes that take effect immediately on update.

# GriefPrevention3D v17.4.0 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## Highlights - **More translatable messages** — Added `CommandRequiresPlayer` key for console-command error messages. - **Plugin metadata** — Added `authors` and `website` fields to `plugin.yml`. ## Translatable Messages Added new `Messages` enum key: - `CommandRequiresPlayer` — Sent when a player-only command is used from console. Default: `"This command can only be used by players."` This is now used by `/buyclaimblocks` and `/sellclaimblocks` in `UnifiedClaimCommand` instead of a hardcoded string. Customize it in `plugins/GriefPreventionData/messages.yml`. ## Plugin Metadata Updated `plugin.yml` with additional metadata: - `description`: "The self-service anti-griefing plugin for Minecraft servers — now with full 3D subdivisions" - `website`: `https://castled.codes` - `authors`: `[CASTLEDKING, RoboMWM, BigScary]` ## Migration No configuration changes or data migration required. The new `CommandRequiresPlayer` key will be added to your `messages.yml` automatically on next load if missing.

# GriefPrevention3D v17.3.9 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## Highlights - **Fix duplicate permission messages** - Ender pearl access denial messages now only send once on Purpur/Folia - **Folia fix** - Boundary violation alert scheduler now correctly uses the Folia-safe `SchedulerUtil` instead of `Bukkit.getScheduler()` directly - **Rename back to GriefPrevention** - Renaming to 'GriefPrevention3D broke compatibility with GPFlags and other plugins that depend on GriefPrevention by name. ## Fix Duplicate Permission Messages On Purpur and Folia servers, both `PlayerTeleportEvent` and `ProjectileHitEvent` fire for ender pearls. Previously, both handlers would send the "You don't have player's permission to use that" message when access was denied, resulting in 2-3 duplicate messages. Fixed by adding a deduplication check in `PlayerTeleportEvent` handler — it now skips sending the message if `ProjectileHitEvent` already handled the denial (tracked via the existing `refundedByProjectileHitEvent` set). ## Folia Fix The boundary violation alert scheduler in `ClaimBoundaryViolationTracker` was calling `Bukkit.getScheduler().runTaskLater()` directly, which is not available on Folia servers. Fixed to use `SchedulerUtil.runLaterGlobal()` — the existing Folia-safe adapter used throughout the rest of the plugin. This routes through Folia's `GlobalRegionScheduler` when present and falls back to `Bukkit.getScheduler()` on Paper/Spigot. ## Migration No configuration changes or data migration required.

# GriefPrevention3D v17.3.8 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## Highlights - **Official plugin rename** - Plugin is now officially named `GriefPrevention3D` (output jar, `plugin.yml`, dependency declarations) - **Folia fix** - Boundary violation alert scheduler now correctly uses the Folia-safe `SchedulerUtil` instead of `Bukkit.getScheduler()` directly ## Plugin Rename The plugin's official name is now `GriefPrevention3D` across the board: - `plugin.yml` `name:` field changed from `GriefPrevention` to `GriefPrevention3D` - Output jar is now `GriefPrevention3D.jar` - Maven `<artifactId>` and `<name>` updated to `GriefPrevention3D` ### Impact on addon/dependent plugins If you have plugins that declare a dependency on this plugin, update your `plugin.yml`: ```yaml # Before softdepend: [GriefPrevention] # After softdepend: [GriefPrevention3D] ``` JitPack dependency coordinates also updated to `com.github.castledking:GriefPrevention3D`. ## Folia Fixes Two scheduler calls were using `Bukkit.getScheduler()` directly, which throws `UnsupportedOperationException` on Folia/Canvas region threads: - `ClaimBoundaryViolationTracker` — burst flush task now uses `SchedulerUtil.runLaterGlobal()` - `AutoExtendClaimTask` — async fallback now uses `SchedulerUtil.runAsyncNow()` Both now go through the existing `SchedulerUtil` adapter, which routes to Folia's schedulers when present and falls back to Bukkit on Paper/Spigot. Thanks to **R00tB33rMan** for reporting the crash and identifying the affected code (PR #4). ## Migration - **Server owners**: rename the jar file reference in your startup scripts if you have any hardcoded references to `GriefPrevention.jar`. - **Addon developers**: update `softdepend`/`depend` in your `plugin.yml` to `GriefPrevention3D`. - **No claim data migration required.** Existing claims load without modification.

# GriefPrevention3D v17.3.7 ## Highlights - **Boundary Violation Alerts** - Claim owners are notified when pistons or liquids get blocked at their claim boundary, with smart deduplication and burst detection - **Improved Claim Selection Messages** - More informative messages when selecting claims and subdivisions - **Updated Player Manual** - Welcome book now includes GP3D branding and additional commands - **New Wiki** - https://github.com/castledking/GriefPrevention3D/wiki ## Boundary Violation Alerts Pistons and liquids blocked at claim boundaries now send a chat message to the claim owner (if online) explaining where the violation occurred. Covers: - Pistons pushing blocks **into** or **out of** claims - Water/lava trying to flow **into** or **out of** claims ## Improved Claim Selection Messages - **Subdivisions** now get a dedicated, verbose message with color-coded command list - **Basic claims** reference `/claim abandon` - **Top-level claims** reference `/claim abandon toplevel` - All messages better reflect available commands ## Updated Player Manual - Added "✅ This server is using GriefPrevention3D" branding - Added `/3dSubdivideClaims` and `/WitherExplosions` to commands page

# GriefPrevention v17.3.6 ## Highlights - Quick fix for a bug where `griefprevention.adjustclaimblocks` was not checked when `/aclaim blocks` was used.

# GriefPrevention v17.3.5 (Paper 26.1.2 Experimental) ## Highlights - Experimental support for Paper 26.1.2 (calendar-versioned Paper builds running on Java 25). - Migrated deprecated `PlayerLoginEvent` to `AsyncPlayerPreLoginEvent` to comply with Paper 26's re-configuration API requirements. - Thread-safe IP ban tracking for async login handling. ## Paper 26.1.2 Compatibility This release targets Paper's new calendar-versioned experimental builds (26.1.2.build.18-alpha) which require Java 25. The plugin has been verified to load and run correctly on: - **Paper**: 26.1.2.build.18-alpha (Implementing API version 26.1.2.build.18-alpha) - **Java**: OpenJDK 25.0.2+10-LTS (Temurin) ## Event System Migration Paper 26 deprecates listening to `PlayerLoginEvent` because it fires between the login and configuration phases, blocking Paper's re-configuration APIs. This release migrates to `AsyncPlayerPreLoginEvent`: - Login cooldown and spam protection now run asynchronously before the configuration phase. - IP address recording moved to `PlayerJoinEvent` to keep DataStore writes on the main thread. - Smart-ban IP tracking preserved: banned accounts are still recorded for IP-based auto-banning. ## Thread Safety Improvements - `tempBannedIps` changed from `ArrayList` to `CopyOnWriteArrayList` to safely handle writes from the async login thread while main-thread handlers iterate the list. ## Technical Changes - `paper-api` dependency bumped to `26.1.2.build.18-alpha`. - Removed deprecated `PlayerLoginEvent` and `PlayerLoginEvent.Result` imports. - Added `AsyncPlayerPreLoginEvent` import and handler (`onAsyncPlayerPreLogin`). - Added offline-safe `hasSpamBypass(UUID)` helper for cooldown bypass checks (falls back to op status; permission-based bypass will be restored in a future update). ## Notes - This is an **experimental build** for Paper 26.1.2. For production servers on Paper 1.21.x, use the standard v17.3.5 release. - The `api-version` in `plugin.yml` remains `"1.21"` for backward compatibility. - All 108 unit tests pass on Java 25. - No changes to claim mechanics, permissions, or commands — this is purely a compatibility update.

# GriefPrevention v17.3.5 ## Highlights - Major shaped-claim performance pass: shaped edits and large shaped path creation are now viable at sizes that previously stalled or failed the geometry layer. - Reduced per-edit CPU cost for nib growth, merges, and boundary tracing on claims with long orthogonal perimeters. ## Shaped Claim Performance - Replaced the per-cell scan used to measure shaped claims with a closed-form count derived from the boundary polygon, so measuring a shaped claim is now `O(edges)` instead of `O(width * height)`. - Large shaped paths (winding corridors, perimeter walls, sprawling multi-segment outlines) can now be created and resized without the prior cost wall, because measurement no longer grows with the claim's bounding box. - Added a cached boundary polygon on each claim so repeated measurement, containment, and overlap queries within the same edit no longer rebuild and re-validate the polygon from scratch. ## Technical Improvements - New `OrthogonalPolygon.cellCount()` computes the number of integer-lattice cells inside or on the boundary of a shaped claim directly from its corners, using Pick's theorem (`A + B/2 + 1`) with the shoelace formula for the area `A` and the summed Manhattan edge lengths for the boundary count `B`. This is exact for axis-aligned polygons with integer corners, which is always the case for shaped claims. - `Claim.getClaimBlocks()` now calls `cellCount()` instead of iterating every `(x, z)` in the bounding box and calling `containsColumn`. - `DataStore.polygonCellArea(...)` no longer builds a throwaway measuring claim and runs a per-cell `contains(...)` test; it also delegates to `cellCount()`. - Added a transient `cachedBoundaryPolygon` on `Claim`, invalidated on shape mutation and on the copy constructor, and populated from the already-validated polygon in `setShapedCorners` so `getBoundaryPolygon()` does not re-validate on first access. ## Notes - This release is the recommended base for GPExpansion `v1.0.4`, whose `/claimmap` performance work depends on the shaped-claim geometry speedups shipped here. - Behavior of existing shaped edits is unchanged; only their cost and upper size limits have improved.

# GriefPrevention v17.3.4 ## Highlights - Fixed `/claimexplosions` not actually enabling TNT explosions in claim.

# GriefPrevention v17.3.3 ## Highlights - Fixed `/witherexplosions` being ignored when `/claimexplosions` was enabled. - Wither skull explosions now correctly respect the separate wither explosion setting.

# GriefPrevention v17.3.2 ## Highlights - Fixed a `/permissiontrust` regression where trusted players could end up with edit-level abandon behavior instead of only trust-management access. - Continued the shaped-claim editor stabilization pass, especially around nib merges, corner reconnects, and map-driven geometry updates. - Updated default `/claim create` layout math so editor-integrated creation flows line up to a true `10x10` starter claim instead of drifting between `9x9` and `11x11`. ## Shaped Claims And Resizing - Fixed several shaped resize edge cases where notch and nib edits could: - expand an entire face instead of the intended local segment, - collapse into a tiny invalid local loop, - fail to reconnect to the main claim body during merge-style edits, - or report a successful merge while leaving inconsistent geometry. - Improved polygon union and subtraction tracing used by the editor stack so map-driven claim edits can resolve the final claim body more reliably. - Tightened claim creation and resize alignment for editor-driven workflows so boundary math stays consistent between command creation, shovel resizing, and external map tools. ## Bug Fixes - Fixed `/permissiontrust` incorrectly allowing players to abandon claims they did not own. - Fixed starter claim sizing so `/claim create` now produces the expected exact square footprint for editor integrations. - Fixed several shaped-resize regressions that could mis-handle corner fills, side merges, or segment-local edits. ## Technical Improvements - Added cleaner polygon merge/subtract handling for occupied-cell based claim editing. - Improved boundary tracing and reconnect selection for complex orthogonal shaped claims. - Better failure handling for unsupported geometry outcomes, such as edits that would split a claim into disconnected pieces. ## Notes - This release is the recommended base for the updated GPExpansion `v1.0.3` map editor and resize GUI work. - When a shaped edit cannot be represented safely, it now fails cleanly instead of silently approximating a broken result.

# Release: Shaped Claims + Subclaim Resize Fixes ## Highlights - Added shaped claim editing workflow with segment-based expansion/resizing. - Fixed subclaim resize validation so subdivisions cannot be resized outside parent confines. - Fixed container-corner interaction flow so 3D subdivision corner clicks correctly prioritize resize. - Added stronger nested-subclaim safety checks to prevent invalid create paths. ## Shaped Claims To enable shaped claims, set: - `GriefPrevention.Claims.AllowShapedClaims: true` Then use: - `/shapedclaims` to enter shaped claim mode. ### Quick Walkthrough In shaped claim mode: - Right-click boundaries to create/edit segments on non-rectangular claims. - Click corners or matching segment points to perform shaped merge-resizes. - Right-click selected segments to resize claim sides directly. - Segment resize direction depends on player position relative to the segment: - Center = expand full side. - Left = expand left portion. - Right = expand right portion. - `/expandclaim 10` and `/expandclaim -10` work with selected segments. ## Subclaim Resize Fixes - Prevented 2D/3D subdivision resize from escaping parent confines and creating conflict-zone style invalid states. - Added stricter containment checks for subclaim create/resize paths. - Ensured existing shaped claims remain protected even if `AllowShapedClaims` is later turned off. - Updated resize failure messaging for parent-confine violations. ## Technical Improvements - Container-click handling now matches normal shovel behavior for corner clicks: - Corner click on editable 3D subdivision starts resize flow first. - Subdivision creation no longer incorrectly starts on those corner/container interactions. - Nested subdivision creation is now guarded at datastore level, not only interaction layer logic.

## Overview - Add new /witherexplosions command (wither-only toggle) - New data components handle wither explosion logic. Full changelog: [17.2.6...17.3.0](https://github.com/castledking/GriefPrevention/compare/17.2.6...17.3.0)

## Overview - Folia fix for glowing visualizations Full changelog: [17.2.5...17.2.6](https://github.com/castledking/GriefPrevention/compare/17.2.5...17.2.6)

## Overview - Fix purpur servers duping pearls Full changelog: [17.2.4...17.2.5](https://github.com/castledking/GriefPrevention/compare/17.2.4...17.2.5)

## Overview - Folia fix: Prevent endermites spawning and damaging entities when using enderpearls in claims Full changelog: [17.2.3...17.2.4](https://github.com/castledking/GriefPrevention/compare/17.2.3...17.2.4)

## Overview - Folia fix for teleportation causes - Merge upstream Full changelog: [17.2.2...17.2.3](https://github.com/castledking/GriefPrevention/compare/17.2.2...17.2.3)

## Overview - fix EnderPearlsRequireAccessTrust setting not actually working Full changelog: [17.2.1...17.2.2](https://github.com/castledking/GriefPrevention/compare/17.2.0...17.2.1)

## Overview - Add inheritNothingForNewSubdivisions field for claim data - Allow /rsc to be ran in main claims, restricting their future subdivision permissions - Add new MainClaimSubdivisionInheritDisabled and Enabled messages Full changelog: [17.2.0...17.2.1](https://github.com/castledking/GriefPrevention/compare/17.2.0...17.2.1)

## Overview - Add removeInheritedPermissions to properly remove trusted players on /rsc Full changelog: [17.1.9...17.2.0](https://github.com/castledking/GriefPrevention/compare/17.1.9...17.2.0)

## Overview - Fix /rsc command in 3D subclaims Full changelog: [17.1.8...17.1.9](https://github.com/castledking/GriefPrevention/compare/17.1.8...17.1.9)

## Overview - Restore ClaimPermission.Inventory as deprecated alias to fix compatibility with plugins - Upstream GriefPrevention kept Inventory as a @Deprecated(forRemoval = true) alias for Container, but commit 88b5a82 removed it entirely. This broke plugins like SpawnerMeta that reference ClaimPermission.Inventory. - Also updates isGrantedBy() to normalize Inventory to Container for proper permission comparison. Full changelog: [17.1.7...17.1.8](https://github.com/castledking/GriefPrevention/compare/17.1.7...17.1.8)

## Overview - Improve claim subdivision error handling - Fixed /restrictsubclaim command - Bumped version to 17.1.7 Full changelog: [17.1.6...17.1.7](https://github.com/castledking/GriefPrevention/compare/17.1.6...17.1.7)

## Overview Improve 2D visualization to start at player Y level, instead of starting at max world height - Merge FakeBlockVisualization with upstream - Remove SnapOverrideHelper - Bump version to 17.1.6 Full changelog: [17.1.5...17.1.6](https://github.com/castledking/GriefPrevention/compare/17.1.5...17.1.6)

## Overview - Enhanced command/tabcompletion addon implementation for GPExpansion to extend - Improve visualization snapping - Bumped version to 17.1.5 Full changelog: [17.1.4...17.1.5](https://github.com/castledking/GriefPrevention/compare/17.1.4...17.1.5)

## Overview Add back legacy /givepet command - Merging with upstream [https://github.com/castledking/GriefPrevention3D/commit/4a426f64692d3bb5916d2d28e125d5cf6cf75167](https://github.com/GriefPrevention/GriefPrevention/commit/4a426f6) - /givepet command and messages are now supported in this project. Full changelog: [17.1.3...17.1.4](https://github.com/castledking/GriefPrevention/compare/17.1.3...17.1.4)

## Overview - Added support for a new 'toplevel' option in the /claim abandon command to delete a claim and all its subdivisions. - Resizing claims now selects them and allows /claim abandon to delete them. - Replaced the old ResizeStart message with ClaimSelected and ClaimSelectedTopLevel. When you load with an existing ResizeStart in messages.yml, it is backed up automatically (see below). **ResizeStart removed — backup and new messages** The message **ResizeStart** was removed. It is replaced by two messages so the plugin can suggest the right command depending on whether the selected claim has subdivisions or not. ### Backup (automatic) If your **messages.yml** contained **Messages.ResizeStart** (or **Messages.ResizeStart.Text**), the plugin backs it up on load: ```yaml # Where: Same folder as messages.yml (your GriefPrevention data folder) # File: ResizeStart-backup.yml # # The backup file contains your old ResizeStart value and a short header explaining that # ClaimSelected and ClaimSelectedTopLevel replaced it. After the backup is written, # ResizeStart is removed from messages.yml so the plugin does not use it anymore. # You can copy any formatting (e.g. color codes) from ResizeStart-backup.yml into # ClaimSelected or ClaimSelectedTopLevel in messages.yml if you want to keep it. ``` ### New messages ```yaml # ClaimSelected # When: Shown when you select a claim corner and that claim has no subdivisions. # Suggests: /claim abandon to delete the claim. # Default: "Claim selected. Use your shovel again to set the other corner and resize, or use /claim abandon to delete this claim." # ClaimSelectedTopLevel # When: Shown when you select a claim corner and that claim has subdivisions. # Suggests: /claim abandon toplevel to delete the claim and all its subdivisions. # Default: "Claim selected. Use your shovel again to set the other corner and resize, or use /claim abandon toplevel to delete this claim and its subdivisions." ``` Full changelog: [17.1.2...17.1.3](https://github.com/castledking/GriefPrevention/compare/17.1.2...17.1.3)

## Overview - Improved permission checks for 3D claims in ProtectionHelper and Claim classes to ensure proper inheritance for first-child subdivisions. - Added migration logic in DatabaseDataStore and FlatFileDataStore to set inheritance correctly for new 3D subdivisions. Full changelog: [17.1.1...17.1.2](https://github.com/castledking/GriefPrevention/compare/17.1.1...17.1.2)

## Overview - fix: New standalone master switch and fixes for alias.yml ‎ What to edit in **alias.yml** (in `plugins/GriefPreventionData/`) to use the new options. Reload with `/gpreload` after changes: ‎ ## 1. Global Toggles (top of file) ```yaml # Master switch: false = no alias system, use default English command names enabled: true # Standalone commands: false = only /claim and /aclaim (or their translations) exist # No /trust, /trapped, /abandonclaim, etc. – use /claim trust, /claim trapped, etc. instead** standalone: true ``` ## 2. Root command names (claim / aclaim) Under `commands:` → `claim:` or `aclaim:` use the **`commands:`** list. **Every entry is a full root command** (not just the first one). **Example – allow both `/claim` and `/claims`:** ```yaml commands: claim: enable: true commands: [claim, claims] # /claim create and /claims create both work # ... aclaim: enable: true commands: [aclaim, aclaims] # /aclaim restore and /aclaims restore both work # ... ```

## Overview ### Updated Upstream (GriefPrevention 16.18.5...6) GriefPrevention Changes: - Changed permission checks from ClaimPermission.Inventory to ClaimPermission.Container across multiple classes to improve clarity and consistency. - Introduced a new method to retrieve per-world maximum claim depth, enhancing configuration flexibility. - Added a new configuration option to refund denied ender pearls when teleportation fails. This project is now up-to-date with latest GriefPrevention changes. Full changelog: [17.0.24...17.1.0](https://github.com/castledking/GriefPrevention/compare/17.0.24...17.1.0)

## Overview - Fix /acb & /scb commands - Fix /trapped command in Folia Full changelog: [17.0.23...17.0.24](https://github.com/castledking/GriefPrevention/compare/17.0.23...17.0.24)

## Overview - Fix investigation tool breaking on conflicting claim creation or resize - Fix 1x1x1 3D subdivision resizing - Fix no containers permission message not showing Full changelog: [17.0.22...17.0.23](https://github.com/castledking/GriefPrevention/compare/17.0.22...17.0.23)

## Overview - Fix: add global toggle to disable alias system Full changelog: [17.0.18...17.0.19](https://github.com/castledking/GriefPrevention/compare/17.0.18...17.0.19)

## Overview - Hide canonical names from tab completion when aliases are configured - Only show aliases in tab completion when they exist, not both canonical and aliases - Add dynamic root command registration to allow renaming main commands (e.g., /claim -> /terreno) - Use reflection to force-override existing commands in knownCommands map - Add comprehensive alias.yml documentation with argument type reference and translation examples Full changelog: [17.0.17...17.0.18](https://github.com/castledking/GriefPrevention/compare/17.0.17...17.0.18)

## Overview - Rename /claim protect to /claim create and standalone command to createclaim - Add /aclaim help subcommand and standalone aclaimhelp command - Improve dynamic command registration to force-override existing commands via knownCommands reflection - Fix 3D Subdivisions still being missing in recent updates. Full changelog: [17.0.16...17.0.17](https://github.com/castledking/GriefPrevention/compare/17.0.16...17.0.17)

## Overview - fix: wrong commands being generated in alias.yml - fix: AFK detection was inverted; players who moved were counted as idle. Full changelog: [17.0.15...17.0.16](https://github.com/castledking/GriefPrevention/compare/17.0.15...17.0.16)

## Overview - fix: add back ignoreclaims permission check Full changelog: [17.0.14...17.0.15](https://github.com/castledking/GriefPrevention/compare/17.0.14...17.0.15)

## Overview - Add restore nature command with aggressive and fill modes - Implement buy/sell claim blocks with Vault economy integration - Added Paper compliant KnockbackHandler for wind charges - Fixed a bug where 3D subdivisions were missing in recent updates Full changelog: [17.0.13...17.0.14](https://github.com/castledking/GriefPrevention/compare/17.0.13...17.0.14)

## Overview - Add explicit saveClaim call for 3D claims in resizeClaim since setNewDepth is only called for 2D claims Full changelog: [17.0.12...17.0.13](https://github.com/castledking/GriefPrevention/compare/17.0.12...17.0.13)

## Overview - Fixed some commands that were broken Full changelog: [17.0.11...17.0.12](https://github.com/castledking/GriefPrevention/compare/17.0.11...17.0.12)

## Overview - Subdivision permissions now take precedence over parent claims - Improved GlowVisualization settings Full changelog: [17.0.10...17.0.11](https://github.com/castledking/GriefPrevention/compare/17.0.0...17.0.11)

## Overview - Add wind charge knockback and damage protection in PVP-safe claims - Treat copper golems as animals requiring container trust - Fix visualization surface detection to always search from world surface downward for consistent results - Add leaves to transparent block list for better visualization placement - Replace sendMessage with sendRateLimitedErrorMessage for PVP messages to reduce spam ## Known Issues: - Copper Golems glitch out visually on untrusted interaction (not harmful) Full changelog: [17.0.9...17.0.10](https://github.com/castledking/GriefPrevention/compare/17.0.9...17.0.10)

## Overview - Quick Fix: /trustlist was broken Full changelog: [17.0.8...17.0.9](https://github.com/castledking/GriefPrevention/compare/17.0.8...17.0.9)

## Overview - Quick Fix: A bug where subdivisions were duplicating after resize + restart Full changelog: [17.0.7...17.0.8](https://github.com/castledking/GriefPrevention/compare/17.0.7...17.0.8)

## Overview - A new unified command architecture consolidates claim-related commands under `/claim` for players and `/aclaim` for administrators. _The unified command system uses a separate `alias.yml` file that is auto-generated with defaults on first run._ - New `/checkclaimexpiry [player]` command provides detailed expiration information. - Various claiming/investigation interaction & visualization improvements. - Fixed a bug where subdivisions couldn't be created on same x/z boundary of parent claims. ## For Developers See `Public Api.txt` in the plugin resources for detailed API documentation, including: - World and Claim Y dimension methods - ClaimYInfo class usage - Code examples for all new APIs Full changelog: [17.0.6...17.0.7](https://github.com/castledking/GriefPrevention/compare/17.0.6...17.0.7)

## Overview - Fixed 3D Subdivisions not persisting/not being deleted after restarts. - Fixed /sethome permission not updating when exiting claims. - Improved the visualization a little. (SnapOverrideHelper) - Improved investigation tool exiting 3D subclaim visualization Full changelog: [17.0.5...17.0.6](https://github.com/castledking/GriefPrevention/compare/17.0.5...17.0.6)

## Overview - Added new config option: ```yaml AllowNestedSubClaims: false ``` when set to true will allow you to create subdivisions inside of each other. *By default they will not inherit the permissions of the parent subdivision, unlike un-nested subdivisions; you will need to /trust players manually to nested subclaims.* - Fixed a weird quirk where trusted parent players were not listed in the /trustlist of subclaims. - Improved claim visualization snapping - messages.yml now supports (`&`) color formatting. [Full Changelog](https://github.com/castledking/GriefPrevention/compare/17.0.4...17.0.5)

## Overview - Improved the centering and scale of the block displays for glow visualizations to reduce Z-fighting on shaders. - Corrected 2D visualizations to rest at sea level instead of going to the sea floor. - Fixed admin claims default visualization mismatching with the glow visualization in water. - Fixed 3D visualizations adding a third layer at sea level if the claim is partially in water. Full changelog: [17.0.3...17.0.4](https://github.com/castledking/GriefPrevention/compare/17.0.3...17.0.4)

## Overview - Added new `VisualizationGlow: false` config setting to enable glowing block display visualizations for claims on 1.19.3+ servers. - Added sign filtering that respects the bannedWords.txt - Added more granular control to eavesdrop permission ([see docs](https://www.youtube.com/watch?v=HxwUNAJHEfg)) ### Fixes for problems in the current griefprevention plugin: - Fixed untrusted players being able to leash and ride boats in claims. - Fixed untrusted players being able to brush suspicious blocks in claims. - Fixed untrusted players being able to use specific lingering potions to harm players in claims. - Fixed resizing of parent claims to prevent new resizes that would exclude a subclaim boundary. - Improved parent claim selection priority when trying to resize a corner when it shares it with a subdivision. Full changelog: [17.0.2...17.0.3](https://github.com/castledking/GriefPrevention/compare/17.0.2...17.0.3)

### Overview - Improved 3D in-air corner selection for resizing. - Fixed 2D subdivision resizing setting new depths for adjacent 3D subdivisions. Full changelog: [17.0.1...17.0.2](https://github.com/castledking/GriefPrevention/compare/17.0.1...17.0.2)

### Overview - Improved claim visualization for clearer create/resize outlines. - Fixed piston behavior around 2D subdivisions in ``` yaml EVERYWHERE ``` and ``` yaml EVERYWHERE_SIMPLE ``` Full changelog: [17.0.0...17.0.1](https://github.com/castledking/GriefPrevention/compare/17.0.0...17.0.1)

Extends classic GP with true Y-aware subclaims, stacked regions, and correct trust handling across vertical layers. Folia supported. Full changelog: [18e5ee0](https://github.com/castledking/GriefPrevention/commit/18e5ee00fcab594c752c5e94683db88393c768af)