GriefPrevention tasks

Task guides and troubleshooting for GriefPrevention. Check the installed release before changing configuration or data.

Choose GriefPrevention access trust without exposing containers

A visitor who only needs buttons and doors does not necessarily need a claim’s storage. Use the documented trust tiers to grant the smallest useful access and verify it with an ordinary account.

Before you start

GriefPrevention has different documentation for legacy v16 and newer alpha releases. Match your installed branch before following commands. Test with a claim owner and an untrusted account, and keep claim ownership distinct from operator or bypass permissions.

Work through the check

  1. Check whether the server runs legacy v16 or a newer branch, then open the command documentation matching that release before changing trust.
  2. As the owner, stand inside the target claim and inspect /TrustList, recording the visitor’s existing access and any subdivision context.
  3. Use the documented /AccessTrust <player> control for a test visitor, then test a harmless button or other supported access interaction and a separate storage chest.
  4. Compare with the documented /ContainerTrust tier on an isolated example only if storage access is actually required; test building separately from both tiers.

Confirm the result

The visitor should perform only the intended access interactions while containers and building remain protected. The owner’s storage and the neighboring claim should remain unchanged.

If the result differs

A visitor may already inherit broader trust from a parent claim or hold administrative bypass permission. Inspect the complete trust list and repeat with a clean normal account before concluding that access trust is too broad.

Recover safely

Remove only the accidental visitor grant with the documented untrust control and restore any recorded prior trust level. Do not use an all-players untrust command, which would disrupt unrelated members.

Documentation and related help

Check the GriefPrevention maintainer documentation and GriefPrevention maintainer reference against your installed release before applying changes.

Restrict a GriefPrevention subdivision without changing the parent claim

A subdivision can inherit permissions from its parent. If a private room remains accessible to parent members, check inheritance before moving chests or recreating the whole claim.

Before you start

GriefPrevention has different documentation for legacy v16 and newer alpha releases. Match your installed branch before following commands. Test with a claim owner and an untrusted account, and keep claim ownership distinct from operator or bypass permissions.

Work through the check

  1. Confirm the installed GriefPrevention branch and record the parent claim’s boundaries, owner and trust list before creating or editing a subdivision.
  2. Use the branch’s documented subdivision mode and define a small test area inside the parent, preserving the parent boundary.
  3. Inspect the subdivision trust and, where supported, use /RestrictSubclaim while standing in the intended subdivision to stop inherited permissions before adding its specific members.
  4. Test a parent-only member and a subdivision member inside the room and in the surrounding parent area, using harmless interactions and no operator bypass.

Confirm the result

The restricted subdivision should follow its intended local trust while the surrounding parent retains its original members. A player trusted only in the room should not gain unrelated claim access.

If the result differs

If access remains open, verify the player is actually inside the subdivision and has no direct broader permission. Tool modes and inheritance details differ between release branches.

Recover safely

Restore the recorded subdivision rules if the trial excludes intended members. Return the tool to basic claim mode after editing; do not abandon the parent claim to repair a room’s trust settings.

Documentation and related help

Check the GriefPrevention maintainer documentation and GriefPrevention maintainer reference against your installed release before applying changes.

Resize a GriefPrevention claim while preserving its protected build

A claim resize changes which blocks remain protected. Measure the complete build and available claim blocks before moving a corner so storage or farms are not accidentally left outside.

Before you start

GriefPrevention has different documentation for legacy v16 and newer alpha releases. Match your installed branch before following commands. Test with a claim owner and an untrusted account, and keep claim ownership distinct from operator or bypass permissions.

Work through the check

  1. Confirm the installed release branch, take a backup and record both existing claim corners, the owner and the claim-block totals from the supported claims-list display.
  2. Inspect the proposed new border around every part of the build, including detached farms and containers, and check for neighboring claims.
  3. Use the documented claim tool as the owner to move the intended corner, keeping the change small enough to verify immediately.
  4. Inspect the new boundary and claim-block accounting, then test an outsider’s harmless build attempt near each changed edge and beside important storage.

Confirm the result

The intended build should remain inside the protected boundary, with available claim blocks adjusted consistently. The resize must not affect the neighboring claim’s owner or permissions.

If the result differs

An insufficient claim-block balance, minimum claim size or overlapping neighbor can reject the resize. Read the exact message before granting an administrative bypass or changing global limits.

Recover safely

Restore the recorded original corner promptly if a protected structure falls outside. Keep both the world and claim-data backup; do not abandon and recreate the claim, which can temporarily expose the entire base.

Documentation and related help

Check the GriefPrevention maintainer documentation and GriefPrevention maintainer reference against your installed release before applying changes.

