常见问题

/lysz open 无法打开衣橱

按以下顺序检查：

1. 必须由玩家在游戏内执行 /lysz open，控制台不能打开玩家界面。
2. 确认插件已经完成授权与初始化。初始化完成前，玩家会被阻止进入服务器。
3. 确认 DragonCore 已安装并成功启用。DragonCore 未启动时，插件不会注册衣橱界面的数据包监听。
4. 确认 时装衣橱.yml 已放入 plugins/DragonCore/Gui/。
5. 确认界面名称仍为 时装衣橱。插件会按此名称打开界面并调用界面方法。
6. 检查控制台是否出现“玩家数据不存在”。玩家数据尚未载入时，插件会拒绝打开衣橱。
7. 如果刚执行过重载，关闭界面后重新进入，或重新登录再测试。

衣橱可以打开，但内容没有初始化

衣橱打开后，需要由 DragonCore 界面向服务端发送标识为 LyArmourersWardrobe 的初始化数据包。初始化过程会创建玩家筛选缓存，并刷新以下内容：

• 当前页时装列表。
• 当前穿戴槽位。
• 五个时装预设按钮。
• 类型、品质和拥有状态筛选按钮。
• 当前预设中已经穿戴的时装。

如果界面只有背景，没有时装、筛选按钮或穿戴槽位，通常是界面文件与当前插件的数据包方法不匹配。请使用与插件配套的 时装衣橱.yml，不要混用旧版界面文件。

界面打开后没有贴图

检查客户端资源是否完整，并确认界面配置引用的路径与实际目录一致。原有资源通常位于 GUI/时装衣橱贴图/ 路径下。

还需要区分以下两种显示内容：

现象	检查项
界面背景、按钮贴图缺失	检查客户端的衣橱贴图资源与 DragonCore 界面路径
时装列表显示书本图标	show-item-armourers 默认为 false，这是正常行为
开启时装物品显示后仍无模型	检查 DragonArmourers 中是否存在对应时装 ID

设置 show-item-armourers: true 后，插件会尝试把时装皮肤附加到列表物品上。修改该配置后应执行 /lysz reload，再重新打开衣橱。

衣橱内没有任何时装

插件会递归读取以下目录中的所有 .yml 文件：

plugins/LyArmourersWardrobe/armourers/

每个顶层配置键就是 DragonArmourers 时装 ID。请检查：

1. armourers 目录中存在 .yml 时装文件。
2. 时装 ID 与 DragonArmourers 内的真实 ID 完全一致。
3. 不同文件中的顶层时装 ID没有重复。
4. DragonArmourers 能够返回该时装的类型。
5. 返回的类型属于插件支持的类型。
6. 控制台没有出现“时装注册失败”或“未找到对应时装类型”。

插件支持的时装类型如下：

类型 ID	默认显示名
sword	武器
bow	弓箭
outfit	套装
wings	翅膀
head	帽子
chest	上衣
legs	裤子
feet	鞋子

时装类型由 DragonArmourers 自动识别，不需要在时装文件中手动填写。

控制台提示“时装注册失败”

常见原因如下：

• 顶层配置键不是有效的 DragonArmourers 时装 ID。
• DragonArmourers 中不存在该时装。
• DragonArmourers 无法识别时装类型。
• 时装类型不属于插件支持的八种类型。
• 时装 YAML 格式错误。
• DragonArmourers 没有正常启动。

插件加载时会逐个注册时装。注册失败的时装不会进入衣橱列表，也不能通过 /lysz give 给予玩家。

时装品质显示错误或变成普通品质

时装文件中的 quality 是 config.yml 内 quality 节点的数字键。例如：

quality:
  0: '&f普通'
  1: '&a优秀'
  2: '&b精良'

示例时装ID:
  quality: 1

如果时装填写的品质等级没有在 quality 中定义，插件会将该时装回退到 0 级品质。

配置品质时还需要注意：

