▶️ ЗАБЕРИ СВОИ 8 ПОДАРКОВ 🎁 ПРИ СОЗДАНИИ СВОЕГО МАЙНКРАФТ СЕРВЕРА
Плагины/GPExpansion
GPExpansion

GPExpansion

The ultimate add-on for GriefPrevention 3D Subdivisions

Оцените первым
710
4
Все версииGPExpansion v1.1.19

GPExpansion v1.1.19

Release11.08.2026

Список изменений

GPExpansion v1.1.19

This release fixes several places where GPExpansion had the right data but used it at the wrong level or delivered it at the wrong time.

The most visible example was CrowBar claim waypoints. A live report showed only 102 claims taking roughly 23 minutes to appear. Those claims were already loaded in memory and could be prepared in milliseconds; the delay came from sending one snapshot shortly after join, before the client had reliably advertised its custom payload channel, then waiting for an unrelated claim event to cause another send. GPExpansion now refreshes when CrowBar registers the channel and has a short delayed fallback.

The other headline changes are in claim administration: the flags GUI now shows the effective state GPFlags actually enforces, subdivisions keep their own flags and snapshots, admin claims can be managed by administrators, and rent/sell/mailbox signs accept compact prices such as 1k, 2.5m, and 1b.

Read the Behaviour Changes section before updating. The money-payment cap changed from 9,999,999.99 to 2,000,000,000. Existing signs above the old cap can therefore charge substantially more than they did before.

No configuration keys or permission nodes were added. The Maven project version is now 1.1.19; version.config-version remains unchanged.

Bug Fixes

CrowBar claim snapshots no longer depend on winning the join race

The old join path waited one tick and called rebuildAll(). That had two separate problems:

  • the payload could be sent before CrowBar's crowbar:claim_data receiver had been registered with the server;
  • one joining player caused the claim set for every online player to be recalculated and serialized.

If the first payload was missed, GPExpansion had no acknowledgement or retry. CrowBar correctly continued to show Collecting claims... Please wait., and the player only recovered when a trust, claim, colour, name, spawn, or other waypoint event happened to trigger a global rebuild. That explains why a 102-claim server could appear to spend 23 minutes "caching": it was waiting for a resend, not processing claims for 23 minutes.

Delivery now has three opportunities:

  1. A targeted refresh is still scheduled one tick after join for the fast path.
  2. PlayerRegisterChannelEvent triggers another targeted refresh as soon as Paper reports that the player registered crowbar:claim_data. This is the first delivery point known to have a listening CrowBar client.
  3. A final targeted refresh runs after 60 ticks, roughly three seconds, as a fallback for unusual registration timing.

This is a server-side protocol fix. The JSON format and channel name are unchanged, so existing CrowBar clients can receive the more reliable delivery without a matching client update.

World changes now refresh only the player who changed worlds. Quits only discard that player's vanilla waypoint state; they no longer rebuild anyone else, because another player going offline cannot change claim ownership or trust visibility.

Claim flags show what GPFlags actually enforces

The flags GUI previously read only the raw flags stored directly on a claim. GPFlags resolves flags through a wider effective chain: the claim, its parent, defaults, world settings, and server settings. As a result, the GUI could display a flag as disabled while GPFlags was actively enforcing an inherited value.

GPExpansion now reflects into GPFlags's effective lookup and uses that result for every flag shown in the GUI. An inherited value is marked with:

(inherited from world/server, not set on this claim)

Toggling also starts from the effective state and writes an explicit opposite override to the claim. It no longer removes a raw value and accidentally allows an inherited parent, default, world, or server value to take over again.

/claim flags targets the subdivision the player is standing in

Some GriefPrevention-compatible lookup paths return a parent claim even when the player is inside a subdivision. Since GPFlags stores values by claim ID, that opened the parent's flags instead of the subdivision's.

When /claim flags is used without an explicit claim ID, GPExpansion now checks the resolved parent's children and narrows the target to the subdivision containing the player's full X/Y/Z position.

Snapshots preserve subdivision identity

The shared claim context used to retain only the top-level claim for snapshot operations. Taking a snapshot while standing in a rented or independently managed subdivision could therefore snapshot the parent and store the result under the parent's ID.

The context now carries both the top-level claim and the claim actually resolved at the player's position. Snapshot creation, listing, restoration, and deletion use the resolved claim ID, so subdivisions get their own snapshot history and bounds.

Administrators can manage ownerless admin claims

Ownership-gated claim actions treated an administrative claim as unmanageable because admin claims deliberately have no owner UUID. A player with griefprevention.adminclaims is now treated as the manager of an admin claim for GPExpansion's shared claim-management checks.

This does not grant access to ordinary player claims and introduces no new permission. It makes GPExpansion agree with GriefPrevention's existing administrative-claim permission model.

Sign Prices

Compact k, m, and b amounts

Rent, sell, and mailbox sign parsing now accepts case-insensitive shorthand:

  • 1k = 1,000
  • 2.5m = 2,500,000
  • 1b = 1,000,000,000
  • an L suffix remains available for XP levels where that economy type supports it

