常见问题
为什么装备无法强化?
依次检查以下内容:
- 装备必须拥有显示名称和 lore。
- 装备名称必须匹配某个强化方案的
适用物品。 - 装备数量必须为 1,堆叠装备不会执行强化。
- 装备 lore 不能包含
禁止强化功能Lore关键词中配置的任意关键词。 - 当前等级必须存在对应的强化配置,并且没有达到
强化上限。 - 如果下一级配置了
强化权限,玩家必须拥有对应权限。
适用物品 默认按名称包含关系匹配,也可以使用指定的匹配前缀:
| 写法 | 匹配方式 |
|---|---|
物品名 | 模糊匹配,装备名称包含该内容即可 |
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 变量和公式。
基础概率、强化石加成和保底加成会参与最终随机判定。福星的具体计算方式还受全局 福星变量、福星乘法 和等级配置中的 福星 影响。
排查时应先临时使用固定数值,确认基础强化正常,再逐步恢复变量与公式。
为什么保底没有生效?
保底需要同时满足以下条件:
config.yml中guaranteed-enable为true。- 当前目标等级配置了大于 0 的
强化保底次数。 - 当前目标等级配置了
强化保底概率。 - 玩家对应强化方案的连续失败计数达到要求。
- 玩家保底数据已经成功加载。
配置示例:
yaml
强化保底次数: 5
强化保底概率: 10失败后,插件会增加该玩家在当前强化方案下的保底计数;强化成功后,该方案的计数会重置为 0。达到次数后,强化保底概率 会作为额外成功率加入本次判定。
保底按强化方案分别记录,不是所有装备共用一个总计数。
保底数据保存在哪里?
未启用 MySQL 时,保底数据保存在:
text
plugins/LyStrengthen2/data/玩家UUID.ymlYAML 数据使用 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。
- 两件装备都不包含禁止强化关键词。
- 左侧装备强化等级高于右侧装备。
- 右侧装备强化上限不低于左侧装备当前等级。
- 左右装备分别属于可转移的强化组。
强化转移.yml中存在左组-右组对应的转移规则。- 玩家拥有足够的转移材料和金币。
转移方向固定为左侧装备向右侧装备继承。配置 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,并确保对应变量所属的扩展或插件能够正常返回值。
排查顺序:
- 确认 PlaceholderAPI 已加载。
- 确认对应变量在服务器中可以正常解析。
- 确认变量返回的是公式需要的数值或条件需要的文本。
- 确认变量写在插件支持处理的配置字段中。
- 检查变量替换后是否形成有效的四则运算或条件表达式。
为什么槽位强化等级变量返回不正确?
槽位变量格式为:
text
%lyqh_slot_level_插件#槽位%不同槽位来源使用不同参数格式:
| 来源 | 参数格式 |
|---|---|
| DragonCore | DragonCore#槽位名 |
| GermPlugin | GermPlugin#槽位名 |
| APInventory | APInventory#分页ID#槽位ID |
| LyInventory | LyInventory#背包ID#类型 |
| LyInventoryReload | LyInventoryReload#背包ID#类型 |
| YeeJewelry | YeeJewelry#背包ID#槽位ID |
| PXRPG | PXRPG#类型#背包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 | 变量替换、动态公式、条件和槽位变量 |
| LyMySQLCore | MySQL 玩家保底数据加载与保存事件 |
如果启用 MySQL 存储,必须安装 LyMySQLCore,并确保数据库成功连接,否则相关功能不会生效。
为什么物品库中的材料、保护符或替换物品无法取得?
检查对应物品库是否安装,以及相关开关是否正确:
yaml
neigeItems: false
originAttribute: false
SX-Item: falseneigeItems 的优先级高于 OriginAttribute。配置注释还说明 OriginAttribute 未检测到物品时会继续检测 MythicMobs。
项目示例中的替换物品还提到 AzureFlow。由于不同物品来源使用相同字符串入口,物品 ID 必须与实际物品库中的 ID 一致,并避免在多个物品库中使用容易冲突的 ID。
为什么修改消息、GUI 标题或按钮 lore 后没有变化?
确认修改的是实际运行目录中的 config.yml,然后执行管理员重载命令:
text
/qh reloadGUI 文本分为强化界面、强化券界面和强化转移界面三组。需要修改对应前缀的配置:
| 前缀 | 对应界面 |
|---|---|
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-headreplace-content.fail-result-take-levelreplace-content.fail-result-no-changereplace-content.fail-result-break
如果删除 {fail_result},失败结果仍会参与实际判定,只是不再显示在按钮 lore 中。
为什么音效报错或没有播放?
sound 只提供两种配置值:
| 配置值 | 使用的声音名称体系 |
|---|---|
1.7 | 旧版声音名称 |
1.12 | 新版方块声音名称 |
应根据服务端版本选择可用的声音配置。填写其他值时,现有逻辑不会播放强化音效。
配置改坏后应该先检查什么?
按以下顺序排查:
- 查看控制台是否存在 YAML 格式、公式、物品库或数据库异常。
- 检查 YAML 缩进,尤其是强化方案的等级节点、列表和映射。
- 确认等级范围使用类似
3-9的键,并使用字符串无法引起歧义的写法。 - 确认材料项至少包含“物品名称”和“数量”两段。
- 确认失败结果只使用
0、负数或break。 - 确认公式左右关键词成对出现。
- 确认修改后执行了重载;数据库开关则必须重启服务器。
- 使用固定概率、固定金币和单一材料进行最小化排查,再逐步恢复公式与变量。
不要通过修改已经投入使用的 强化标识符 和 强化名称 修复旧装备识别问题,这通常会让旧装备更难恢复。