• 至少保留一个 0 级品质。
• 品质等级应从小到大连续设置，不要跳级。
• 修改后执行 /lysz reload，让品质与时装数据重新载入。

筛选按钮的文字不正确

类型、品质与拥有状态按钮分别由以下配置控制：

配置项	可用占位内容
filter-button-text.type	{type}
filter-button-text.quality	{quality}
filter-button-text.owner	{status}

类型名称来自 display-type，品质名称来自 quality。修改品质、类型显示名或按钮格式后，需要执行 /lysz reload 并重新打开衣橱。

all 只用于筛选，界面中固定显示为“全部”，不是可注册的时装部位。

搜索不到中文时装名称

搜索功能会将玩家输入和时装的 name 转换为拼音后进行包含匹配。请检查：

• 搜索目标写在时装配置的 name 中，而不是只写在时装 ID 中。
• 时装已经成功注册并出现在未筛选的列表中。
• 当前品质、类型和拥有状态筛选没有排除该时装。
• 修改时装名称后已经执行 /lysz reload。

搜索只匹配时装显示名称的拼音，不会搜索 Lore、属性内容或时装 ID。

下一页按钮没有反应

插件根据筛选后的时装数量和 file-armourers-amount 判断是否存在下一页。当前页已经包含全部结果时，点击下一页不会发生变化。

请检查：

1. 当前筛选结果是否超过单页数量。
2. file-armourers-amount 是否与 DragonCore GUI 每页实际创建的槽位数量一致。
3. 搜索、品质、类型或拥有状态筛选是否缩小了结果范围。
4. 是否使用了与当前插件匹配的 GUI 文件。

默认每页数量为 24。

点击按钮偶尔没有反应

插件通过 packet-interval 限制同一玩家向衣橱发送数据包的频率，避免连点器造成服务器压力。默认值为 300 毫秒。

如果玩家连续快速点击，间隔内的数据包会被直接忽略。这会影响穿戴、脱下、翻页、筛选、搜索、切换预设和隐藏状态等界面操作。

不建议把间隔设置得过低。配置文件建议使用 200 至 300 毫秒。

穿戴后没有显示时装

优先检查以下内容：

1. DragonArmourers 已安装并成功启用。
2. 时装 ID 与 DragonArmourers 中的真实 ID一致。
3. 时装已经在 armourers 配置目录中注册。
4. 玩家拥有该时装，或当前正处于有效试穿时间内。
5. 当前预设没有隐藏该时装部位。
6. 当前部位记录的时装没有被移除或过期。
7. DragonCore 配置中的 DragonAmourers 是否与本插件的穿戴逻辑冲突。

如果出现频繁穿戴不生效或不显示，可尝试将 DragonCore 配置中的 DragonAmourers 设置为 false。DragonCore 自带的龙核槽位时装与本插件穿戴逻辑完全冲突，应根据服务器方案选择其中一种。

需要进一步定位时，可以临时设置：

debug-skin-update: true

开启后，控制台会输出玩家当前预设、穿戴映射、隐藏映射、拥有状态、原始皮肤列表以及时装被加入或过滤的原因。排查完成后建议关闭，避免产生大量日志。

穿戴时提示“未在配置内注册的时装ID”

这表示界面或玩家预设引用了一个 DragonArmourers 中可能存在、但没有成功载入 LyArmourersWardrobe 时装配置的 ID。

请确认该 ID 已作为顶层键写入 plugins/LyArmourersWardrobe/armourers/ 下的某个 .yml 文件，并执行 /lysz reload。

如果该时装已从配置中删除，玩家旧预设中的记录不会继续正常穿戴。应重新选择有效时装，或由管理员检查玩家数据。

隐藏时装后仍然显示

隐藏状态按“当前预设”和“时装部位”分别保存。请检查：

