GPExpansion v1.2.2

This point release closes three ways a banned player could still act inside a claim they were banned from. The reported one is the most serious: riding any mount across the border bypassed the ban completely, and dismounting left the animal behind inside the claim.

A ban also did not reliably outrank trust, and enforcement only ever considered where the player was standing, never what they were reaching for. Because banning does not remove trust, GriefPrevention still authorized a trusted-but-banned player to interact through the boundary.

Read the Behaviour Changes section before updating. A ban is now enforced against the target of an action rather than only the player's position, so a banned player can no longer break, place, interact with, mount, or attack anything inside the claim from outside it. Public bans are unchanged in that trusted players still pass them.

No configuration keys or permission nodes were added. Two language keys were added, both with bundled defaults. The Maven project version is now 1.2.2; version.config-version remains unchanged.

Mounted Entry

Riding across the border no longer bypasses the ban

A banned player who rode a horse, pig, strider, camel, boat, or minecart into a claim received the claim.ban-blocked-enter chat message and was then free to roam. Nothing else happened.

The move handler was firing correctly. Its two enforcement tools simply do not work on a passenger:

• cancelling PlayerMoveEvent returns the player to the previous position, but the vehicle owns that position and keeps walking in;
• Player#setVelocity is ignored while the player is a passenger, so the boundary knockback did nothing.

The deep-ejection path could not help either, because a passenger cannot be teleported away from its vehicle. That is why the player was only ejected once they dismounted, and why the mount stayed inside the claim.

A mounted boundary crossing now detaches the rider and returns both the rider and the mount to the position the move came from. The knockback path is unchanged for players on foot.

Vehicle movement is checked independently

VehicleMoveEvent is now handled as a second net for rides that move a passenger without a vetoable PlayerMoveEvent. The event is not cancellable, so the mount is put back by hand.

The handler walks the full passenger stack, so a player riding a horse that is itself in a boat is still found. It uses the same block-coordinate change filter and the same flat ban-box index as the move handler, so vehicles that are nowhere near a claim with bans cost one axis-aligned box test.

If the ride began inside the claim, there is no safe previous position to roll back to and the existing safe-ejection search runs instead.

Mounts leave with their rider

Ejecting a rider on its own left the animal parked inside the claim, which is the grief the ban is meant to prevent. Three paths now move the mount as well:

• a rejected boundary crossing returns the mount to the position outside that the ride came from;
• ejection from inside the claim dismounts the player first, then teleports the player and the mount to the same computed exit point;
• a banned rider who dismounts voluntarily inside the claim has their mount relocated to the nearest point outside the claim footprint.

A mount that still carries another player is left alone. Only the banned rider is removed from it, and someone else's boat continues on its way.

The dismount relocation is deferred by one entity tick. EntityDismountEvent fires before the player is actually off, and teleporting a mount that still has a passenger would drag the player along with it. Dismounts that GPExpansion performs itself are flagged and skipped, so the ejection paths are not processed twice.

Mounting across the boundary is denied

Player reach is longer than a claim border is thick. A banned player could stand outside and right-click an animal standing inside to ride it in, which produced no chat message at all because their own position was never in the claim.

EntityMountEvent is now checked against the mount's location. Mounting an entity inside a claim the player is banned from is cancelled and reported with the new claim.ban-blocked-mount message.

Bans and Trust

An explicit ban now outranks trust

The ban check evaluated the public ban and the player's trust before it considered the player's own ban:

if (!pubBanned && !playerBanned) return null;
if (pubBanned && isTrusted(main, player)) return null;

A player who was individually banned from a claim that was also public-banned therefore came back as not banned whenever they held trust. The individual ban was discarded.

A ban naming the player now short-circuits the check before trust is consulted. A public ban still yields to trust, which remains the documented way to public-ban a claim while keeping specific players allowed in.

Bans still do not remove trust

