秦淮系列文档

English

简体中文

English

简体中文

Appearance

Installation and Environment ​

Previous: Overview　·　Next: Quick Start

Environment requirements ​

ItemRequirementNote
ServerPaper / Purpur / Spigot 1.21.11+QR places structures using the Bukkit native structure API, which requires a newer core
Java25+Consistent with the rest of the Qinhuai suite
Hard dependencyQinhCoreLibMust be installed first; without it, QR simply won't enable

On startup QR self-checks: if QCL isn't loaded → it logs an error to the console and disables itself; if the server version doesn't match → it disables itself the same way. When you see that QinhRuins x.xx.x logo banner in the log, it means enabling succeeded.

Installation steps ​

  1. First put QinhCoreLib into plugins/ (it's the foundation of the whole suite).
  2. Put the QinhRuins jar into plugins/.
  3. (Optional) Install any soft dependencies you need (see the table below).
  4. Start the server. On first launch, QR releases a full set of default resources into plugins/QinhRuins/:
    • config.yml — the main configuration
    • templates/_example/ — an annotated ruin template example (folders starting with _ are ignored and not loaded as real ruins)
    • generators/*.yml — 17 built-in placement profiles
    • loottables/*.yml — three example loot tables: default / vault / realm
    • affixes.yml — the affix library
    • scripts/affix_example.js — an affix script example
    • lang/<language>/*.yml — text in 7 languages
  5. In-game, run /qr version to confirm the version, and /qr for help.

Caution

After first launch, don't rush to delete _example — it's the best template to copy and modify from.

Soft dependencies and the degradation table ​

QR's backends are all auto-detected, with no manual configuration required. Whichever soft dependency is missing, the corresponding capability degrades gracefully and the plugin starts as usual:

Soft dependencyCapability providedWhat happens without it (degradation)
MythicMobsSpawning custom mobs (mm-mobname in blueprints)Mobs with the mm- prefix won't spawn; vanilla entity names work as usual
QinhClass / MMOCoreSource of player growth and partyGrowth scaling degrades to neutral; parties degrade to QR's built-in temporary party (/qr party)
QinhItems / NeigeItems / MMOItemsCustom item references for loot / keystones / guide itemsitem: resolution from these sources fails and is skipped; vanilla: vanilla items work as usual
ItemsAdder / CraftEngine / NexoResource-pack textures for keystones / guide itemsSame as above, falling back to vanilla textures
PlaceholderAPIAll %qinhruins_*% placeholders, loot table condition placeholdersPlaceholders aren't resolved; a loot condition is treated as always true
Vault / ExcellentEconomy / PlayerPointsRealm currency rewards, entry cost, keystone reforge costCurrency-related features are silently skipped
CitizensThe mechanism NPC action spawning an NPCThe NPC action has no effect

For choosing an economy backend, see realm.reward.currency-provider in Configuration File; leave it blank = auto-detect.

Storage backend ​

QR uses YAML by default (zero-config, works out of the box for a single server). In config.yml:

yaml
storage:
  type: yaml      # yaml | database
  • yaml — anchors, chest claims, slot machine, codex, etc. are all stored in local YAML files. Enough for a single / standalone server.
  • database — reuses QinhCoreLib's database (whether SQLite or MySQL is configured in QCL's config.yml; QR doesn't configure a database separately).

On a network (BungeeCord / Velocity), if you want player codex discoveries shared across servers → configure QinhCoreLib to point at the same MySQL, and the backends share it naturally.

Note: only the codex (per player) goes into the database; data tied to specific world coordinates — anchors / chest claims / slot machine, etc. — still stays in each server's local YAML (as it should be, locally). See Data Storage.

Upgrades and config migration ​

QR has a built-in config migrator: the top of config.yml carries a config-version baseline — do not edit it manually. When the config structure is upgraded in the future, the migrator automatically fills in new fields and preserves your old values on startup — old servers can just swap the jar without resetting their config.

Next step ​