• 隐藏的是当前正在查看的预设。
• 隐藏的部位与实际穿戴时装类型一致。
• DragonArmourers 的皮肤刷新事件正常触发。
• 界面发送的隐藏状态没有被过短的 packet-interval 拦截。
• 没有其它插件在皮肤刷新后重新附加同一时装。

本插件会保留事件中原本存在的其它皮肤，只过滤自己当前预设中被隐藏的时装。因此，如果同一个时装由其它系统同时添加，隐藏本插件槽位不一定能移除其它系统提供的皮肤。

切换预设后时装没有变化

插件固定创建五个预设，索引为 0 至 4。每个预设分别保存：

• 各部位穿戴的时装 ID。
• 各部位的隐藏状态。

切换预设时，只有新旧预设的穿戴映射或隐藏映射不同，插件才会刷新玩家皮肤。如果两个预设内容完全相同，外观不会变化。

还应确认目标预设中的时装仍然存在、已经注册，并且玩家永久拥有该时装。

重启后试穿时装消失了

这是正常行为。插件只会把永久时装写入本地 YAML 或 MySQL：

• 永久时装使用 -1 作为内部拥有期限，并会持久保存。
• 试穿时装使用到期时间，只在当前运行期间临时保存于玩家数据中。
• 保存预设时，只会保存玩家永久拥有的已穿戴时装。

因此，重启、重新登录或重新载入玩家数据后，不会恢复历史试穿时装，也不会恢复试穿时装提供的穿戴状态。

试穿结束后没有恢复原来的时装

试穿会把对应部位的当前穿戴记录替换为试穿时装。试穿到期后，插件会移除该临时时装，并清除所有预设中对它的引用，不会自动恢复试穿前该部位穿戴的旧时装。

玩家需要重新打开衣橱并手动穿戴原来的时装。

如果试穿一直没有到期，请检查：

• try-on-time 是否为合理的秒数。
• 服务器主线程是否长期卡顿。
• 控制台是否出现任务异常。
• 玩家数据是否仍存在于插件内存中。

试穿结束后仍然显示时装

插件每秒检查一次临时时装是否到期。到期后会：

1. 从玩家拥有列表中移除临时时装。
2. 清除所有预设中对该时装的穿戴记录。
3. 清理对应的 DragonCore 槽位物品。
4. 刷新当前预设皮肤和属性。
5. 发送 message.try-on-expired 消息。

如果外观仍然存在，优先开启 debug-skin-update 检查最终皮肤列表。还需要确认该皮肤是否由 DragonCore 槽位、其它时装插件或其它 DragonArmourers 逻辑重复添加。

试穿提示仍需等待，但时间已经过去

试穿冷却时间保存在 next-try-on-time 中。玩家每次开始试穿时，会立即写入下一次可试穿时间。

需要注意：

• next-try-on-cooldown 是两次试穿之间的冷却，不是试穿持续时间。
• try-on-time 是本次临时时装的有效时间。
• 冷却时间可以长于试穿时间。
• 显示的剩余秒数采用整数计算，接近结束时可能显示 0 秒，但仍需等待不足一秒的剩余时间。
• 修改配置不会自动重算已经记录的冷却时间。

如果需要验证新配置，应等待旧冷却结束后再次测试。

试穿时没有获得收集属性

这是正常机制。试穿时装不会提供收集属性，也不会提供穿戴属性。

插件刷新属性时只统计：

• 玩家永久拥有时装的 attribute。
• 当前预设中已经穿戴，并且永久拥有的时装的 equip-attribute。

临时试穿记录不会加入属性缓存。

永久时装的属性没有生效

按以下顺序检查：

1. attribute-plugin 是否填写了服务器实际安装的属性插件名称。
2. 修改 attribute-plugin 后是否重启服务器。默认配置明确要求重启后生效。
3. 对应属性插件是否成功启用。
4. 时装是否为永久拥有，而不是临时试穿。
5. attribute 与 equip-attribute 的文本格式是否符合目标属性插件要求。
6. 时装配置是否已经重新载入。
7. 玩家是否重新登录，或关闭过背包以触发属性缓存刷新。

