Configuration & Permissions

MiniModes is designed to be safe by default and easy to tune: you drop it into your server, and then tighten or expand what players can do using config files and permissions.

This page focuses on:

Config basics

Where MiniModes stores its config and how changes are applied.

Core permissions

Which nodes control access to menus, parties, and game actions.

Roles & examples

Concrete permission sets for players, staff, and builders.

---

1. Where configuration lives

When the plugin starts, it creates a data folder:

• plugins/MiniModes/
  Contains:
  • Core config files (e.g. config.yml, messages.yml, etc. depending on your build)
  • Extension resources (e.g. .mmx files and their assets)
  • Internal storage for mashup/rematch and other runtime data

The exact filenames may differ per version, but the important part is: all MiniModes configuration is under plugins/MiniModes/.

Typical config responsibilities

Even if your exact file names differ, MiniModes configs will usually cover:

• Global behavior

  • Whether to enable the built-in party system
  • Default behavior for /minimodes and /mm
  • Which features are enabled server-wide (Mashup, rematch, spectating)

• UI & messaging

  • Prefixes and colors for chat messages
  • Text in titles, action bars, boss bars, and some GUI labels
  • Cooldowns and timing for pre-game flows (team selection, voting)

• World & game behavior

  • Where temporary game worlds are created
  • Cleanup policies for maps after games end
  • Defaults for game timeouts and AFK handling (if exposed by the version you use)

Whenever possible, prefer config options first and only then override with permissions. Config is for “how the system behaves by default”; permissions are for “who can do what.”

---

2. Reloading configuration

MiniModes provides a command for reloading configuration and extensions without restarting the whole server (exact subcommand names may differ per version, but a common pattern is):

• /mm reload under the /minimodes or /mm root command.

When you:

1. Edit config files under plugins/MiniModes/, and/or
2. Add / remove / update .mmx extension files,

run the reload command to apply:

/mm reload

Typical behavior:

• Re-reads config values (message formats, toggles, limits).
• Refreshes registered games from extensions.
• Respects any permission checks to avoid exposing admin-only features to regular players.

Use this for non-breaking changes.
For plugin updates or deep changes to extensions, prefer a full server restart.

---

3. Permissions overview

MiniModes relies on your permission plugin (LuckPerms, PermissionsEx, etc.). There are two big groups of permissions:

1. Player-facing commands & GUIs
2. Admin / operator controls

The exact permission nodes depend on the version and how the commands are registered. The patterns below are meant as a structure you can adapt to your actual nodes.

3.1. Command structure (conceptual)

Commands are structured roughly as:

• /minimodes and /mm – open the main menu and manage global plugin actions.
• /mm game ... – game-specific operations.
• /party ... – party creation, invites, mashup, etc.

Under the hood, these are typically implemented as:

• MiniModesCommand – for /minimodes and /mm
• GameCommand – for /mm game
• PartyCommand – for /party

Your permission nodes will likely mirror this structure, e.g. something like:

• minimodes.cmd.open
• minimodes.cmd.party.create
• minimodes.cmd.party.mashup
• minimodes.cmd.game.spectate
• minimodes.admin.reload

Use your permission plugin’s /lp verbose or equivalent feature to see exact nodes requested when a player runs a command.

---

4. Core permissions by feature

This section lists feature-level permissions you should consider setting up. Replace the example node names with the specific ones used by your build.

4.1. Opening the game menu

Feature: /minimodes / /mm game selection GUI.

Typical pattern:

• minimodes.menu.open – allow opening the menu
• minimodes.menu.list – allow seeing the list of available games
• minimodes.menu.start – allow starting a game from the menu (usually party leader only)

Suggested usage:

• Regular players:
  • minimodes.menu.open
  • minimodes.menu.list
• Leaders / everyone (depending on your policy):
  • minimodes.menu.start

Even if everyone has menu.start, MiniModes still checks party leadership at runtime, so non-leaders can’t bypass the flow.

4.2. Party system

Feature: /party and all its subcommands.

Key subcommands:

• /party create
• /party invite <player>
• /party accept <player>
• /party leave
• /party kick <player>
• /party list
• /party rematch
• /party mashup <start|stop>

Example permissions to look for or set:

• minimodes.party.create
• minimodes.party.invite
• minimodes.party.accept
• minimodes.party.leave
• minimodes.party.kick
• minimodes.party.list
• minimodes.party.rematch
• minimodes.party.mashup

Notes:

• MiniModes automatically keeps everyone in some party:
  • If you’re not in a party, it silently creates a solo party.
• Only party leaders can:
  • Start games
  • Start/stop mashup
  • Kick members

Permissions just decide whether you can call the relevant commands. Leadership and other guards still apply at runtime.

4.3. Game commands

Feature: managing your current game via /mm game ....

Key subcommands:

• /mm game leave
• /mm game spectate <player>
• /mm game stop
• /mm game win <players…>
• /mm game settings

Example permission patterns:

• minimodes.game.leave
• minimodes.game.spectate
• minimodes.game.stop
• minimodes.game.win
• minimodes.game.settings.view
• minimodes.game.settings.modify

Typical policy:

