MCSkylines

Configuration defaults: Values shown for operator-configurable settings are the bundled defaults, and can be changed in the module’s configuration or definitions. The server’s active settings take precedence, so costs, speeds, ranges, durations, chances, effects, recipes, limits and enabled features may differ. Command examples illustrate syntax; fixed mechanics and validation bounds are not configuration defaults.

The suite is one combined plugin containing sixteen modules. Use this guide to install the server, choose enabled systems, and preserve existing player data. The other encyclopedia pages explain gameplay and operator setup.

Install and update

The City desktop's Node backend is separate from the sixteen gameplay modules. Technology's authenticated bridge starts disabled and needs explicit setup with the existing website, email and optional private R2 storage. See the Technology panel setup. Government schema 5 requires a pre-upgrade database backup for rollback; browser activity earns no Minecraft playtime or salary.

1. Run the suite's supported Paper 1.21.11 server on Java 21. Stop it before replacing plugins.
2. Back up the complete server plugin data, databases, secrets, configuration, and matching resource pack.
3. Remove standalone MC Skylines module JARs and install the current combined MCSkylines-*.jar from the release bundle. Module build JARs are internal inputs.
4. Keep the external plugins required by enabled modules. Keep every existing module data folder; the combined host preserves their namespaces and storage.
5. Distribute the matching complete resource pack. Preserve custom Oraxen assets when merging; an older partial pack can omit current equipment, scopes, vehicles, or sound events.
6. Start the server, run /skylinessuite modules, and resolve each blocked provider before testing its dependent gameplay.

Modules and dependencies

plugins/MCSkylines/config.yml contains one boolean per module and the dependency tree. Switches default to true and require a full restart. Disabling a prerequisite blocks its dependants with a reason; unrelated modules can continue. Optional integrations affect available features rather than enabling a disabled module. Utilities and Industry are prototypes and can be disabled subject to dependencies.

Read the required/optional dependency lists on each module page. Shared menu styling and confirmations belong to the suite host. Core owns /skylines give, so central item issuance needs Core enabled.

Items, menus, and configuration

Items carry persistent identities; renaming ordinary items does not create medical supplies, vehicle titles, tools, or signed cards. Menus use blue frames, green confirmation, red cancellation, gold money, information books, bottom-page arrows, and a map page counter. Disabled arrows mark list boundaries. Confirmations recheck current eligibility; reopening a menu may be necessary after changing data.

Each module retains its own messages and configuration. MiniMessage templates provide wording and colors. A module reload applies only the files documented for that module; it cannot install new Java code or apply host module switches. Restart for database/provider changes and structural configuration where required.

Rollback

Stop the server, remove the combined JAR, restore the previous sixteen JARs and their matching server backup, then restart. Do not run both distributions together. The pre-unification source backup in the workspace includes per-file checksums and the previous complete release; it does not substitute for backing up live server data.

Integrations and persistence

The host refuses simultaneous standalone suite plugins. Retain all module databases and journals together when restoring a backup. Property and Lock retain their legacy AreaShop/Lockette folder migrations. Existing item/entity namespaces and public service packages remain stable. Integrations obtain services through Bukkit's ServicesManager; plugin-name aliases do not prove a module is enabled, and old standalone entry-point casts are unsupported.

Reading command syntax

Configuration defaults: Values shown for operator-configurable settings are the bundled defaults, and can be changed in the module’s configuration or definitions. The server’s active settings take precedence, so costs, speeds, ranges, durations, chances, effects, recipes, limits and enabled features may differ. Command examples illustrate syntax; fixed mechanics and validation bounds are not configuration defaults.

<argument> is required; [argument] is optional. Replace the placeholder, including its brackets, with your value. Choices separated by a vertical bar mean choose one. ... accepts the remaining words. Do not type quotation marks around multiword names unless the command specifically requires them. A bare command has no required arguments. Examples use sample players/IDs: substitute entries from your server and use Tab for configured IDs.

player means a username; operational actions usually require that player online. amount and price are currency values such as 25.00, unless the row specifies items, levels, or units. reason, memo, message, name, and statement accept text where supported. duration uses the module's duration format (for example 10m, 2h, or 7d); it is not a bare number of minutes unless stated. id is the exact identifier displayed by that system, not its friendly name. Permissions and ownership/state/location checks both apply.

Module command

Root commands and aliases

These are the registered command entry points. The subcommand tables above describe their complete operations. Alias names use the same arguments as their root.