可填写的值如下：

配置值	对应属性系统
AttributePlus	AttributePlus
SX-Attribute2	SX-Attribute 2 对应接口
SX-Attribute3	SX-Attribute 3 对应接口
AttributeSystem	AttributeSystem
ItemLoreOrigin	ItemLoreOrigin
空字符串	不接入属性插件

当服务器安装 SX-Attribute，但 attribute-plugin 没有选择 SX-Attribute2 或 SX-Attribute3 时，控制台会提示未选择 SX 版本。

收集属性生效，但穿戴属性不生效

attribute 与 equip-attribute 的触发条件不同：

字段	生效条件
attribute	玩家永久拥有该时装
equip-attribute	玩家永久拥有该时装，并在当前预设中穿戴

请确认该时装不是试穿状态，并确认当前预设的对应部位确实记录了该时装。

隐藏时装只控制外观显示，不会从当前预设的穿戴映射中移除时装。因此，永久时装被隐藏后，仍可能保留穿戴属性。

时装 Lore 中没有展开属性列表

只有当 Lore 中的一整行完全等于以下标记时，插件才会展开属性列表：

标记	展开内容
{collect_attribute}	当前时装的 attribute 列表
{equip_attribute}	当前时装的 equip-attribute 列表

正确示例：

示例时装ID:
  lore:
    - '&7收集后获得属性:'
    - '{collect_attribute}'
    - ''
    - '&7穿戴时获得属性:'
    - '{equip_attribute}'

不要把标记与其它文字写在同一行，否则插件不会替换。

/lysz give 提示玩家不在线

/lysz give 和 /lysz remove 只处理在线且玩家数据已经载入的玩家。请确认：

• 玩家当前在线。
• 玩家名称大小写与实际名称一致。
• 插件已经完成初始化。
• 玩家没有处于数据库加载失败或数据尚未建立的状态。

这两个命令不支持直接修改离线玩家数据。

/lysz give 提示时装 ID 不存在

管理员命令只能操作已经载入 ArmourersData 的时装。请检查：

1. 时装 ID 是否完整且大小写一致。
2. 时装是否已写入 armourers 目录中的 .yml 文件。
3. 时装是否在重载时注册成功。
4. DragonArmourers 是否能识别该时装及其类型。

管理员可以使用命令补全查看当前已注册的时装 ID。

普通玩家看不到管理命令帮助

这是正常权限逻辑。项目没有定义独立权限节点，管理操作直接检查发送者是否为服务器管理员。

操作	使用条件
/lysz open	玩家执行，不要求管理员身份
/lysz reload	必须为服务器管理员
/lysz give [玩家] [时装ID]	必须为服务器管理员
/lysz remove [玩家] [时装ID]	必须为服务器管理员
管理命令补全	仅服务器管理员可见

插件未加载完整核心逻辑前，帮助中可能只显示 /lysz reload，并提示更多指令将在验证通过后显示。

执行 /lysz reload 后部分设置没有变化

重载会重新读取配置、品质、类型和时装文件，并重启自动保存任务，但不是所有设置都支持热重载。

以下配置应通过重启服务器应用：

• mysql.enable
• MySQL 连接信息。
• attribute-plugin
• 依赖插件的启用状态与监听器注册状态。

重载后已经打开的 DragonCore 界面也可能保留旧组件。建议关闭并重新打开衣橱。

自动赠送的时装没有穿上

auto-give-armourers 会在玩家数据加载时给予永久时装。如果当前预设对应部位没有穿戴时装，插件还会自动把赠送时装放入该部位。

不会自动穿戴的常见原因：

• 玩家已经拥有该时装，因此本次加载会直接跳过。
• 当前预设的同一部位已经穿戴其它时装。
• 时装 ID 无效或 DragonArmourers 无法识别类型。
• 时装类型不在支持范围内。
• 修改列表后只执行了重载，但玩家数据没有重新加载。