• All players:
  • minimodes.game.leave
• Trusted players / everyone (optional):
  • minimodes.game.spectate
• Leaders or staff:
  • minimodes.game.stop
  • minimodes.game.win
• Leader-only editing:
  • minimodes.game.settings.modify

At runtime, MiniModes will:

• Let everyone view settings (if the game supports runtime settings).
• Restrict changes to:
  • Those with settings.modify, and
  • The game/party leader, and
  • Settings that are explicitly marked as runtime changeable by the extension.

4.4. Admin & debug

Feature: server operator tools.

Examples:

• /mm reload
• /mm list or /minimodes list – list loaded games
• /mm stats – see internal statistics
• Any force commands under /party or /mm game (force-join, force-stop, etc.)

Possible permission nodes:

• minimodes.admin.reload
• minimodes.admin.list
• minimodes.admin.stats
• minimodes.admin.force.*

Recommended:

• Grant to trusted staff only, or just to op.

---

5. Using permissions to define roles

Here are example permission sets for three roles:

5.1. Regular player

Goal: Can play, use parties, and enjoy Mashup. No admin controls.

# Example: LuckPerms group "default"
permissions:
  # Open the MiniModes menu
  - minimodes.menu.open
  - minimodes.menu.list

  # Basic party functionality
  - minimodes.party.create
  - minimodes.party.invite
  - minimodes.party.accept
  - minimodes.party.leave
  - minimodes.party.list
  - minimodes.party.rematch
  - minimodes.party.mashup

  # Game interactions
  - minimodes.game.leave
  - minimodes.game.spectate  # Optional: spectating could be limited to donors

Players do not get any admin nodes or force commands.

5.2. Builder / game tester

Goal: Can start/stop games more freely and adjust settings to test maps and extensions.

# Example: LuckPerms group "builder"
inheritance:
  - default

permissions:
  # Ensure they can start games from the menu
  - minimodes.menu.start

  # Allow game control
  - minimodes.game.stop
  - minimodes.game.win
  - minimodes.game.settings.view
  - minimodes.game.settings.modify

Combine with any build-world protections you already have.

5.3. Admin / operator

Goal: Full control over the plugin and its games.

# Example: LuckPerms group "minimodes-admin"
inheritance:
  - builder

permissions:
  # Administrative actions
  - minimodes.admin.reload
  - minimodes.admin.list
  - minimodes.admin.stats
  - minimodes.admin.force.*

  # (Optional) If you prefer wildcard patterns:
  # - minimodes.*

You can also just use op if your network is small, but explicit permission groups are safer for larger servers.

---

6. Interaction with game extensions

Each MiniModes extension (your .mmx files) can define:

• Its own commands and corresponding permissions.
• Additional settings that show up in:
  • Team selection
  • Settings voting
  • Runtime settings

Common patterns:

• Per-game permission to join / see the game in the main menu.
  Example: minimodes.game.<game-id>.play
• Per-game permission for staff-only modes or maps.
  Example: minimodes.game.<game-id>.map.staff_only
• Per-game permission to host or force start a specific mode.
  Example: minimodes.game.<game-id>.host

When you add a new extension:

1. Check its documentation for extra nodes.
2. Give these to the appropriate groups (players, staff, builders).
3. Optionally hide experimental games behind staff-only permissions.

If a player can open MiniModes but does not have permission for a specific game, you have two typical behaviors:

• The game is hidden from them in the menu.
• Or it is visible but marked as locked/unauthorized when clicked.

The exact behavior depends on the extension and your MiniModes version.

---

7. Best practices

7.1. Start restrictive, then open up

1. Grant only essential permissions to default.
2. Let players try the system.
3. Add more nodes as needed, not all at once.

This avoids accidental exposure of admin tools.

7.2. Use groups, not per-player nodes

Define roles like:

• default – regular players
• minimodes-player – optional donor or “games access” role
• minimodes-builder – map testers and builders
• minimodes-admin – full control

Then assign groups to players, rather than hand-adding nodes.

7.3. Audit permissions with verbose logging

Most permission plugins offer a verbose mode. Use it to:

1. Run /lp verbose on (or equivalent).
2. Have a player attempt a command or action.
3. Check the logs to see which permission node was queried and denied.
4. Grant that node to the correct group.

This is invaluable when adding new extensions or after updating MiniModes.

---

8. Checklist for going live

Before you open MiniModes to all players:

• Confirm core config is set:
  • Game worlds directory is correct.
  • Messages are branded for your server.
  • Default behavior for Mashup & rematches is what you want.
• Define permission groups:
  • default (players)
  • builder (optional)
  • admin (staff)
• Test flows with a non-op test account:
  • /minimodes / /mm
  • Basic /party commands
  • Starting a game from the menu
  • Leaving and spectating
• Verify admins can:
  • Reload config and extensions
  • List games and see stats
  • Force stop or fix stuck games if necessary

With config and permissions tuned, MiniModes becomes a controlled sandbox: players enjoy a streamlined UX, while you retain precise control over what they can do.

---

If you share your exact permission nodes (from your build or docs) I can help you turn this conceptual layout into a drop-in YAML/JSON config for your permission plugin.