GPExpansion v1.1.13

Turning claim flight off previously changed its behaviour but not its cost. ClaimFlyListener.onPlayerMove() kept doing a GriefPrevention claim lookup for every player, every block, regardless of the setting. This release moves the check to the top of the handlers.

No config migration is required and the default is unchanged (enabled: true), so servers that use claim flight are unaffected.

Performance

`claim-flight.enabled: false` did not disable the per-move work

The claim-flight.enabled flag has existed for several releases, but it was only consulted inside ClaimFlyManager.canUseClaimFlight() — reached at the end of the handler, after the expensive part had already run. Disabling the feature stopped players from being granted flight and saved essentially nothing on the server tick.

Three costs stacked up on the movement path:

Vertical movement counted as a claim transition. The early-return required X, Y and Z to be unchanged, so falling, jumping, and swimming each triggered a lookup on top of horizontal travel.
The lookup is reflective. GPBridge.getClaimAt() reaches into GriefPrevention's DataStore through Method.invoke. It passes null for the cached-claim argument, which defeats GP's own lookup cache, and a null result is retried a second time with ignoreHeight=false — so a player crossing wilderness cost two reflective invokes per block.
player.updateCommands() on every claim boundary crossing, which re-serializes the full command tree and resends it to that client.

Separately, a per-player reconciler task ran another getClaimAt() every 40 ticks (2 seconds) for every online player, also without checking whether the feature was enabled.

What changed

A new isFeatureEnabled() guard runs at the top of onPlayerMove, onPlayerTeleport, onPlayerJoin, and onEntityDamage, before any claim lookup. When claim flight is off, the movement handler is a single boolean config read and a return.
The reconciler honours the flag too. Rather than being cancelled, it drops from a 40-tick to a 200-tick cadence and skips the claim lookup entirely, so the feature can be switched back on without a restart.
On the first disabled tick, the reconciler calls revokeClaimFlight() for anyone still holding a grant. Players who were mid-flight when the switch was flipped are landed through the normal path, including the landing-grace-seconds slow-falling effect, instead of being left with a stale grant.

This has not been benchmarked, so no TPS figure is quoted — the claim is structural, that the work no longer happens, not a measured improvement.

Configuration

Nothing to migrate. config-version stays at 1.1.2; no keys were added or renamed. To disable:

claim-flight:
  enabled: false

/gpx reload picks the change up on a running server — reloadAll() refreshes the config manager the guard reads from. Flipping it back on re-enables claim flight within one reconciler tick (up to 10 seconds) without a restart.

The key gained an explanatory comment in the shipped config.yml. Existing server configs are not rewritten, so the comment only appears in freshly generated files; the behaviour is identical either way.

Notes

No API, permission, placeholder, or command changes.
Behaviour with enabled: true is unchanged. The guard is an added short-circuit on the disabled path only.
The costs described above still apply when the feature is enabled. They were left alone deliberately, as out of scope for a master switch. Worth revisiting if claim flight is on and onPlayerMove still shows up in a profile:
- passing the player's last-known claim as the cached-claim hint instead of null, so GP can short-circuit its own lookup — likely the largest single win;
- skipping the redundant second ignoreHeight=false invoke in wilderness;
- reconsidering whether pure Y-axis movement needs to re-resolve the claim.

GPExpansion