Shorthand is expanded to plain digits before the existing payment and rental code sees it. Fractional shorthand is multiplied and rounded down to a whole unit; for example, 1.2345k becomes 1,234.

The setup wizard accepts the same syntax. When it generates sign lines from a whole numeric price, it automatically compacts exact multiples of a billion, million, or thousand so large prices fit more comfortably on a sign. Values that are not exact multiples are left unchanged rather than approximated.

Maximum amount is 2 billion

New shorthand or numeric sign amounts above 2,000,000,000 are rejected. The limit keeps item, XP, and claim-block paths inside their integer-backed ranges.

The money withdrawal path previously clamped the amount to 9,999,999.99. A sign displaying a larger stored price could therefore charge only the old cap. It now uses the same 2-billion ceiling as parsing.

Upgrade consequence: audit existing money-based rent, sell, and mailbox signs whose stored price exceeds 9,999,999.99. They will now charge the intended amount, up to 2 billion, instead of silently undercharging at the old cap.

Performance

Waypoint refreshes do less work

Join and world-change refreshes now scan claims for only the affected player. With P online players and C claims, a join's visibility work changes from approximately P × C checks to C. The improvement scales directly with online player count; a join with 50 players online performs roughly 50 times fewer visibility checks.

Global rebuilds are still required when claim visibility or metadata genuinely changes, but they now:

  • walk the GP3D in-memory claim collection once;
  • prepare each visible claim's anchor, display name, colour, and deterministic waypoint UUID once;
  • pass each viewer's final claim list directly to JSON serialization and vanilla waypoint syncing instead of repeatedly scanning the union of every viewer's claims.

Claim-event bursts are coalesced with one queued rebuild per tick. Bulk operations that fire many create, resize, trust, or metadata events no longer enqueue an identical full refresh for every event in that burst.

GP3D itself required no change for this work. DataStore#getClaims() and direct UUID trust checks are already in-memory; the observed multi-minute wait was delivery timing, not disk access or GP3D claim lookup time.

Internal Command Routing

GUI buttons, command interception, the GP3D command addon, and nested /claim fly dispatch used to construct anonymous Bukkit Command objects solely to call ClaimCommand#onCommand or its tab completer. The command implementation only needed a command name.

ClaimCommand and ClaimFlyCommand now expose direct name-based entry points, and tab completion has the same path. All internal callers use those methods, removing the synthetic command objects while preserving Bukkit's normal executor entry points for registered commands.

This is intended as an internal cleanup. It does not change command names, aliases, syntax, permissions, or scheduling behavior.

Behaviour Changes

  • CrowBar claim data should arrive immediately when channel registration is observed, with a roughly three-second fallback instead of waiting indefinitely for another claim event.
  • The flags GUI reports effective inherited values. A flag may now display as enabled even when there is no raw flag entry on that claim; that is the state GPFlags was already enforcing.
  • Toggling an inherited flag creates an explicit claim override. It no longer means "remove this claim's entry and fall back to inheritance."
  • /claim flags and snapshot operations preserve subdivisions instead of silently targeting the parent claim.
  • Holders of griefprevention.adminclaims pass GPExpansion's ownership gate for ownerless admin claims.
  • Existing money signs above 9,999,999.99 can charge more after updating, up to the new 2-billion ceiling.
  • The setup wizard's default invalid-price message now mentions 1k, 1m, and 1b. Existing customized lang.yml values are not overwritten merely because the bundled wording changed.

Compatibility

Built against GriefPrevention3D 18.2.7 and Paper 26.2. The waypoint delivery change uses Bukkit/Paper's standard plugin messaging and PlayerRegisterChannelEvent; it does not require a new CrowBar payload format.

GPFlags remains an optional reflective integration with no compile-time dependency. Effective-state display expects a GPFlags build exposing FlagManager#getEffectiveFlag(String, Claim, World). If that method is absent or incompatible, GPExpansion logs the reflective failure rather than preventing the plugin from enabling.

No storage migration is needed. Existing claims, flags, snapshots, signs, and configuration files retain their formats.

Configuration and Language

  • No new configuration keys.
  • No new permission nodes.
  • No new commands or aliases.
  • No new language keys.
  • The existing wizard.invalid-price bundled default now documents shorthand amounts.
  • Maven artifact version: 1.1.19.

Verification

  • mvn test and mvn package completed successfully for GPExpansion.
  • The full GriefPrevention3D Gradle test suite completed successfully; GP3D source was not changed.
  • The pre-fix waypoint failure was observed live as an approximately 23-minute wait with 102 claims, which is what identified the delivery race. The new registration-driven and delayed retry paths have compiled successfully but still need confirmation through a fresh client join on a live server.

Файлы

GPExpansion.jar(1.45 MiB)
Основной
Скачать

Метаданные

Канал релиза

Release

Номер версии

1.1.19

Загрузчики

Bukkit
Folia
Paper
Purpur
Spigot

Версии игры

1.20–26.2

Загрузок

9

Дата публикации

11.08.2026

Загрузил

ID версии

Главная