Invites, templates & chat

Temporary Invites

Invitations can carry an optional duration, after which the member is auto-kicked:

/claim invite <player> [duration] [claim]

The duration argument accepts the same format as ban durations (10m, 12h, 7d, 2w, 1mo, 1y). Omit it for a permanent invite — behaviour is unchanged from previous versions.

How expiration works

• Persistent across restarts — the expiry timestamp is stored in the database alongside the member row, so server restarts don't reset the countdown.
• Precise expiration — a per-invite task fires at the exact expiry moment. A 5-minute safety sweep also runs in the background to catch any edge case (e.g. a task lost to a Folia region being unloaded).
• Online kick notification — if the member is online when the invite expires, they receive a chat message and hear the kick sound. Offline members are simply removed from the claim.
• Owner feedback — the member GUI (Java + Bedrock) shows the remaining time in the member head's lore. The placeholder %expires% resolves to the remaining duration or no-expiration for permanent members.

Claim Templates

Templates let you save a claim's permissions + flags once, then apply them to any of your other claims with a single command:

/claim template save <name>         # save current claim's perms + flags
/claim template apply <name> [claim] # overwrite target claim's perms + flags
/claim template list                   # list your templates
/claim template delete <name>        # remove a template

What's stored

• Role permissions for every role (default + custom)
• All flag values
• The list of custom roles, if any

What's not stored

• Members, bans, spawn point, name, description, icon
• Chunks — templates never change the claim's shape

Per-player scope

Templates are saved per owner. Another player can't apply or see your templates.

Migrations

On plugin startup, templates are backfilled the same way claims are — if a new permission or flag key is added in a future release, your saved templates automatically gain that key (defaulting to the role's factory value) so apply doesn't wipe keys it doesn't know about.

Claim chat (/cc)

/cc <message> broadcasts one line to every online member across every claim the sender owns. Think of it as a "team chat" spanning all your claims — useful when you run several small builds with overlapping groups of trusted players.

• Format is driven by the claim-chat-format lang key (placeholders: %player%, %message%).
• Permission: scs.claim.chat (default true).
• Alias: /claimchat.
• Recipients are computed by taking the union of every member UUID across every claim of the sender — so members who belong to multiple claims only receive the line once.
• Sender always sees their own line.
• If the sender owns no claim, the command is a no-op with a chat message.

Claim-chat socialspy (/scs socialspy) — 2.5.6

/scs socialspy toggles claim-chat spying for the staff member who runs it. While enabled, they receive a copy of every /cc message sent anywhere on the server — even for claims they are not a member of — so staff can keep an eye on private claim chat.

• Permission: scs.admin.socialspy (default op). The same node gates both running the command and receiving the spied messages.
• The toggle is stored per player in their PlayerData settings (socialspy, default false in players.default), so it survives reconnects and restarts.
• Spied messages use the claim-chat-socialspy-format lang key (placeholders: %player%, %message%), prefixed by default with a [Spy] tag to set them apart from chat you legitimately receive.
• Staff who are already a normal recipient of a message (a member of one of the sender's claims) are not sent a duplicate spy copy.
• The current on/off state is shown in the player head lore of /scs player <player>.

Unclaim requests (/requnclaim) — 2.5.0

Players can submit a staff-reviewed request to unclaim a chunk or an entire claim instead of bothering admins in DMs. The full flow is gated by unclaim-requests.* in config.yml.

Player flow

1. /requnclaim [chunk|claim] [reason] while standing inside the target claim. Scope keyword optional (default scope picked from config). Reason optional unless unclaim-requests.reason.required: true.
2. A chat message appears with a clickable [CONFIRM] button. The request is not persisted until clicked — the 60-second token TTL avoids stale confirmations when the player walked out and back into a different claim.
3. After confirmation, the request lands in the staff queue. The player is told to wait; per-player cooldown (unclaim-requests.cooldown-seconds) starts.

Staff flow

1. Online holders of scs.admin.unclaimrequest.notify receive a chat ping when a new request arrives (configurable via unclaim-requests.notifications.notify-staff-on-new-request). A Discord embed is also posted when discord-webhook.enabled is on, so offline staff don't miss it.
2. Run /viewrequnclaim to open the review GUI — every pending request is shown as a player head (the requester's). Hover shows scope, owner, claim name, world+chunk coordinates, reason and submission date.
3. Left-click the head to teleport to the chunk. Shift+right-click to approve (triggers a force-unclaim of the chunk or claim, depending on the scope). Shift+left-click to deny.
4. The requester (if online) is notified of the outcome.

Auto-resolve sweep

An async task scans pending requests on a configurable interval (default hourly) and auto-resolves entries whose target claim no longer exists OR whose requester has been offline for more than the configured threshold. Resolved rows older than archive-after-days are physically deleted from the DB.

Configuration sample

unclaim-requests:
  enabled: true
  scope:
    allow-claim: true     # /requnclaim claim ...
    allow-chunk: true     # /requnclaim chunk ...
  cooldown-seconds: 300   # 0 disables
  max-pending-per-player: 5  # 0 = unlimited
  reason:
    required: false
    min-length: 0
    max-length: 200
  auto-resolve:
    enabled: true
    when-claim-deleted: true
    when-requester-offline-days: 30   # 0 disables
    check-interval-minutes: 60
    archive-after-days: 30            # 0 keeps full history
  notifications:
    notify-staff-on-new-request: true
    notify-requester-on-resolved: true

Permissions

• scs.requnclaim — submit requests (default true).
• scs.admin.viewrequnclaim — open the review GUI (default op).
• scs.admin.unclaimrequest.notify — receive new-request chat pings (default op).
• scs.admin.unclaimrequest.review — approve/deny from the GUI (default op).