管理员文档 · 安装与升级

新服务器安装

1. 先单独启动一次目标服务端核心，让 eula.txt、世界和 plugins/ 目录生成。确认 Java 运行环境满足该核心的要求。
2. 将 Dominion JAR 放入服务端 plugins/ 目录。目录中只保留一个 Dominion JAR。不要把源码工程或开发依赖放进 plugins/。
3. 启动服务器，等待插件第一次生成 plugins/Dominion/。首次启动时不要立刻覆盖生成文件，先保存一份原始配置作为对照。
4. 确认插件已完成启用。启动日志应包含数据库连接和启用成功信息：

[Dominion] Database connected successfully.
[Dominion] Plugin Enabled!

5. 停服后备份整个 plugins/Dominion/，再根据配置文件总览修改策略。
6. 启动后用普通玩家账号创建一块小型测试领地，分别验证访客、成员、权限组和环境 flag。不要只用 OP 账号判断权限。

生成的目录

插件首次启动时会生成以下目录结构：

plugins/Dominion/
├── config.yml
├── flags.yml
├── limitations/
│   └── default.yml
├── world-wide/
├── languages/
├── dominion.db                 # 使用 SQLite 时
└── logs/                       # 若发行版启用独立日志

数据库文件名和附属文件以服务器实际生成结果为准。不要用文本编辑器直接修改数据库。备份、迁移或修复时，优先使用插件提供的导出、导入和迁移命令。

升级顺序

升级前应先记录运行环境、数据库类型和配置改动。操作顺序如下：

1. 停服并完整备份 plugins/Dominion/ 与服务端日志；外部数据库另外做数据库级备份。
2. 阅读发行说明，确认数据库、配置 version、flag schema 和 NMS 设置的变化。
3. 替换插件 JAR，保留数据目录；不要在没有备份的情况下删除旧数据库。
4. 启动一次，检查配置迁移、数据库连接和 NMS 加载日志。
5. 先用只读方式检查原有领地，再用测试账号执行创建、边界调整、成员加入和 UI 打开。
6. 确认稳定后再开放玩家；若发生异常，停服保留日志，不要反复启动覆盖现场。

常见安装误区

• 把 api-version 声明当成完整功能验证。插件能加载不代表所有 UI 或事件都已验证。
• 直接复制旧的 config.yml 覆盖新文件，可能漏掉新键或带入旧 schema。更稳妥的做法是比较差异后迁移自己的改动。
• 修改配置后只重载了 cache，却期待数据库或语言文件改变；配置策略应使用 /dominion reload config，数据库操作则应按命令说明执行。
• 在 OP 账号下测试并得出“所有玩家都能使用”的结论。管理员绕过开启时，OP 的结果不能代表普通玩家。