Banning a player deliberately leaves their trust entries untouched, so an unban restores exactly what they had before. GPExpansion enforces the ban above trust instead of destroying trust data that could not be restored.

The consequence is that GriefPrevention, which knows nothing about GPExpansion bans, will still authorize a trusted-but-banned player for anything GPExpansion does not intercept. That is what the next section covers.

Cross-Border Enforcement

Enforcement previously asked only whether the player was standing inside a claim they were banned from. A banned player standing just outside the border could still reach in.

Every one of these is now checked against the location of the thing being acted on, regardless of where the player stands:

Event	Target checked
PlayerInteractEntityEvent	The clicked entity
EntityMountEvent	The mount
EntityDamageByEntityEvent	The victim, for melee and for projectiles resolved back to their shooter
BlockBreakEvent	The broken block
BlockPlaceEvent	The placed block
PlayerInteractEvent	The clicked block, in addition to the existing player-position check

PlayerInteractAtEntityEvent shares its handler list with PlayerInteractEntityEvent and is covered by the same handler.

Denials are reported with the new claim.ban-blocked-interact message on the existing ten-second ban-message cooldown. The claim boundary visualization is now throttled with the message rather than shown per event, because a held left click produces one event per tick.

The existing bypass permissions are unaffected. claim-customization.bans.admin-bypass-permission and claim-customization.bans.bypass-permission are still checked first and exempt their holders from all of the above.

Performance

Every new handler runs behind the flat ban-box index introduced for move enforcement. A location that is not inside the X/Z footprint of any claim with bans is rejected with an axis-aligned box test before any GriefPrevention lookup, config read, or claim resolution happens. Servers with no claim bans configured pay one empty-list check per event.

Behaviour Changes

• A banned player riding any mount is dismounted at the border and returned to the position they came from, together with the mount.
• Mounts are moved out of the claim with the banned rider, including when the rider dismounts inside the claim voluntarily.
• A mount carrying other players is not relocated; only the banned rider is removed from it.
• A player named in a claim's ban list is now banned even when they hold trust and the claim is also public-banned. Previously that combination let them through.
• A banned player can no longer mount, interact with entities, damage entities, shoot entities, break blocks, place blocks, or use blocks inside the claim while standing outside it.
• A banned player who holds trust is affected by all of the above. Bans still do not delete trust entries.
• The ban boundary visualization is now rate limited with the ban message instead of shown on every blocked event.

Configuration and Language

• No new configuration keys. All new enforcement is governed by the existing claim-customization.bans.prevent-entry setting and is skipped entirely when it is false.
• Two new language keys, both with bundled defaults so existing lang.yml files need no edits:

claim:
  ban-blocked-mount: "&cYou cannot ride entities in a claim you are banned from!"
  ban-blocked-interact: "&cYou cannot touch anything in a claim you are banned from!"

• New internal helper: SchedulerFacade#teleportEntity(Entity, Location), the existing player teleport generalized to any entity so mounts follow the same Paper and Folia paths.
• Maven artifact version: 1.2.2.

Compatibility

Built against GriefPrevention3D 18.2.7 and Paper 26.2. EntityMountEvent and EntityDismountEvent are used from org.bukkit.event.entity, where Paper has exposed them since 1.20.6.

VehicleMoveEvent covers everything Bukkit models as a Vehicle: horses, donkeys, mules, camels, llamas, pigs, striders, boats, and minecarts. A mob made rideable by another plugin that does not implement Vehicle is still covered by the player move handler.

No storage migration is required. Existing ban, rental, sale, mailbox, and claim data, configuration, and language customizations retain their formats.

Verification

• mvn clean package completed successfully and produced target/GPExpansion.jar for version 1.2.2.
• The existing suite of 10 unit tests passes.
• Live-server verification is still needed for: riding each vehicle type across a border while banned, a stacked passenger arrangement, a shared boat with one banned passenger, dismounting inside the claim, mounting an animal from outside the border, and each cross-border action as a player who is both trusted and banned.