GPExpansion v1.2.1

This point release lets holders of GriefPrevention's existing griefprevention.adminclaims permission create GPExpansion-managed signs inside admin claims, restores automatic mailbox-protocol selection on fresh installations, reports malformed sign input in chat without replacing the player's sign text, and prevents generic BlueMap sign-marker plugins from claiming GPExpansion signs.

Admin claims deliberately have no owner UUID. GPExpansion's sign setup paths were still treating Claim#getOwnerID() as the only ownership answer, so an authorized admin-claim manager could build in the area but rent, sell, global, and mailbox setup would reject the claim as unowned. v1.2.1 treats griefprevention.adminclaims as the ownership equivalent only when the target is an admin claim or one of its subdivisions.

The Maven project version is now 1.2.1. One compatibility configuration key was added. No language keys, storage migrations, commands, or permission nodes were added.

Sign Validation Feedback

Malformed rent and sell sign input no longer rewrites the physical sign as [Invalid Rental] or [Invalid Listing]. GPExpansion now leaves every line as the player entered it and reports the validation failure through the existing localized chat messages.

An empty [sell] sign now receives a useful chat explanation that a payment amount is required, instead of displaying an invalid-listing marker on the sign. This also avoids modifying signs that reuse a GPExpansion header for another plugin, including bracket-based BlueMap marker plugins.

Valid GPExpansion sign creation and formatting are unchanged.

BlueMap sign-marker compatibility

Generic sign-marker plugins can treat every bracketed first line as a BlueMap icon. Headers such as [sell], [rent], and [mailbox] could therefore be consumed as map markers before GPExpansion handled them.

The new signs.compatibility.prevent-bluemap-markers option defaults to true. GPExpansion temporarily masks an enabled, configured GPExpansion input header while normal-priority marker listeners run, then restores the exact original component before GPExpansion parses and formats the sign.

The filter is deliberately narrow. It applies only to the configured input headers for enabled GPExpansion rent, sell, mailbox, and global signs. Other marker headers such as [bank], [star], and [shop] remain visible to BlueMap marker plugins.

When protection is enabled, a shared header such as [sell] belongs to GPExpansion and cannot also be used as a BlueMap marker header. Servers that intentionally assign the same header to another plugin can restore the old shared-header behavior:

signs:
  compatibility:
    prevent-bluemap-markers: false

Mailbox Protocol Detection

Fresh GP3D installations default to `real` again

GPExpansion historically selected the mailbox protocol on first startup:

GriefPrevention3D: signs.mailbox.protocol: real;
upstream GriefPrevention: signs.mailbox.protocol: virtual.

The 1.1.2 configuration restructure moved the old top-level mailbox-protocol setting to signs.mailbox.protocol. The bundled configuration and the generic Java defaults both supplied virtual at the new path. VersionManager's GP/GP3D detection only ran when the path was missing, so the bundled value made fresh GP3D installations look like an explicit user choice and short-circuited detection.

GPExpansion now records whether config.yml was created during the current startup. On that first load, it replaces the bundled placeholder with the detected server default even though the nested path already exists. A fresh GP3D server persists real; a fresh upstream GP server persists virtual.

The mailbox protocol is no longer injected by the generic static-default pass. If the nested setting is genuinely missing from an existing configuration, VersionManager can again migrate the old mailbox-protocol value or select a default from the installed GriefPrevention implementation.

After VersionManager writes a detected value or migration, GPExpansion reloads its dedicated configuration wrapper immediately. The selected protocol therefore governs mailbox creation during the same first server session instead of taking effect only after a restart.

Existing choices are not overwritten

The first-install override applies only when that startup created config.yml. Once the file already exists, either explicit value remains authoritative:

signs:
  mailbox:
    protocol: real

or:

signs:
  mailbox:
    protocol: virtual

This means GPExpansion does not silently change a server intentionally using the virtual protocol on GP3D, and it does not flip an established configuration merely because the GriefPrevention implementation changes later.

Upgrade note: if an affected GP3D installation has already completed its first startup and saved virtual, GPExpansion cannot distinguish that generated value from an administrator's intentional choice. Change signs.mailbox.protocol to real once. New installations created by v1.2.1 select and save real automatically.

Admin-Claim Sign Creation

Supported sign types

The admin-claim exception applies to the ownership checks used by:

rent signs;
sell signs;
global claim signs;
purchasable mailbox signs;
self-mailbox signs.

