Skip to content

常见问题 ​

为什么装备无法强化? ​

依次检查以下内容:

  1. 装备必须拥有显示名称和 lore。
  2. 装备名称必须匹配某个强化方案的 适用物品。
  3. 装备数量必须为 1,堆叠装备不会执行强化。
  4. 装备 lore 不能包含 禁止强化功能Lore关键词 中配置的任意关键词。
  5. 当前等级必须存在对应的强化配置,并且没有达到 强化上限。
  6. 如果下一级配置了 强化权限,玩家必须拥有对应权限。

适用物品 默认按名称包含关系匹配,也可以使用指定的匹配前缀:

写法匹配方式
物品名模糊匹配,装备名称包含该内容即可
contain@物品名关键词匹配
equals@物品名完整名称匹配

如果多个强化方案使用了容易重叠的名称关键词,应调整 适用物品,避免装备被错误归类。

为什么界面可以打开,但点击强化没有反应? ​

插件只允许在强化界面的指定槽位放置装备和强化石,并会拦截不受支持的点击或拖拽操作。

还需要确认:

  • 装备槽中的物品数量为 1。
  • 装备能够匹配强化方案。
  • 装备没有包含禁止强化关键词。
  • 当前等级未达到强化上限。
  • 下一级配置存在且玩家拥有所需权限。
  • 材料、金币、强化石和保护符均通过检查。

关闭界面时,插件会尝试把已放入的物品退回玩家背包。背包已满时,物品会掉落在玩家脚下。

为什么提示材料不足? ​

检查当前等级的 材料需求。基础格式为:

yaml
材料需求:
  - "物品名称#数量"

材料数量支持 {level}、PlaceholderAPI 变量和四则运算。例如:

yaml
材料需求:
  - "测试物品#{level}*2"

材料还可以增加第三段条件:

yaml
材料需求:
  - "测试物品#2#{level} >= 10"

只有条件成立时,该项材料才会参与检查和扣除。条件支持数值比较、字符串相等比较,以及 &&、|| 逻辑组合。

同时检查以下问题:

  • 物品名称或物品库 ID 是否正确。
  • 玩家背包中的物品是否与插件取得的目标物品一致。
  • 材料数量公式经过计算后是否超出预期。
  • 放入的强化石是否设置了 need-item-rate,该倍率会影响本次所需材料数量。
  • 对应物品库支持是否已经正确启用。

为什么金币不足,或者实际扣除金币与配置不同? ​

当前等级的 消耗金币 支持 {level}、PlaceholderAPI 变量和四则运算。

如果放入强化石,最终金币消耗还会乘以强化石的 need-eco-rate:

yaml
强化石:
  强化石1:
    need-eco-rate: 1.0

金币功能需要可用的经济服务。项目将 Vault 声明为软依赖;如果服务器没有提供可用的经济环境,金币余额检查和扣除无法正常工作。

为什么强化石无法使用? ​

检查 强化道具.yml 中的强化石配置:

配置项检查内容
强化石节点名称必须能够识别放入界面的物品名称
chance强化石提供的成功率数值
type只能按配置使用 + 或 * 计算方式
lv当前装备等级必须处于允许范围内,-1 表示不限制
need-item-rate会改变本次材料数量
need-eco-rate会改变本次金币消耗

lv 可以填写单个等级、等级范围或 -1。例如:

yaml
强化石:
  强化石1:
    chance: 20
    need-item-rate: 1.0
    need-eco-rate: 1.0
    type: '+'
    lv: '1-5'

如果强化石能够被识别,但当前装备等级不在允许范围内,插件会提示强化石等级不匹配。

强化石的 + 和 * 有什么区别? ​

强化石的成功率加成方式由 type 决定:

类型计算方式
+直接把强化石的 chance 加到基础成功率
*按基础成功率乘以 chance 的百分比计算额外成功率

最终判定还可能包含保底加成和福星加成。强化界面按钮 lore 可以显示基础成功率、强化石加成和保底加成。

为什么保护符没有显示? ​

保护符必须写在玩家当前准备强化等级的 保护符 列表中。例如,装备当前为 0 级,准备强化到 1 级时,插件读取的是 1 级配置中的 保护符。

