Tags
Creators
Details
19.0.1
Compatibility
Required content
Changes
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.ClaimExpirationCheckRateseconds (60 by default), going round every owner in turn.
These players keep their claims:
- anyone online;
- anyone with at least
ExceptWhenOwnerHasTotalClaimBlocksclaim blocks (10000 by default), or at leastExceptWhenOwnerHasBonusClaimBlocksbonus 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.Localetoid_ID, or letPerPlayerLocalepick 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:
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
DaysInactiveandChestClaimDaysto0. - 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.UnusedClaimDaysandAutomaticNatureRestorationare 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.
Optional dependencies
Projects on Modrinth are automatically available through a Maven repository for use with JVM build tools such as Gradle. To learn more about the Modrinth Maven API, click here.
Note: When available, you should use the creator's maven repo instead as it will have transitive dependency information that the Modrinth Maven API does not. You may also end up with duplicate dependencies if you use a mix of Modrinth and non-Modrinth Maven repositories for your dependencies, because the group identifier will be different when served through the Modrinth Maven API.
Maven coordinates:
Version ID:
build.gradle:
repositories {
exclusiveContent {
forRepository {
maven {
name = "Modrinth"
url = "https://api.modrinth.com/maven"
}
}
// forRepositories(fg.repository) // Uncomment when using ForgeGradle
filter {
includeGroup "maven.modrinth"
}
}
}
// Standard Gradle dependency
dependencies {
implementation "maven.modrinth:pqVXF7b5:FJu68dWy"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:pqVXF7b5:FJu68dWy"
}

