Limits
How Limits Work
Limits control how many claims, chunks, members, and other resources each player can have. Every player starts with the default values defined in config.yml under players.default.
There are two methods to increase limits beyond the defaults. They cannot be used at the same time — you must choose one or the other for your server.
Important: Permission-based limits and command-based limits are mutually exclusive. If you set limits via permissions, do not also use admin commands to set limits, and vice versa. Using both simultaneously will cause unpredictable behavior.
Method 1: Permission-Based Limits
Use permission nodes to set limits per group or player. This is the recommended method for servers using LuckPerms or similar permission plugins, as it integrates naturally with your rank system.
| Permission | Description |
|---|---|
scs.limit.claims.<amount> | Maximum number of claims the player can create |
scs.limit.chunks.<amount> | Maximum total number of chunks across all claims |
scs.limit.claims-cap.<amount> | Ceiling the player's claims limit can be raised to (2.7.0) |
scs.limit.chunks-cap.<amount> | Ceiling the player's chunks limit can be raised to (2.7.0) |
scs.limit.chunks-per-claim.<amount> | Maximum chunks a single claim may hold (2.7.0) |
scs.limit.radius.<amount> | Maximum radius for /claim radius |
scs.limit.cost.<amount> | Cost per chunk (overrides default) |
scs.limit.cost-multiplier.<amount> | Cost multiplier per additional chunk |
scs.limit.members.<amount> | Maximum members per claim |
scs.limit.roles.<amount> | Maximum custom roles per claim |
scs.limit.warps.<amount> | Claims the player may keep open as public warps at once (highest wins) (2.7.1) |
scs.limit.min-visit-price.<value> | Lowest visit price the player may set on a warp (lowest wins) (2.7.1) |
scs.limit.tax-multiplier.<value> | Multiplier applied to the player's claim tax — 0.5 = half price, 0 = exempt (lowest wins) (2.7.1) |
scs.limit.distance.<amount> | Minimum distance (in chunks) between this player's claims and other players' claims |
scs.limit.delay.<amount> | Teleportation delay in seconds for /claim tp |
scs.limit.max-claim-price.<amount> | Maximum chunk cost cap (0 = no limit, displays as infinity) |
scs.limit.auto-default-timer.<seconds> | Default /claim auto-X timer applied when the player omits [seconds]. 0 = no timer (legacy behaviour). |
scs.limit.auto-max-timer.<seconds> | Hard cap on player-supplied [seconds] in /claim auto-X. 0 = no cap. |
Examples with LuckPerms
# Give VIP players 10 claims and 50 chunks
/lp group vip permission set scs.limit.claims.10
/lp group vip permission set scs.limit.chunks.50
# Give MVP players cheaper chunks
/lp group mvp permission set scs.limit.cost.50
/lp group mvp permission set scs.limit.cost-multiplier.1.0
# Give a specific player a larger radius
/lp user Notch permission set scs.limit.radius.10
# Set teleportation delay to 0 for donors
/lp group donor permission set scs.limit.delay.0When a player has multiple matching permissions (e.g., from different groups), the highest value is used.
Grant a wildcard such as scs.limit.chunks.* (or any scs.limit.<type>.*) to mean unlimited — equivalent to 0. The concrete scs.limit.chunks.<amount> node still sets an exact cap. Applies to scs.limit.chunks.*, scs.limit.claims.*, scs.limit.radius.*, scs.limit.members.* and scs.limit.roles.*. Before 2.6.6 a wildcard grant was misread and silently fell back to the punitive default (max-chunks: 1), so the permission looked ignored. (Added in 2.6.6)
Method 2: Command-Based Limits
Use admin commands to set or adjust limits per player. This is useful for servers that want direct control without a permissions plugin.
Setting a fixed value
/scs player <player> set-<setting> <amount>Overrides the default value for that player.
Adding/subtracting from current value
/scs player <player> add-<setting> <amount>Adds to the player's current limit. Use negative values to decrease.
Available settings
| Setting | Description | Supports add- |
|---|---|---|
max-claims | Maximum claims (0 = unlimited) | Yes |
max-chunks | Maximum total chunks across all claims (0 = unlimited) | Yes |
max-radius | Maximum radius for /claim radius | Yes |
max-claims-cap | Ceiling max-claims can be raised to (0 = none) | Yes |
max-chunks-cap | Ceiling max-chunks can be raised to (0 = none) | Yes |
max-chunks-per-claim | Maximum chunks a single claim may hold (0 = unlimited) | Yes |
default-claim-radius | Default radius the player gets when typing /claim alone — capped at max-radius | Yes |
chunk-cost | Per-chunk claim cost | Yes |
cost-multiplier | Cost multiplier per additional chunk | Yes |
max-claim-price | Cap on /claim sell price (0 = no cap) | Yes |
max-members | Maximum members per claim | Yes |
max-roles | Maximum custom roles per claim | Yes |
max-warps | Maximum public warps the player may keep open (0 = unlimited) | Yes |
distance | Minimum claim distance (in chunks) | Yes |
delay | Teleportation delay in seconds for /claim tp | Yes |
fly | Remaining claim-fly seconds | Yes |
auto-default-timer | Default /claim auto-X timer applied when the player omits [seconds]. 0 = no timer. | Yes |
auto-max-timer | Hard cap on player-supplied [seconds] in /claim auto-X. 0 = no cap. | Yes |
auto-purge-bypass | When true, the player is exempt from the auto-purge sweep. Boolean only — use set- with true or false. | No |
Examples
# Give a player 20 max claims
/scs player Notch set-max-claims 20
# Add 5 more chunks to a player's limit
/scs player Steve add-max-chunks 5
# Set free chunks for a player
/scs player Alex set-chunk-cost 0
# Reduce teleport delay
/scs player Steve set-delay 0
# Cap a player's /claim auto-X timer at 1 hour
/scs player Steve set-auto-max-timer 3600
# Exempt a player from auto-purge
/scs player Notch set-auto-purge-bypass trueMethod 3: Playtime-Based Bonus Limits
On top of the permission and command methods, SimpleClaimSystem can grant players extra claims and/or chunks the longer they have played. It reads the vanilla playtime statistic — so it works retroactively for existing players — and needs no permissions plugin.
The bonus is recomputed when a player joins and, if refresh-interval is above 0, periodically while they are online, so a threshold crossed mid-session applies without a relog. It is added on top of whichever base limit is in effect (permission node or admin-set value) and only ever raises a finite limit: a base of 0 (unlimited — an admin, or scs.limit.claims.*) is left untouched.
How the bonus is computed
bonus = floor(hoursPlayed / every-hours) × amount (capped at max-bonus, 0 = uncapped)
effective limit = base limit + bonus (only when base > 0)Example with the default config (every-hours: 25, amount: 1, max-bonus: 5): a player with a base of 3 claims reaches 4 at 25 h played, 5 at 50 h, and tops out at 8 claims (base 3 + max bonus 5) from 125 h onward. The claim menus reflect the increased limit automatically.
Disabled by default. Enable and tune it under players.playtime-limits — see Configuration → Playtime-Based Limits.
Earnable Limit Ceilings — 2.7.0
The methods above set a limit. A ceiling instead says how far a limit may be earned, so players can grind or vote their way up while their rank decides where they stop.
players:
default:
max-chunks: 3 # what everyone starts with
max-chunks-cap: 0 # 0 = no ceiling (default)
max-claims-cap: 0| Permission | Description |
|---|---|
scs.limit.chunks-cap.<amount> | Ceiling for max-chunks |
scs.limit.claims-cap.<amount> | Ceiling for max-claims |
Typical setup: chunks earned by voting
# Everyone starts at 3 chunks (players.default.max-chunks: 3) and earns more by voting.
# The rank decides the ceiling — no scs.limit.chunks.<n> node anywhere.
/lp group default permission set scs.limit.chunks-cap.100
/lp group vip permission set scs.limit.chunks-cap.1000
# Your vote plugin then simply runs, per vote:
/scs player %player% add-max-chunks 1The ceiling is applied where the limit is written, so add-max-chunks stops at 100 for a default player and at 1000 for a VIP — the command tells the sender when a value was capped. It is also applied when the limit is read, so a playtime bonus (or a scs.limit.chunks.<n> node granted elsewhere) can never push a player past their rank's ceiling. Promoting a player to VIP immediately unlocks the higher ceiling; nothing needs to be re-granted.
0 means no ceiling — the default, so servers that do not use this feature are unaffected. A ceiling never lowers what a player already owns; it only stops the limit from growing further.
Chunks per claim
Separately, players.default.max-chunks-per-claim (permission: scs.limit.chunks-per-claim.<n>) caps how many chunks a single claim may hold — useful to force players to spread out rather than build one giant claim. It is enforced on /claim radius, /claim addchunk and /claim merge, and measured against the claim OWNER's limit when a moderator extends someone else's claim. 0 = unlimited.