yaml
保护符:
  - 测试物品
  - 测试物品2

界面最多展示当前等级配置中的前三种保护符。保护符物品还必须能够通过已配置的物品来源正常取得。

为什么保护符没有生效? ​

仅在配置中写入保护符名称并不会自动使用。玩家需要在强化界面中点击并选中保护符。

选中后,界面中的保护符会:

  • 增加附魔光效。
  • 追加 保护符使用lore 中配置的内容。

强化失败时,插件会再次检查玩家背包中是否有对应保护符。保护符存在时会扣除一个,并阻止本次失败产生掉级或装备破碎结果。

如果玩家关闭界面、取消选择,或者背包中没有对应保护符,保护不会生效。

为什么强化失败后没有掉级? ​

可能存在以下原因:

  • 玩家选中了有效保护符。
  • 强化失败 随机到了 0,表示等级不变。
  • 失败结果配置没有按预期加载。

失败结果由“结果”和“权重”组成:

yaml
强化失败:
  - '-1#50'
  - '0#45'
  - 'break#5'
结果含义
0强化等级不变
负数按数值降低强化等级
break装备破碎

失败降级结果不要填写正数。项目示例明确要求这里只使用 0、负数或 break。

为什么装备强化失败后消失了? ​

当前等级的 强化失败 可能随机到了 break。该结果会直接清空强化界面中的装备,并发送 msg.装备破碎 消息。

如果不希望某一级发生破碎,请检查并移除该等级失败结果中的 break 项,或者为该等级配置可用保护符。修改失败结果后,需要重载插件配置。

为什么强化失败后等级变成 0 级? ​

当失败降级后的结果小于或等于 0 时,插件会把强化等级处理为 0,并重置装备上的强化内容。

例如,当前为 1 级并随机到 -2,最终会回到 0 级,而不是出现负强化等级。

为什么强化成功率与填写的 概率 不一致? ​

最终成功率不一定只包含等级配置中的 概率,还可能受到以下内容影响:

  • 强化石成功率加成。
  • 保底成功率加成。
  • 福星变量加成。
  • 概率 中使用的 {level}、PlaceholderAPI 变量和公式。

基础概率、强化石加成和保底加成会参与最终随机判定。福星的具体计算方式还受全局 福星变量、福星乘法 和等级配置中的 福星 影响。

排查时应先临时使用固定数值,确认基础强化正常,再逐步恢复变量与公式。

为什么保底没有生效? ​

保底需要同时满足以下条件:

  1. config.yml 中 guaranteed-enable 为 true。
  2. 当前目标等级配置了大于 0 的 强化保底次数。
  3. 当前目标等级配置了 强化保底概率。
  4. 玩家对应强化方案的连续失败计数达到要求。
  5. 玩家保底数据已经成功加载。

配置示例:

yaml
强化保底次数: 5
强化保底概率: 10

失败后,插件会增加该玩家在当前强化方案下的保底计数;强化成功后,该方案的计数会重置为 0。达到次数后,强化保底概率 会作为额外成功率加入本次判定。

保底按强化方案分别记录,不是所有装备共用一个总计数。

保底数据保存在哪里? ​

未启用 MySQL 时,保底数据保存在:

text
plugins/LyStrengthen2/data/玩家UUID.yml

YAML 数据使用 guaranteed.强化方案ID 保存每个方案的失败次数。保存时会使用临时文件和 .bak 备份;主文件损坏时,插件会尝试从备份恢复。玩家数据文件按 UTF-8 读取和写入。

启用 MySQL 后,保底数据会保存到插件对应的数据表中。

启用 MySQL 后为什么保底数据没有加载? ​

MySQL 仅用于保底数据,并且只有启用保底功能时才有实际意义。

必须满足以下条件:

  • 安装 LyMySQLCore。
  • LyMySQLCore 已正常运行。
  • LyStrengthen2 已成功连接数据库。
  • mysql.enable 为 true。
  • guaranteed-enable 为 true。
  • 数据库地址、端口、库名、用户名和密码正确。
  • 修改数据库开关后已经重启服务器。

