写给服主
玉简对外开放的一切，都可以在游戏中从 Cultivation 的管理菜单（cultivation.admin）→ 配置数值标签页 → 玉简分节里编辑，也可以手工编辑玉简自己的配置文件。本页是这两种方式的确切参考。
配置键
| 键 | 默认值 | 作用 |
|---|---|---|
Technique-Preset-Cap | 6 | 本扩展把 Cultivation 的功法按键布局上限提高到多少套。被限制在引擎自身的上限 8 之内。 |
Profile-Cap | 5 | 本扩展把 Cultivation 的修炼存档上限提高到多少个。无论此处如何设置，Cultivation 自己绝不会兑现超过其自身上限 6 的部分。 |
Palettes-Require-Permission | false | 把选择配色置于 jadeslip.palette.<id> 之后。功勋外观在赢得核验之外，也一并计入此项。 |
Banners-Require-Permission | false | 把选择普通宗门旗号置于 jadeslip.banner.<id> 之后。两面功勋旗号另行把守 —— 见下文。 |
Meditation-Auras-Require-Permission | false | 把选择打坐气息置于 jadeslip.meditationAura.<id> 之后。 |
Titles-Enabled | true | 本扩展的十一个装饰性称号是否注册。 |
Brighter-Auras | true | 玉简的配色是否使用更浓密的境界气息组，而不是 Cultivation 自己的。 |
Slip-Sharing-Enabled | true | 铭刻玉简是否可用。关闭时：/jadeslip inscribe 拒绝执行，阅读玉简也不起任何作用；已持有的玉简会失效，而不是被销毁。 |
Inscribe-Cost-Spirit-Stones | 10 | 写下一枚铭刻玉简的花费，要么全额扣除、要么分文不取。0 合法，即免费。 |
Consume-On-Read | true | 阅读铭刻玉简是否将其耗去。关闭则玉简成为永久、可分享的副本 —— 无论哪种情形，玉简都绝不传授功法，所以允许这样做不损失什么。 |
Champion-Looks-Enabled | true | 胜者桂冠与星耀天命 —— 两套须赢得的配色、它们的旗号与称号 —— 是否提供。关闭则对所有人隐去两套外观的这三处；已在佩戴其中一套的玩家保留它。 |
House-Look-Enabled | true | 宗主是否可用 /jadeslip house 为整座大殿悬挂一种外观。 |
House-Look-Sets-Banner | true | 悬挂大殿外观时，在所选外观有相配旗号的情况下，是否一并升起该旗号。无论如何，撤下外观都绝不会降下旗号 —— 那是另一项宗门设置，宗主此后或许已另行精心挑选过。 |
文件里还有一个 Last-Verified-Millis 字段。它不是设置 —— 它是授权宽限期据以起算的时间戳，由模组自己写入。手工编辑它毫无益处：设在未来的时间戳，在被读取的那一刻就会被拉回当前时间，所以它没法用来换取无限的宽限期。
何时生效
这一点值得说得确切些，因为并非每个字段在保存之后的表现都相同。
即时生效，无须重启： Palettes-Require-Permission、Banners-Require-Permission、Meditation-Auras-Require-Permission，以及 0.3.0 的全部六个键 —— Slip-Sharing-Enabled、Inscribe-Cost-Spirit-Stones、Consume-On-Read、Champion-Looks-Enabled、House-Look-Enabled 与 House-Look-Sets-Banner。每一项都会在每次绘制选择器、应用某项选择或运行某条命令时重新检查，所以拨动其中一项，会在玩家下次打开相关菜单或键入相关命令时生效。
下次重启后生效： Technique-Preset-Cap、Profile-Cap、Titles-Enabled 与 Brighter-Auras。这四项都只在服务器启动期间玉简登记自身内容时读取一次，此后不再重新检查 —— 所以在管理菜单中改动其中一项，新值会被正确保存，但要等到服务器（也即玉简自己的 setup()）下一次重启才会真正生效。
三个权限开关管的都是选择，绝不是保留。已经佩戴着某套配色或某种打坐气息的玩家，或已悬着某面旗号的宗门，无论开关如何都继续保有它 —— 这与 Cultivation 对待自家外观的方式一致；已佩戴的称号同样在要求变化之后依然留存。若想让权限从一开始就生效，请在发放外观之前把开关打开。
权限节点
玉简所添加的大部分内容，都是通过 Cultivation 现有的菜单与命令来选择的，由上述权限核验把守，而不是命令权限。任何一种外观的节点永远是 jadeslip.<registry>.<id>，其中 <id> 是它的注册表键中冒号之后的那一部分：
| 模式 | 示例 |
|---|---|
jadeslip.palette.<id> | jadeslip.palette.frost、jadeslip.palette.starfall、jadeslip.palette.laurel、jadeslip.palette.destiny |
jadeslip.banner.<id> | jadeslip.banner.frost、jadeslip.banner.stormcaller（不含两面功勋旗号 —— 见气息、旗号与称号） |
jadeslip.meditationAura.<id> | jadeslip.meditationAura.stillwater |
这些节点都要等到与之对应的 -Require-Permission 开关打开之后才起作用；开关关闭时，对应的注册表根本没有任何权限核验。Cultivation 自己的节点是如何构成的，见权限。
命令
自 0.3.0 起，玉简有了一棵自己的命令树 /jadeslip，涵盖铭刻玉简与大殿外观 —— 见按键布局与存档与配色。
| 命令 | 谁可用 | 作用 |
|---|---|---|
/jadeslip | 任何人 | 列出你的功法按键布局名称，以及铭刻一份的花费。与 slips 相同。 |
/jadeslip slips | 任何人 | 同一份列表，写明全称。 |
/jadeslip inscribe <layout name> | 任何人 | 把你的一份布局写入一枚铭刻玉简。 |
/jadeslip house | 任一宗门成员 | 报告悬在你大殿之上的外观：哪一套配色、升起哪面旗号、由谁在何时设定，以及你所在世界中有多少在线成员无法佩戴该配色而停留在朴素外观上。与 show 相同。 |
/jadeslip house show | 任一宗门成员 | 同一份报告，写明全称。 |
/jadeslip house <palette> | 宗主 | 为大殿悬挂一种外观。可接受裸 id（如 laurel），或完整键 jadeSlip:laurel。 |
/jadeslip house clear | 宗主 | 撤下大殿外观。 |
house clear 会让旗号继续悬着。旗号是另一项宗门设置，自外观悬起之后宗主或许已另行精心挑选过，所以撤下外观绝不会降下它；命令会如此告知，而要更改旗号则靠宗门菜单。当 Cultivation 中的 Sects-Enabled 被关闭时，house show 与 house clear 依然可用，因为在开关拨下之前悬起的外观仍然在那些成员身上，而宗主必须始终有办法把它撤下。只有会添加新东西的 house <palette> 才需要宗门处于开启状态。这三种形式都由 House-Look-Enabled 关闭，该开关同时也会让外观不再被绘出。
只有宗门的宗主能悬挂或撤下外观；其他人会被告知这一点，不在任何宗门内的调用者亦然。宗主自己无权佩戴、或并未注册的配色，会被拒绝，并以一条消息点出他们所键入的内容。
没有哪个子命令需要权限节点；每一个都对任何玩家开放，访问由上文的配置开关（Slip-Sharing-Enabled、House-Look-Enabled）与宗主核验来控制，而不是靠权限组。
需要哪个 Cultivation 版本
这道下限由 manifest.json 自己的 Dependencies 条目强制执行，那是一个真正的 semver 范围，服务器在玉简的任何一行代码运行之前就会核验它 —— Cultivation 一旦落在范围之外，玉简便根本不会被加载，不抓取任何东西，也不会半途启动。当前构建（v0.4.0）要求 Cultivation 0.11.0 或更高版本，并针对 Hytale 0.7.2 服务器（Update 7）运行，并声明 ServerVersion: >=0.7.2 <0.8.0；它无法在 Update 6 服务器上运行。若不确定，请把你所运行的 jar 与你的 Cultivation 版本核对一下；两者各自独立编号、独立发布。
授权与兼容性自检
玉简通过订阅发行，并会向 xianxia.dev 核验自身，免得一份在订阅之外持续流转的副本永远保持可用。这一核验在启动之后延迟运行，读取的是 Cultivation 自己构建核验的结论，而不是自己另发一次请求。
它依次核验什么：
- 这个构建是否落后太多？若已发布的版本比正在运行的版本领先三个以上的次版本，玉简便立即收回，不论它是否还能以别的方式完成核验 —— 数月无人更新的构建，正是这道核验要抓住的情形。
- 构建核验是否判定为正版？一份确认无误、未经改动的构建会重置宽限计时。若玉简在本次运行中早先已经收回，也是这一步将其恢复 —— 控制台会如此说明。
- 还是判定为非正版？代码与所发布版本不符的构建会立即收回，控制台会明白说出这一原因。
- 否则（未知 —— 核验没能连上 xianxia.dev，或尚未得到回应）：进入宽限期。从未核验过的构建，自这种情况首次发生起开始一段 30 天的计时，而不是把防火墙后的全新安装一上来就视作已逾期。只剩 7 天时，控制台会警告一次；30 天用尽仍无一次成功核验，便收回。
兼容性核验是另一项，与之并行运行：玉简读取的是 Cultivation 自己也会查阅的那份已公布的兼容清单，它可以点名某个在二者都已发布之后才被发现会破坏此构建的 Cultivation 版本 —— 这是在发布时就写死在 jar 里的 manifest 凭自身做不到的。若该清单将这一对确切的玉简／Cultivation 组合标为不兼容，玉简便收回，并明确说出是哪几个版本、哪个要求范围触发了它。
收回究竟做了什么：它交还配色、宗门旗号、装饰性称号、打坐气息、典籍文章、大殿外观，以及被提高的两项上限 —— 即插件卸载所能收走的一切。铭刻玉简是唯一有意为之的例外，仍然照常可用：它们是玩家付过真实灵石花费、也可能已转手交易的寻常物品，而无论授权状态如何，玉简都绝无可能授予功法，所以这道关卡去动它们，并没有什么要保护的。其他一概不删，修炼进度也分毫不动：已保存的配色或旗号选择会保留，在收回期间只是回落到 Cultivation 自己的默认样貌；而一旦构建通过核验、或版本得到纠正，一切即刻自动恢复 —— 收回逻辑本身无须重启。收回每次运行只发生一次；已经收回的构建不会重复这一动作或它的控制台消息。
它在每个方向上都是失效即放行，唯独沉默除外。无法连上的 xianxia.dev、格式错误的兼容清单，或是无人发布过条目的版本，都会让玉简原封不动地继续运行 —— 离线的服务器绝不会因为一次失败的请求，就被夺走它所付费换来的东西。唯一的例外是 30 天宽限期本身：一台确实没有任何对外连接的服务器，终将按期被收回，此前有一周的控制台警告，因为否则，把该域名整个屏蔽，与一次真正的核验失败将无从区分。
这一切都防不了篡改，也并不打算如此 —— 任何肯去改动 jar 的人都能把这些核验整个移除，就像他们同样能删掉 Cultivation 自己的构建核验一样。它所拦住的，是一份未经改动的副本在被转手流传到它所附带的订阅之外后，仍旧永远可用。