修改 auto-give-armourers 后，玩家需要重新登录才能触发数据加载逻辑。

数据保存后又出现已经脱下的旧时装

当前本地保存逻辑会重新构建完整 YAML，而不是在旧文件上增量修改，正常情况下已经脱下的时装键不会残留。

如果仍出现旧记录，请检查：

• 是否有多个服务端实例同时写入同一数据目录。
• 是否手动恢复了旧数据文件或 .bak 备份。
• 是否在 MySQL 与本地 YAML 之间切换了存储方式。
• 玩家退出或服务器关闭时是否出现保存失败日志。

本地数据文件位于：

plugins/LyArmourersWardrobe/data/玩家UUID.yml

玩家数据文件损坏后会怎样处理

本地 YAML 模式使用临时文件、备份文件和替换流程保存玩家数据：

• 保存前先写入唯一的 .tmp 临时文件。
• 旧主文件会切换为同名 .bak 备份。
• 新临时文件再替换为主文件。
• 读取主文件失败时，会尝试读取 .bak 并恢复主文件。
• 主文件和备份都损坏时，会删除损坏文件并使用空数据继续加载。
• 文件中包含 NUL 字符时，会被判定为损坏。

如果控制台提示已经从备份恢复，建议先停止服务器，再备份整个 data 目录并检查磁盘、异常关机或并发写入问题。

数据库切换后玩家时装消失了

本地 YAML 与 MySQL 是两套独立存储，插件不会自动迁移数据。

• 本地模式读取 plugins/LyArmourersWardrobe/data/。
• MySQL 模式读取数据库中名为 LyArmourersWardrobe 的表。
• 切换存储方式后，玩家看到的是目标存储中已有的数据。

正式切换前必须备份原数据，并自行完成数据迁移。修改 mysql.enable 后需要重启服务器，不能只执行 /lysz reload。

开启 MySQL 后玩家无法进入服务器

MySQL 存储模式必须安装 LyMySQLCore，并确保 LyMySQLCore 与数据库都已成功初始化。只有 LyMySQLCore 正常触发安全加载、保存事件后，玩家数据读写功能才会生效。

插件自身的数据库连接没有完成时，会阻止玩家进入服务器：

• 普通玩家看到“服务器尚未初始化完毕”。
• 管理员的提示会额外说明 LyArmourersWardrobe 数据库未连接完毕。

请检查：

1. LyMySQLCore 是否已经安装并正常加载。
2. mysql.enable 是否为 true。
3. mysql.ip、mysql.port、mysql.databasename、mysql.username 和 mysql.password 是否正确。
4. 数据库服务是否允许服务端所在主机连接。
5. 数据库用户是否具有建表、查询、插入和更新权限。
6. 控制台是否显示数据库连接成功和数据表初始化成功。
7. 修改数据库配置后是否完整重启服务器。

数据库未连接时，不要尝试放行玩家，否则玩家数据加载与保存功能无法正常工作。

MySQL 模式没有自动保存

MySQL 模式会按 auto-save-interval 的秒数检查在线玩家，只保存已经被标记为发生变化的数据。该配置在默认文件中可能没有显式出现，代码默认值为 3 秒。

自动保存还要求：

• mysql.enable 为 true。
• 数据库连接池处于可用状态。
• 玩家数据已经成功加载。
• 玩家数据发生过需要保存的变化。

玩家退出、被踢出或插件关闭时，也会触发保存流程。若控制台出现保存失败日志，请先处理数据库连接问题。

本地 YAML 模式会自动定时保存吗

现有定时自动保存任务只在 MySQL 已启用且连接正常时执行。本地 YAML 模式主要在玩家退出、被踢出或插件关闭时保存。

因此，不建议强制结束服务端进程。应使用正常的服务器关闭流程，确保在线玩家数据完成保存。

时装数量变量不正确