如果没有安装 LyMySQLCore,或者数据库连接没有成功,MySQL 保底数据相关功能不会生效。此时应查看控制台中的数据库连接、数据表初始化、玩家数据读取和保存提示。

为什么切换 MySQL 开关后没有立即生效? ​

config.yml 已明确说明数据库开关需要重启服务器。不要只执行重载命令来切换 YAML 与 MySQL 存储方式。

切换前应先备份现有数据。项目证据中没有提供 YAML 与 MySQL 保底数据自动迁移功能,不能认为切换存储方式后旧数据会自动同步。

为什么强化等级显示不对? ​

强化等级会写入装备显示名称中的隐藏标记,并通过强化 lore 标识识别对应内容。

不要在已经投入使用后随意修改以下配置:

配置项作用
强化标识符标记插件写入的强化 lore
强化名称生成显示在装备名称中的强化等级文本
强化识别字符定位强化 lore 的插入位置
强化插入方式决定强化内容插在定位行的上方还是下方

尤其不要随意修改 强化标识符 和 强化名称。旧装备仍保留原来的隐藏内容,修改后可能导致插件无法正确识别或清理旧强化信息。

为什么强化 lore 出现在错误位置? ​

插件先查找 强化识别字符 对应的完整 lore 行,再根据 强化插入方式 插入强化内容。

强化插入方式效果
next插入到识别行之后
其他值插入到识别行之前

如果装备中没有与 强化识别字符 完全相同的 lore,强化内容会添加到 lore 末尾。

单个强化等级还可以单独配置 强化识别字符,并覆盖 config.yml 中的全局定位字符。

为什么旧的强化 lore 没有被替换? ​

插件通过 强化标识符 识别并删除自己先前写入的强化 lore。如果该标识符被修改,旧 lore 可能无法被识别,随后继续追加新的强化内容。

请恢复投入使用时的 强化标识符。不要直接依靠修改标识符来改变显示效果。

删除LORE起始行定位 和 删除LORE结束行定位 为什么没有效果? ​

两个配置必须同时存在,并且装备 lore 中必须按正确顺序包含对应关键词。

插件会保留起始行和结束行,仅删除两者之间的内容。如果结束行位于起始行之前、任意定位行不存在,或者关键词不匹配,则不会执行删除。

该功能使用包含匹配,关键词过短可能误删其他 lore,应使用清晰且不重复的定位文本。

为什么 lore 取值变量读取不到? ​

lore-get-value 会按配置的固定 lore 格式提取数值。例如:

yaml
lore-get-value:
  '变量1':
    default-value: 1
    lore-formula: '&7强化个体值: <value>'

读取成功后,可在强化内容和 NBT 值中使用 {v.变量1}。

读取不到时会使用 default-value。常见原因包括:

  • 装备 lore 文本与 lore-formula 不一致。
  • 颜色代码或固定文本不同。
  • 数值所在位置没有对应 <value>。
  • 目标 lore 是会频繁变化或重复嵌套的内容。

该功能适合读取格式固定的 lore,不适合读取不断套娃变化的充能类 lore。

为什么公式没有正确计算? ​

强化内容、NBT、成功率、金币和材料数量可使用四则运算。强化内容与 NBT 中的公式默认使用 calculate-key-left 和 calculate-key-right 作为边界,例如:

yaml
强化内容:
  - '&e物理攻击: &b<{level}*10~%.0f>'

公式部分支持 +、-、*、/ 和括号。~ 后面是数值格式,例如 %.0f 表示不保留小数,%.1f 表示保留一位小数。

排查时检查:

  • 左右公式关键词是否被其他插件或文本占用。
  • 左右关键词是否成对出现。
  • {level} 和 PlaceholderAPI 变量替换后是否为有效数字。
  • 括号是否完整。
  • 表达式中是否包含不受支持的运算符。

为什么材料条件没有按预期判断? ​

材料的第三段内容会作为条件表达式处理,并先替换 {level} 和 PlaceholderAPI 变量。

支持的比较和逻辑运算包括:

