Download File

# 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.