Cube Areas
A cube area is a cuboid (box) region defined by two corner blocks.
Every area belongs to a specific world and its dimension is detected automatically
based on the world name. Areas are stored as individual YAML files in Areas/ and persist across restarts.
Area Properties
| Property | Description |
|---|---|
| ID | Unique identifier used in all commands. Case-sensitive. Can contain / to place the area in a subfolder (e.g. zones/pvp/arena). Cannot be changed after creation — see Folder Organization. |
| Coordinates | Two opposite corner blocks: (x1, y1, z1) to (x2, y2, z2). The corners can be in any order. |
| World | The world name where the area exists (e.g. world, world_nether). |
| Dimension | Auto-detected: minecraft:overworld, minecraft:the_nether, or minecraft:the_end. |
| Color | Hex color code (#RRGGBB) used to render the area outline in the client mod. Set with /area color. |
| Alias | Optional human-readable name displayed in the client mod interface alongside the area ID. |
| Priority | Integer value (default 0). Controls how far outward the area inherits from the areas that contain it. See Priority. |
| Skybox | Optional PNG texture name. When set, replaces the sky for players inside the area. Requires the client mod. See Skybox. |
Folder Organization
Area IDs can contain / slashes to organize areas into virtual subfolders.
The ID becomes the relative file path — for example, an area with ID zones/pvp/arena
is stored at Areas/zones/pvp/arena.yml and its folder hierarchy is created automatically.
Flat areas follow the same pattern under Areas/.flat/.
Using subfolder IDs in commands
Because / is a special character in command parsing, IDs that contain it must be
wrapped in double quotes when typed in a command.
Tab-completion automatically suggests them pre-quoted so you never have to type the quotes manually.
# Creating an area inside a subfolder
/area create cube "zones/spawn" -50 60 -50 50 90 50
# Applying a rule to a specific nested area
/area cube rules add "zones/pvp/arena" no_break
# Tab-completion will suggest: "zones/pvp/arena" (already quoted)Bulk folder operations
Many commands support a bulk mode: if the ID argument ends with /,
the command applies to every area whose ID starts with that prefix.
This lets you manage a whole group of areas in a single command.
# Add no_pvp to every area in zones/pvp/
/area cube rules add "zones/pvp/" no_pvp
# Remove all player limits from areas in events/
/area cube limit remove "events/"
# Apply a color to all areas under worlds/nether/
/area color "worlds/nether/" #FF6600
# Set priority 5 on every area in the lobby/ folder
/area cube priority "lobby/" 5Flat Areas
A flat area is a 2D planar zone defined by a bounding box and a crossing plane position. Unlike cube areas, flat areas do not contain players — instead they detect when a player crosses from one side of the plane to the other. Useful for one-way entry triggers, border detection, or directional events.
How flat areas work
When a flat area is created, the server automatically detects the flat axis (X, Y, or Z)
based on the bounding box geometry. The flatPosition parameter sets the exact
coordinate value of the crossing plane on that axis.
The client mod tracks which side of the plane the player is on. When the player transitions from one side to the other while within the area's bounds, a crossing event fires:
- Positive side — the player moved toward the increasing direction of the axis.
- Negative side — the player moved toward the decreasing direction of the axis.
Flat Area Properties
| Property | Description |
|---|---|
| ID | Unique identifier. Single word, case-sensitive. |
| Bounding box | Defines the region where crossing detection is active. Players outside the bounds are ignored. |
| Flat position | The coordinate value on the flat axis where the crossing plane sits (e.g. 0 for z=0). |
| Flat axis | Auto-detected (X, Y, or Z) from the area geometry. The axis with the smallest span becomes the flat axis. |
Example
# A flat area at z=0 that spans x:-100 to 100, y:60 to 80, z:-5 to 5
# flatPosition=0 → the crossing plane is at z=0
/area create flat border 0 -100 60 -5 100 80 5
# When a player walks from z=-1 to z=1 they cross toward the positive side
# When they walk from z=1 to z=-1 they cross toward the negative sideDimension Areas
A dimension area has no coordinates at all. It covers an entire Minecraft dimension and acts as the
outermost layer that the areas inside it can inherit from. Dimension areas are stored as individual
YAML files under Areas/.dimension/, mirroring how flat areas live under
Areas/.flat/.
They are provisioned automatically
There is deliberately no /area create dimension command. At server
start the plugin scans every loaded world and writes one YAML file for each dimension that does not
already have one. Modded and datapack dimensions are therefore picked up automatically, with no
manual setup.
Provisioning only ever creates missing files. It never overwrites an existing file, and it never deletes the file of a dimension that has disappeared — so removing a mod does not destroy the configuration you wrote for its dimensions. Reinstall the mod and the file is still there.
How the ID is built
The namespace of the dimension key becomes a folder in the area ID. The dimension key
minecraft:the_nether becomes the area ID minecraft/the_nether, stored at
Areas/.dimension/minecraft/the_nether.yml. The colon is replaced by a slash because
: is an illegal character in a filename on Windows. The YAML dimension
field still stores the real dimension key, colon included.
A useful side effect: because the namespace is a real folder, every dimension subcommand also
accepts the folder form. Passing minecraft/ targets
every minecraft:* dimension in one command, and a modded namespace such as
twilightforest/ targets that mod's dimensions.
The default priority is -1
A freshly provisioned dimension area has a priority of -1, while cube areas default to
0. This matters, because a chain is cut as soon as an inner area's priority is
strictly greater than the area containing it — see Priority.
# Let every default-priority area in the Overworld inherit from the dimension area
/area dimension priority "minecraft/overworld" 0
# Same thing for every vanilla dimension at once, using the folder form
/area dimension priority "minecraft/" 0What a dimension area supports
| Feature | Supported | Details |
|---|---|---|
| Basic rules | Yes | /area dimension rules add|remove|list. Applies the rule across the whole dimension. |
| Exceptions | Yes | /area dimension exception add|remove|list. A dimension-wide bypass for a player. |
| Advanced rules | Yes | /area dimension advanced rules add|remove|list, with the same rule types as cube areas. |
| Skybox | Yes | /area dimension skybox add|remove|info. Gives the whole dimension a custom sky. See Skybox. |
| Priority | Yes | /area dimension priority. Controls whether inner areas inherit from the dimension. |
| Creation | No | Files are provisioned automatically at server start; there is nothing to create by hand. |
| Teleport, view, wand | No | A dimension area has no geometry, so there is no corner to select, no box to render, and nowhere to teleport to. |
| Color | No | There is no border to draw, so an outline color would have nothing to apply to. |
| Player limit | No | The limit works by pushing a player back outside the area, and a dimension has no outside. |
| Entry / exit commands | No | They fire when a player crosses the area boundary, and a dimension area has no boundary to cross. |
Every one of the supported subcommands accepts the folder form described above, so you can apply a rule, an exception, an advanced rule, a skybox or a priority to a whole namespace at once.
A freshly provisioned file
id: minecraft/the_nether
type: dimension
dimension: minecraft:the_nether
alias: ''
priority: -1
skybox: ''
rules: []Skybox
Each cube area can have a custom skybox — a PNG texture that replaces the vanilla sky while the player is inside the area. The transition fades in smoothly on entry and fades out on exit. This feature requires the client mod.
A dimension area can carry a skybox too, which gives the whole dimension a custom sky without having to cover it with cube areas.
Which skybox is shown
Skybox resolution follows the same chain as Priority. Walking outward from the smallest area containing the player, the first area that has a skybox assigned wins — so an area's own skybox always beats an inherited one. If the area the player is standing in has no skybox, the sky is inherited from the area around it, and ultimately from the dimension area, unless a priority cut stops the chain first.
# Dimension-wide purple sky for the Nether, and a different sky inside one arena
/area dimension priority "minecraft/the_nether" 0
/area dimension skybox add "minecraft/the_nether" purple_void
/area cube skybox add arena storm
# Inside arena -> storm (the area's own skybox wins)
# Elsewhere -> purple_void (inherited from the dimension area)Setup
-
Prepare the PNG texture
Create a panorama-style PNG image (recommended: 2048×1024 or any 2:1 ratio). Name it anything without spaces.
-
Distribute the texture to clients
Each player must have the file at:
.minecraft/config/ProtectedArea/assets/skybox/<name>.png -
Assign the skybox to the area
/area cube skybox add <area_id> <name>
Commands
/area cube skybox add spawn night # Assign texture "night.png" to area spawn
/area cube skybox remove spawn # Remove the skybox from area spawn
/area cube skybox info spawn # Show the current skybox for area spawn
# The same three subcommands exist for dimension areas
/area dimension skybox add "minecraft/the_end" void
/area dimension skybox remove "minecraft/the_end"
/area dimension skybox info "minecraft/the_end"Basic Rules
Basic rules are global restrictions applied to the entire area. When a rule is active, it applies to all players in the area unless they have an exception. Rules are additive — an area can have any combination of them.
| Rule Key | Description | Note |
|---|---|---|
| no_break | Players cannot break any block inside the area. | |
| no_place | Players cannot place blocks or use buckets (lava, water) inside the area. | |
| no_interact | Blocks all player interactions: containers, doors, buttons, levers, entities, and vehicles. | |
| no_mobgriefing | Entities such as creepers and endermen cannot destroy or modify blocks inside the area. | |
| no_pvp | Players cannot deal damage to other players inside the area. | |
| no_entityattack | Players cannot attack any entities (mobs, animals, etc.) inside the area. | |
| no_damage | Players inside the area take no damage from any source. | |
| no_drop | Players cannot drop items on the ground inside the area. | |
| no_collect | Players cannot pick up items from the ground inside the area. | |
| no_spawn | Natural entity spawning is prevented inside the area. | |
| no_entry | An invisible collision barrier prevents players from entering the area. | CLIENT MOD |
| no_exit | An invisible collision barrier prevents players from leaving the area. Entry is still allowed. | CLIENT MOD |
Advanced Rules
Advanced rules apply restrictions to specific blocks or entities rather than everything. They exist alongside basic rules and give you granular control. There are two categories: YES rules and NO rules.
Priority between basic and advanced rules
YES rules always take precedence over their corresponding basic NO rule.
For example: if an area has the no_break basic rule active, adding a
yes_break advanced rule for minecraft:oak_log means players
can still break oak logs even though breaking is globally disabled.
Similarly, NO advanced rules add restrictions that don't require a global basic rule.
You can block breaking a specific block even in an area with no no_break rule.
Both sides of that comparison are evaluated across the whole
inheritance chain, not just the area the player is standing in. A
yes_break entry on an outer area still lifts a no_break set on an inner
one, as long as the chain between them is not cut by a priority difference.
YES Rules — Allow specific actions
| Rule Type | Target | Description |
|---|---|---|
| yes_break | Blocks | Allow breaking a specific block even when no_break is active. |
| yes_place | Blocks | Allow placing a specific block even when no_place is active. |
| yes_interact | Blocks / Entities | Allow interacting with a specific block or entity even when no_interact is active. |
| yes_drop | Items | Allow dropping a specific item even when no_drop is active. |
| yes_collect | Items | Allow collecting a specific item even when no_collect is active. |
NO Rules — Block specific actions
| Rule Type | Target | Description |
|---|---|---|
| no_break | Blocks | Block breaking a specific block, even without the global no_break rule. |
| no_place | Blocks | Block placing a specific block, even without the global no_place rule. |
| no_interact | Blocks / Entities | Block interaction with a specific block or entity. |
| no_drop | Items | Block dropping a specific item. |
| no_collect | Items | Block collecting a specific item. |
Example
# Museum: everything locked, but players can read signs
/area cube rules add museum no_break
/area cube rules add museum no_place
/area cube rules add museum no_interact
/area cube advanced rules add museum yes_interact minecraft:oak_sign
# Prevent placing TNT specifically (no global no_place required)
/area cube advanced rules add storage no_place minecraft:tnt
# Block interacting with villagers
/area cube advanced rules add market no_interact minecraft:villagerExceptions
Exceptions grant a specific player the ability to bypass one or more rules in a specific area. Exceptions are stored per-area and per-player and persist across restarts.
Exceptions are inherited along the same chain as rules: at any position, the exceptions that count are the union of every exception in the inheritance chain. An exception granted on an outer area therefore also applies inside the areas that inherit from it — including an exception granted on a dimension area, which covers the entire dimension.
| Exception Key | What it bypasses |
|---|---|
all | Every basic rule and the player limit. The player is unrestricted in the area. |
no_break | The no_break basic rule and any no_break advanced entries. |
no_place | The no_place basic rule and any no_place advanced entries. |
no_interact | The no_interact basic rule and any no_interact advanced entries. |
no_pvp | The PvP restriction. |
no_entityattack | The entity attack restriction. |
no_damage | The no-damage rule (the player will take damage normally). |
no_drop | The item drop restriction and any no_drop advanced entries. |
no_collect | The item collect restriction and any no_collect advanced entries. |
no_spawn | Mob spawn prevention (not directly applicable to players). |
no_mobgriefing | Mob griefing prevention. |
no_entry | The entry barrier. The player can walk into the area normally. |
no_exit | The exit barrier. The player can leave the area normally. |
limit | The player limit. The player can enter even when the area is full. |
# Staff member bypasses all rules in the protected zone
/area cube exception add lobby Marquinho all
# Builder can place and break blocks specifically
/area cube exception add lobby Steve no_break
/area cube exception add lobby Steve no_place
# VIP player can enter the restricted barrier area
/area cube exception add vip_lounge VIPPlayer no_entry
# Player can enter even when area is at capacity
/area cube exception add arena VIPPlayer limitPriority
An area inherits from the area that contains it, unless it has strictly greater
priority than that container. Its own configuration always overrides what it inherits.
Cube areas have a default priority of 0; dimension areas are provisioned with
-1.
Priority is therefore not a contest that one area wins. It is the switch that decides how far outward the inheritance chain reaches: raise an inner area's priority above its container to cut it loose, or leave it equal or lower to keep inheriting.
How the chain is built
At any position, the areas that contain that position are ordered from smallest to largest. A dimension area always sorts last, because it conceptually contains everything else in the dimension.
The chain is then walked outward from the smallest area:
- Inheritance continues while each inner area's priority is less than or equal to the priority of the next area out. Equal priority still inherits — which matters, because every area defaults to
0. - The moment an inner area's priority is strictly greater than the area containing it, the chain is cut and nothing further out is inherited at all — not the next area out, and not anything beyond it.
What is resolved from the resulting chain:
- Basic rules, advanced rules and player exceptions are the union of everything in the chain.
- Single-valued properties such as the skybox take the first value found walking outward, so an area's own value always beats an inherited one.
Flat areas do not take part in this at all. They are never placed in the chain, they inherit nothing and nothing inherits from them.
Example — inheritance happens
# Overworld dimension area raised to 0 so areas can inherit from it
/area dimension priority "minecraft/overworld" 0
/area dimension rules add "minecraft/overworld" no_pvp
# Large lobby at the default priority 0
/area create cube lobby -200 60 -200 200 128 200
/area cube rules add lobby no_break
# Standing inside lobby, the chain is: lobby (0) -> minecraft/overworld (0)
# 0 is not greater than 0, so the chain stays open.
# Rules in effect: no_break (from lobby) + no_pvp (inherited from the dimension)Example — the priority cut stops it
# Small arena carved out inside the same lobby
/area create cube arena -30 60 -30 30 128 30
/area cube priority arena 10
# Standing inside arena, the chain is: arena (10)
# 10 is strictly greater than lobby's 0, so the chain is cut immediately.
# Nothing from lobby is inherited, and nothing from the dimension area either.
# Rules in effect: none -> PvP and block breaking both work inside the arena.
# Step outside the arena but stay in the lobby and the chain is open again:
# lobby (0) -> minecraft/overworld (0) -> no_break + no_pvp
Note what the cut costs in that second example: raising arena to 10 does
not only detach it from lobby, it detaches it from everything outside lobby
as well. If the arena still needs a rule that the dimension provides, set that rule on the arena
itself.