先确认使用的是正确变量，并区分永久拥有与临时试穿：

• %law_owned_all% 和 %law_owned_类型% 只统计永久拥有的时装。
• 临时试穿不会计入拥有数量。
• %law_total_all% 与 %law_total_类型% 只统计已经成功注册的时装。
• 注册失败或重复 ID 不会按预期增加总数。

支持的类型为 sword、bow、outfit、wings、head、chest、legs、feet。修改时装文件后执行 /lysz reload。

%law_total_类型% 始终返回 0

项目当前实现中，total_ 变量解析类型时使用了错误的截取长度。这可能导致 %law_total_all% 和 %law_total_类型% 无法按设计返回总数。

这是插件实现问题，不是 PlaceholderAPI 配置问题。其它变量正常时，无需重复安装 PlaceholderAPI。应等待插件版本修复该变量解析逻辑。

PlaceholderAPI 变量返回空字符串

变量返回空字符串通常表示：

• 请求变量时没有对应玩家上下文。
• 玩家数据尚未载入。
• 类型 ID 无效。
• 当前预设对应部位没有穿戴时装。
• 当前穿戴的时装 ID 已不在插件注册数据中。

确认 PlaceholderAPI 已安装并在插件初始化时显示“PlaceholderAPI 已启动”。插件会自动注册标识符 law，不需要单独下载扩展。

PlaceholderAPI 变量返回红色“错误”

当变量标识符属于 law，但后半部分不匹配插件支持的变量格式时，会返回红色“错误”。请检查变量名称、下划线位置、时装 ID 和类型 ID。

变量中的类型必须使用英文 ID，不能填写 武器、套装 等显示名称。

玩家获得时装后没有立即保存

玩家获得、移除时装或修改穿戴数据后，数据会被标记为需要保存。

• MySQL 模式会由自动保存任务处理，并在退出、被踢或插件关闭时再次保存。
• 本地 YAML 模式主要在退出、被踢或插件关闭时保存。

如果服务器直接崩溃或被强制终止，最后一次正常保存之后的本地数据变化可能丢失。

玩家移除时装后其它预设也被清空了

移除永久时装时，插件会遍历全部五个预设，并从所有预设中删除该时装，避免玩家继续穿戴已经不再拥有的内容。

同时会刷新当前预设皮肤、DragonCore 槽位、搭配详情和属性缓存。这是正常行为。

修改时装 ID 后玩家原有数据失效

时装 ID同时用于以下内容：

• DragonArmourers 时装标识。
• 时装配置顶层键。
• 玩家永久拥有列表。
• 五个预设中的穿戴记录。
• 管理命令参数。
• %law_status_时装id% 变量。

插件没有提供自动重命名或迁移机制。修改 ID 后，旧玩家数据仍保存旧 ID，插件会把它视为未注册时装。正式修改前应备份并迁移本地 YAML 或 MySQL 中的玩家数据。

重载后控制台出现大量时装注册日志

这是正常行为。执行 /lysz reload 时会重新读取品质、类型和全部时装文件，并为每个成功注册的时装输出 ID、品质和类型。

如果日志中出现“时装注册失败”，需要根据对应 ID检查 DragonArmourers 数据和时装 YAML，而不是忽略该提示。

插件启动后玩家提示“服务器未加载完成”

插件在完成授权和核心初始化前会阻止玩家进入。核心逻辑会延迟加载配置与依赖监听器，因此刚启动服务器时短暂出现该提示属于保护机制。

如果提示持续存在，请检查：

• 插件授权是否成功。
• 控制台是否出现授权失败信息。
• 核心模块是否成功加载。
• DragonCore 与 DragonArmourers 是否正常启用。
• 开启 MySQL 时，LyMySQLCore 和数据库连接是否正常。
• 控制台是否存在插件初始化异常。

不要在插件尚未初始化完成时反复热重载依赖插件。优先完整重启服务器并观察首次启动日志。