World Creation Rules

Who may create worlds, where, and how many.

---

What is checked, in order

Creating a world passes through four independent gates. A player must clear all of them:

Step	Gate	Node	Default
1	See the category tab	buildsystem.navigator.category.<categoryId>	granted unless explicitly denied
2	Create in that category	buildsystem.create.category.<categoryId>	OP
3	Stay within the world limit	buildsystem.create.<visibility>.<amount>, else world.limits.*	unlimited
4	Use the chosen type, template or generator	see Type Restrictions below	varies

buildsystem.admin bypasses steps 2 and 3 entirely: an admin may create in any category and has no world limit.

Steps 1 and 2 are separate on purpose. Denying the navigator node hides the tab; denying the create node leaves the tab visible and browsable but removes its create button.

---

Restricting creation per category

Each navigator category — built-in or custom — has its own create node:

• Node: buildsystem.create.category.<categoryId>

• Default: OP, so a category is closed to normal players until you grant it

# Let builders create in "public" and a custom "events" category, but not elsewhere
buildsystem.create.category.public: true
buildsystem.create.category.events: true

The <categoryId> is the category's id as shown in /setup → Navigator Layout, not its display name. The built-ins are public, private and archive.

Because category ids are created at runtime, the individual nodes cannot be declared in plugin.yml. The parent buildsystem.create.category is registered for discoverability only — granting the parent does not grant its children; grant the specific node you want.

buildsystem.create.category.private and buildsystem.create.private.<amount> are unrelated nodes: the first decides whether a player may create in the private category, the second how many private worlds they may own.

---

Limiting how many worlds a player may create

Limits are counted per player and per visibility, so a cap on private worlds never restricts public ones. Only worlds the player created themselves count toward their own limit.

The limit is resolved in this order, and the first answer wins:

Order	Source	Value
1	buildsystem.admin	unlimited
2	buildsystem.create.public.<amount> / buildsystem.create.private.<amount>	that number
3	world.limits.public / world.limits.private in config.yml	that number
4	nothing set	unlimited

Per-player permission limits

• Public worlds (EVERYONE visibility): buildsystem.create.public.<amount>

• Private worlds (ADDED_PLAYERS visibility): buildsystem.create.private.<amount>

<amount> is a number, or * for unlimited. If a player holds several such nodes the highest wins, so a group hierarchy can raise a limit without removing the lower node first.

# Builders get 3 private worlds, senior builders get 10
builder:     buildsystem.create.private.3
seniorbuild: buildsystem.create.private.10

The config default

world.limits.public and world.limits.private set the limit for players holding no permission node of their own, so you can cap everyone from config.yml and grant exceptions by permission. -1 means unlimited, which is the shipped default.

world:
  limits:
    public: -1    # unlimited
    private: 2    # two private worlds each, unless a node says otherwise

A permission node always beats the config value, and buildsystem.admin ignores both.

The limit is checked when the creation flow starts, not just when the create button is drawn, so it applies however the flow was opened.

---

Type Restrictions

Which standard dimensions a player may pick in the creation menu:

Dimension Type	Permission Node	Default
Normal	buildsystem.create.type.normal	true
Flat	buildsystem.create.type.flat	true
Nether	buildsystem.create.type.nether	true
End	buildsystem.create.type.end	true
Void	buildsystem.create.type.void	true

All five are granted by default via the buildsystem.create parent. Deny the individual node to remove a dimension; the menu then shows it as a barred item rather than hiding it.

---

Template & Generator Restrictions

Templates and custom chunk generators are default-allow: their names are dynamic and cannot be pre-registered, so a player may use any of them unless you explicitly deny the specific node.

Restricting templates

• Node: buildsystem.create.template.<template_name>

• Denying buildsystem.create.template.LobbyGrid blocks that template for the player. The name is the template folder's name on disk.

Restricting custom generators

• Node: buildsystem.create.generator.<generator_name>

• Denying buildsystem.create.generator.CleanroomGenerator blocks that generator when the player is asked which one to use.

Because both are default-allow, granting these nodes changes nothing — only an explicit deny has an effect.

---

Creating folders

Folders are gated separately from worlds:

• Node: buildsystem.create.folder (Default: OP)

• Controls the create-folder button in a category tab. It does not imply permission to create worlds, and world-creation nodes do not imply it.