类型运算符
数值比较>、>=、<、<=
相等判断==、!=
逻辑与&&
逻辑或`

字符串比较应使用单引号或双引号包住两侧内容。例如:

yaml
材料需求:
  - "测试物品#1#'%player_world%' == 'world'"

条件不成立时,该项材料不会被检查或扣除。

为什么设置 NBT 后没有变化? ​

NBT 仅在强化成功、强化券成功或转移应用目标强化等级时写入。配置示例:

yaml
设置NBT:
  '属性': '物理攻击+<{level}*10~%.0f>'

NBT 的值支持:

  • {level}。
  • {v.变量ID}。
  • PlaceholderAPI 变量。
  • 强化公式计算。

还需要确认当前服务器版本具有对应的 NMS/NBT 适配。项目包含 1.7.10、1.8.8、1.11.2、1.12.2、1.13.2、1.14.4、1.15.2、1.16.5、1.17.1、1.18.2、1.19.2、1.19.4、1.20.1、1.20.2 和 1.20.3 的适配模块。未列出的服务端内部版本不能根据现有证据确认可用。

为什么强化后装备被替换了? ​

检查目标等级是否配置了以下内容:

配置项效果
替换名称直接替换整个装备显示名称,不再按普通方式保存等级名称
替换物品直接取得指定物品并替换当前装备

替换物品 生效时,方法会直接返回新物品,不再继续处理原装备后续的 lore 和 NBT 写入流程。

项目示例注明替换物品支持 AzureFlow、SX-Item、NeigeItems、OriginAttribute,并默认使用 MythicMobs 物品库。实际使用前应确认对应物品库已经安装,并且相关支持开关与物品 ID 正确。

为什么强化券无法识别? ​

强化券按 强化道具.yml 中的节点名称识别。检查:

  • 放入的是强化券物品,而不是普通同名物品。
  • 强化券节点名称正确。
  • lv 和 chance 已配置。
  • type 限制允许当前装备所属强化方案。
  • 装备能够正常匹配强化方案。
  • 装备数量为 1。
  • 装备不包含禁止强化关键词。

如果 type 为空列表,强化券不限制强化方案;如果填写方案 ID,则只允许对应方案使用。

为什么强化券被消耗了,但没有升级? ​

强化券不是默认必定成功。插件会先扣除一张强化券,再根据强化券的 chance 进行随机判定。

判定失败时,装备等级不会提升,并发送强化券失败相关消息。需要必定成功时,只能依据实际概率配置调整 chance,项目证据中没有独立的“必成”配置项。

为什么强化券不能把装备升到目标等级? ​

强化券还会执行以下检查:

  • 强化券目标等级不能超过装备强化上限。
  • 装备当前等级必须低于强化券目标等级。
  • 装备当前等级必须低于强化上限。
  • 目标等级必须存在有效强化数据。
  • 玩家必须拥有目标等级配置的 强化权限。
  • 强化券的 type 必须允许当前强化方案。

强化券成功后会直接应用目标等级配置,不是逐级执行中间等级。

强化转移为什么失败? ​

转移需要同时满足以下条件:

  1. 左右两件装备都能匹配强化方案。
  2. 左右装备数量都为 1。
  3. 两件装备都不包含禁止强化关键词。
  4. 左侧装备强化等级高于右侧装备。
  5. 右侧装备强化上限不低于左侧装备当前等级。
  6. 左右装备分别属于可转移的强化组。
  7. 强化转移.yml 中存在 左组-右组 对应的转移规则。
  8. 玩家拥有足够的转移材料和金币。

转移方向固定为左侧装备向右侧装备继承。配置 f1-f2 只表示允许从 f1 转移到 f2,不能据此认为自动支持从 f2 转移到 f1。

为什么两件同组装备不能转移? ​

插件根据“来源组-目标组”拼接规则 ID。即使两件装备属于同一组,也必须存在对应的同组规则,例如 f1-f1。

如果只配置了 f1-f2,则只会识别从 f1 到 f2 的转移。

为什么转移后等级降低了? ​

转移规则中的 min 和 max 表示转移时随机扣除的等级范围。例如:

yaml
转移:
  f1-f2:
    min: 0
    max: 4

转移后的等级为左侧装备等级减去随机损耗值。结果低于 1 时,插件会按 1 级处理。

转移前应根据界面显示确认当前规则的金币消耗,并检查配置中的随机等级损耗范围。

为什么转移后左侧装备消失了? ​

转移时是否破碎装备 决定转移完成后如何处理左侧装备:

配置值结果
true左侧装备被清空
false左侧装备保留,但会清除强化等级和强化 lore

转移规则内的同名配置优先于全局配置。规则中没有单独填写时,才使用全局 转移时是否破碎装备。

为什么转移后右侧装备属性不正确? ​

转移不是直接复制左侧装备的 lore 或 NBT,而是根据右侧装备所属强化方案和最终转移等级,重新应用右侧方案对应等级的数据。

因此,转移后的属性取决于:

  • 右侧装备匹配的强化方案。
  • 随机损耗后的最终等级。
  • 右侧方案该等级的 强化内容。
  • 右侧方案该等级的 设置NBT。
  • 右侧装备自身可被 lore-get-value 读取的数值。

如果希望两套装备在相同等级得到相同属性,需要分别检查两个强化方案的等级配置。

为什么带有某段 lore 的装备无法强化或转移? ​

检查全局配置:

yaml
禁止强化功能Lore关键词:
  - '禁止强化'

只要装备 lore 中包含列表中的任意关键词,该装备就不能使用强化、强化券或强化转移等强化系统功能。

不需要限制时,可以将其配置为空列表:

yaml
禁止强化功能Lore关键词: []

为什么执行重载后数据库配置没有更新? ​

普通配置可以通过重载命令重新读取,但数据库开关的示例注释明确要求重启服务器。涉及 mysql.enable 的修改应完整重启服务器,不要只执行重载。

可确认的重载命令为:

text
/qh reload

/qh2 reload 也存在对应命令处理逻辑。两者的实际绑定和可见功能可能受插件验证状态影响。重载操作要求执行者为服务器管理员。

为什么输入命令后只看到重载提示? ​

项目中存在验证前后的不同命令处理逻辑。验证前的命令帮助只显示重载,并提示更多指令会在验证通过后显示。

验证通过后的命令处理包含:

命令用途
/qh reload重载插件
/qh open打开装备强化界面
/qh qhq打开强化券界面
/qh zy打开强化转移界面

无参数帮助和重载命令要求执行者为服务器管理员。三个界面命令只能由玩家执行。

如果只能看到重载提示,应先检查插件是否完成验证及核心是否正常加载,而不是自行添加不存在的权限节点。

为什么 PlaceholderAPI 变量或公式变量没有替换? ​

PlaceholderAPI 被声明为软依赖。公式、条件、福星变量、强化内容和 NBT 中使用 PlaceholderAPI 变量时,需要安装 PlaceholderAPI,并确保对应变量所属的扩展或插件能够正常返回值。

排查顺序:

  1. 确认 PlaceholderAPI 已加载。
  2. 确认对应变量在服务器中可以正常解析。
  3. 确认变量返回的是公式需要的数值或条件需要的文本。
  4. 确认变量写在插件支持处理的配置字段中。
  5. 检查变量替换后是否形成有效的四则运算或条件表达式。

为什么槽位强化等级变量返回不正确? ​

槽位变量格式为:

text
%lyqh_slot_level_插件#槽位%

不同槽位来源使用不同参数格式:

来源参数格式
DragonCoreDragonCore#槽位名
GermPluginGermPlugin#槽位名
APInventoryAPInventory#分页ID#槽位ID
LyInventoryLyInventory#背包ID#类型
LyInventoryReloadLyInventoryReload#背包ID#类型
YeeJewelryYeeJewelry#背包ID#槽位ID
PXRPGPXRPG#类型#背包ID#槽位
原版主手Origin#MainHand
原版副手Origin#OffHand
原版头盔Origin#Helmet
原版胸甲Origin#ChestPlate
原版槽位Minecraft#槽位ID

配置示例中还列出了 Origin#Legging 和 Origin#Boots。应按插件配置注释中的实际约定填写,不要自行翻译或修改英文参数。

变量错误时应确认对应背包插件已安装、槽位名称或 ID 正确,并且槽位中的物品能够被 LyStrengthen2 识别强化等级。

哪些 Minecraft 版本有明确的 NMS 适配? ​

项目包含以下版本的 NMS/NBT 模块:

  • 1.7.10
  • 1.8.8
  • 1.11.2
  • 1.12.2
  • 1.13.2
  • 1.14.4
  • 1.15.2
  • 1.16.5
  • 1.17.1
  • 1.18.2
  • 1.19.2
  • 1.19.4
  • 1.20.1
  • 1.20.2
  • 1.20.3

这些是项目文件中能够直接确认的适配目标。未列出的版本没有对应模块证据,不应直接视为支持。

1.17 及以上适配模块使用 Java 17 编译目标;项目主体使用 Java 8 编译目标。服务器实际使用的 Java 版本仍需满足对应 Minecraft 服务端要求。

MythicMobs、Vault、PlaceholderAPI 和 LyMySQLCore 都必须安装吗? ​

它们在 plugin.yml 中属于软依赖,不是所有功能都必须同时安装,但使用对应功能时需要可用:

依赖相关功能
MythicMobs默认物品库物品获取、材料和保护符等物品识别
Vault金币余额检查与扣除
PlaceholderAPI变量替换、动态公式、条件和槽位变量
LyMySQLCoreMySQL 玩家保底数据加载与保存事件

如果启用 MySQL 存储,必须安装 LyMySQLCore,并确保数据库成功连接,否则相关功能不会生效。

为什么物品库中的材料、保护符或替换物品无法取得? ​

检查对应物品库是否安装,以及相关开关是否正确:

yaml
neigeItems: false
originAttribute: false
SX-Item: false

neigeItems 的优先级高于 OriginAttribute。配置注释还说明 OriginAttribute 未检测到物品时会继续检测 MythicMobs。

项目示例中的替换物品还提到 AzureFlow。由于不同物品来源使用相同字符串入口,物品 ID 必须与实际物品库中的 ID 一致,并避免在多个物品库中使用容易冲突的 ID。

为什么修改消息、GUI 标题或按钮 lore 后没有变化? ​

确认修改的是实际运行目录中的 config.yml,然后执行管理员重载命令:

text
/qh reload

GUI 文本分为强化界面、强化券界面和强化转移界面三组。需要修改对应前缀的配置:

前缀对应界面
gui.open-装备强化界面
gui.qhq-强化券界面
gui.zy-强化转移界面

强化按钮中的失败结果说明需要在 gui.open-button-lore 中保留 {fail_result},具体文本来自 replace-content。

为什么强化按钮不显示失败结果? ​

gui.open-button-lore 中必须包含 {fail_result}。插件会使用 replace-content 下的文本生成当前等级可能出现的掉级、不变和破碎说明。

yaml
gui:
  open-button-lore:
    - '{fail_result}'

相关文本由以下配置控制:

  • replace-content.fail-result-head
  • replace-content.fail-result-take-level
  • replace-content.fail-result-no-change
  • replace-content.fail-result-break

如果删除 {fail_result},失败结果仍会参与实际判定,只是不再显示在按钮 lore 中。

为什么音效报错或没有播放? ​

sound 只提供两种配置值:

配置值使用的声音名称体系
1.7旧版声音名称
1.12新版方块声音名称

应根据服务端版本选择可用的声音配置。填写其他值时,现有逻辑不会播放强化音效。

配置改坏后应该先检查什么? ​

按以下顺序排查:

  1. 查看控制台是否存在 YAML 格式、公式、物品库或数据库异常。
  2. 检查 YAML 缩进,尤其是强化方案的等级节点、列表和映射。
  3. 确认等级范围使用类似 3-9 的键,并使用字符串无法引起歧义的写法。
  4. 确认材料项至少包含“物品名称”和“数量”两段。
  5. 确认失败结果只使用 0、负数或 break。
  6. 确认公式左右关键词成对出现。
  7. 确认修改后执行了重载;数据库开关则必须重启服务器。
  8. 使用固定概率、固定金币和单一材料进行最小化排查,再逐步恢复公式与变量。

不要通过修改已经投入使用的 强化标识符 和 强化名称 修复旧装备识别问题,这通常会让旧装备更难恢复。