GPExpansion v1.2.3
This point release fixes claim flight escaping its claim after a relog. A player who logged off while claim flight was active could log back in, leave the claim or teleport away, and keep flying indefinitely.
The cause was bookkeeping, not permission checks. Minecraft saves a player's ability to fly with their player data, but GPExpansion only remembered in memory that it had granted that flight, and forgot it on disconnect. After a relog the flight looked like it came from another plugin, which claim flight deliberately never revokes.
No configuration keys, language keys, commands, or permission nodes were added. The Maven project version is now 1.2.3; version.config-version remains unchanged.
Read the Upgrade Note before updating. Players who are already stuck with flight from before this release are not repaired automatically.
Claim Flight Ownership
Why relogging kept flight on
Claim flight has to coexist with other sources of flight, such as Essentials /fly. To avoid stripping flight it did not grant, the claim-flight listener tracks which players' flight it enabled, and when claim flight turns on for a player who can already fly, it records that flight as external and leaves it alone on the way out.
That grant marker lived only in memory and was cleared when the player quit. Minecraft, however, persists allowFlight in the player's save data. On the next join:
- The player logged in still able to fly, with no grant marker.
- If they were inside a claim, the join-time reconcile saw flight already enabled without a marker and classified it as external flight.
- Leaving the claim or teleporting then reached the revoke path, which found the flight marked external and returned without removing it.
The flight was claim flight the whole time, but after the relog it could not be revoked by any border crossing or teleport.
Relogging outside a claim was also affected
A player who logged back in outside any claim, for example because the claim was abandoned while they were offline or a staff member moved them, was not stripped of flight either. The revoke path returned immediately because no grant marker existed, so the persisted flight was left enabled.
The grant is now stored on the player
GPExpansion now keeps a persistent copy of its grant marker in the player's persistent data container, under the key gpexpansion:claimfly_granted. Because it is saved with the player, it survives:
- a normal disconnect and reconnect;
- a server restart;
- a crash, where no quit event fires. The marker persists on exactly the same saves as
allowFlightitself, so the two cannot drift apart.
The marker is written whenever claim flight is granted, by a border crossing, the periodic reconciler, or /claimfly enabling flight in place, and it is removed whenever claim flight is revoked.
On join, GPExpansion re-adopts the stored grant before anything else evaluates the player's flight. This also runs when claim flight is disabled in the configuration, so switching the feature off still revokes grants carried over from an earlier session.
On quit, only the in-memory marker is dropped. The persistent copy stays for the next join.
Stale markers are discarded
A stored marker is only trusted when it still describes flight that claim flight manages. It is removed on join instead of being re-adopted when:
- the player can no longer fly, so there is nothing left to revoke;
- the player is in creative or spectator mode, where flight belongs to the game mode and claim flight never touches it.
External flight is unchanged
Flight granted by another plugin never receives the marker, so it is still classified as external and preserved when the player leaves a claim, exactly as before.
Behaviour Changes
- A player who relogs with claim flight active loses it on leaving the claim or teleporting away, as they would have without relogging.
- A player who relogs outside any claim with claim flight persisted from before has it revoked by the join-time reconcile.
- Players with the leaving-claim option (
disable-on-leaving-claim) set tofalsekeep their claim flight across a relog in the wilderness, matching their behaviour before the disconnect. - Disabling claim flight in the configuration now revokes grants made in previous sessions, not just the current one.
ClaimFlyListener#markClaimFlightGrantednow takes aPlayerinstead of aUUID, because it writes to the player's persistent data. This is an internal API used by/claimfly.
Upgrade Note
Players who logged off with claim flight active on an earlier version have no persistent marker, so after updating their flight is still indistinguishable from /fly granted by another plugin and will not be revoked. GPExpansion cannot tell the two apart retroactively.
Clear the flight once for any affected player, for example by turning /fly off for them or switching their game mode away from survival and back. After that, claim flight tracks them correctly.
Configuration and Language
- No new configuration keys.
- No new language keys.
- New persistent player field:
gpexpansion:claimfly_granted(byte). It is written and cleared automatically and needs no management. - Maven artifact version:
1.2.3.
Compatibility
Built against GriefPrevention3D 18.2.7 and Paper 26.2. The marker uses the standard Bukkit persistent data container and is saved with the vanilla player data file. No GPExpansion storage migration is required.
Verification
mvn clean packagecompleted successfully and producedtarget/GPExpansion.jarfor version1.2.3.- The existing suite of 10 unit tests passes. None of them cover claim flight.
- Live-server verification is still needed for: relogging while flying inside a claim and then leaving it, relogging and teleporting away, relogging outside a claim, a server restart with claim flight active, preserved Essentials
/flyacross claim borders, and switching claim flight off in the configuration with a carried-over grant online.