Explain GriefPrevention accrued and bonus claim-block totals

A player’s usable claim blocks are not simply the number of blocks they see in one reward message. Distinguish accrued allowance, bonuses and blocks already committed to claims.

Before you start

GriefPrevention has different documentation for legacy v16 and newer alpha releases. Match your installed branch before following commands. Test with a claim owner and an untrusted account, and keep claim ownership distinct from operator or bypass permissions.

Work through the check

  1. Record the player’s claims-list totals and each claim size using the command reference for the installed release branch.
  2. Read the active accrual rate, cap and any permission-based bonus policy, noting whether the player meets the configured conditions for earning blocks.
  3. Compare the expected total allowance with used area and any recent resize, purchase or rank change, keeping these events separate in a small ledger.
  4. Observe a controlled eligible play period or an isolated test reward, then recheck the displayed totals without adjusting the live player’s data.

Confirm the result

The remaining allowance should be explainable from accrued and bonus blocks minus claimed area, subject to the installed policy. A rank removal may affect a permission-based bonus differently from ordinary accrual.

If the result differs

Idle time, an accrual cap or an outdated display can explain a smaller increase than expected. Do not repeatedly award bonus blocks while an active scheduler or rank system is still changing the same allowance.

Recover safely

If a verified correction is needed, record the exact difference and use the release’s supported narrow administrative control. Preserve the original totals and avoid resetting every player’s accrued balance to solve one discrepancy.

Documentation and related help

Check the GriefPrevention maintainer documentation and GriefPrevention maintainer reference against your installed release before applying changes.

Check GriefPrevention siege and PvP behavior on a test claim

A siege feature changes the expectation of safety inside claims. Review the active policy on an isolated copy before enabling it or telling a player that claim protection guarantees PvP immunity.

Before you start

GriefPrevention has different documentation for legacy v16 and newer alpha releases. Match your installed branch before following commands. Test with a claim owner and an untrusted account, and keep claim ownership distinct from operator or bypass permissions.

Work through the check

  1. Identify the installed GriefPrevention branch, check whether siege is supported and enabled, and record the world’s PvP and combat settings.
  2. Read the branch-specific siege rules, permissions and any breakable-block configuration, together with other combat plugins installed on the server.
  3. Prepare a disposable test claim and two ordinary accounts with inexpensive gear, then follow only the documented siege flow on that isolated server.
  4. Record combat access, permitted interactions and the documented end conditions, checking the same accounts outside a siege as a control.

Confirm the result

The observed behavior should match the advertised policy for combat and claims. Ordinary claim permissions outside the test siege should remain unchanged.

If the result differs

Siege is disabled by default in the command reference, and releases or addons may change its availability. If a command is missing, do not install a random fork or grant broad bypass rights to simulate it.

Recover safely

Restore the recorded test settings and remove temporary permissions after checking the feature. Preserve production claims and inventories; a live combat experiment is not a suitable way to investigate a protection complaint.

Documentation and related help

Check the GriefPrevention maintainer documentation and GriefPrevention maintainer reference against your installed release before applying changes.

Keep GriefPrevention administrative claims separate from player claims

An administrative claim belongs to the server administration rather than a player’s personal allowance. Use it deliberately for shared infrastructure and leave player claims under their existing owners.

Before you start

GriefPrevention has different documentation for legacy v16 and newer alpha releases. Match your installed branch before following commands. Test with a claim owner and an untrusted account, and keep claim ownership distinct from operator or bypass permissions.

Work through the check

  1. Check the installed release’s administrative-claim documentation and grant only the documented administrative permission to the responsible staff account.
  2. Record the boundaries and nearby claim owners for the intended empty test area, then switch to the documented /adminclaims mode before creating the example.
  3. Inspect the resulting owner and trust list, test intended visitor interactions with a normal account and confirm the staff member’s personal claim allowance was not used.
  4. Return to /basicclaims after the task and verify the tool mode before the staff member next manages personal land.

Confirm the result

The administrative area should have the intended server ownership and visitor policy, while existing player claims retain their owners and allowances. Ordinary visitors should not receive administrative editing powers.

If the result differs

Staff with administrative-claim permission can manage those claims broadly; it is not a room-specific helper permission. Keep that authority separate from normal trust grants and never test protection with the same bypass-capable account.

Recover safely

Restore the recorded trust settings if the visitor policy is too open. Do not transfer a real player’s claim to administrative ownership merely to bypass an access problem; investigate its existing permissions first.

Documentation and related help

Check the GriefPrevention maintainer documentation and GriefPrevention maintainer reference against your installed release before applying changes.