Both manual sign entry and the setup-wizard paths recognize the exception. This includes /rentclaim, /sellclaim, /mailbox, explicit claim-ID validation, location-based claim selection, and the wizard's sign auto-paste authorization.

/rentclaim and /sellclaim tab completion now also offers top-level admin claim IDs to players with griefprevention.adminclaims.

Permission scope remains narrow

griefprevention.adminclaims replaces only the missing owner check for an admin-claim context. It does not grant control over another player's ordinary claim.

The player must still satisfy the existing requirements for the requested sign type, including its creation and economy permissions. Sign limits, enabled/disabled sign settings, mailbox container attachment, nested-subdivision rules, safe global spawn checks, global claim limits and approval, and .anywhere behavior are unchanged.

The existing broad griefprevention.admin bypass also remains unchanged where a sign workflow already supported it.

Admin subdivisions are detected through their parent chain

GriefPrevention forks do not all expose administrative status at the same level. Some report it directly on an ownerless subdivision, while others expose it only on the top-level claim.

GPExpansion now walks the claim's parent chain when determining whether a sign target belongs to an admin claim. The authorization therefore works inside nested admin-claim subdivisions without treating similarly shaped subdivisions in ordinary player claims as administrative.

Real mailboxes preserve admin-claim ownership

Under the real mailbox protocol, placing an instant mailbox creates a 1x1 child claim around its container. That child previously received the sign creator's UUID because ordinary mailboxes are created by the parent claim owner.

When the parent belongs to an admin-claim hierarchy, the generated mailbox child now inherits the immediate parent's owner UUID. For a normal ownerless admin claim, that value remains null; creating the mailbox no longer turns part of the admin claim into the administrator's personal claim.

The mailbox record and sign creator metadata still identify the player who created the mailbox. Existing mailbox purchase and ownership-transfer behavior is unchanged.

Behaviour Changes

A newly created GP3D configuration persists signs.mailbox.protocol: real; a newly created upstream GP configuration persists virtual.
Existing explicit real and virtual values are preserved.
A detected or migrated protocol is active immediately on the same startup.
A player with griefprevention.adminclaims passes GPExpansion's sign ownership gate inside an admin claim or any descendant subdivision.
The same permission does not bypass ownership in ordinary player claims.
Type-specific sign permissions and every non-ownership validation still apply.
Manual creation and wizard-assisted creation now use the same admin-claim decision.
Rent and sell tab completion includes manageable top-level admin claims.
Real-protocol mailbox child claims remain ownerless when created directly beneath an ownerless admin claim.
Malformed rent and sell signs retain their original text and report the error in chat.
An empty [sell] sign explains that a payment amount is required.
Enabled GPExpansion input headers bypass normal-priority bracket-based BlueMap marker handlers by default.
Unrelated BlueMap marker headers are not filtered.

Compatibility

Built against GriefPrevention3D 18.2.7 and Paper 26.2. Parent-chain inspection uses GPExpansion's existing reflective GriefPrevention bridge and is compatible with both top-level-only and subdivision-level admin status reporting.

No data conversion is required. Existing signs, claims, mailboxes, rentals, permission assignments, configuration, and language customizations retain their formats. Existing [Invalid Rental] and [Invalid Listing] signs are not migrated; players can edit or replace them normally.

Configuration and Permissions

New configuration key: signs.compatibility.prevent-bluemap-markers (default: true).
The existing signs.mailbox.protocol first-install default is dynamic again: real for GP3D and virtual for upstream GP.
No new language keys.
No new commands or aliases.
No new permission nodes.
Existing permission used: griefprevention.adminclaims.
Maven artifact version: 1.2.1.

Verification

mvn clean package completed successfully and produced target/GPExpansion.jar for version 1.2.1.
Maven compiled all 105 main source files successfully.
Ten regression tests pass: five cover fresh and migrated mailbox-protocol selection, one prevents physical invalid-sign rewrites, and four cover managed-header masking, unrelated marker preservation, listener ordering, and configuration defaults.
Diff whitespace validation completed successfully.
Live-server verification is still needed for a complete first boot with GP3D and upstream GP, every sign type in a top-level admin claim and nested admin subdivision, denial in an ordinary claim the administrator does not own, setup-wizard auto-paste, real-mailbox child ownership before and after purchase, protected GPExpansion headers with Easy-BMapMarkers installed, and an unrelated BlueMap marker header while protection is enabled.

GPExpansion