常见问题
为什么只安装服务端插件后,界面、时装和特效没有生效?
LyArmourers 是服务端插件与客户端 Forge MOD 配套运行的混合项目,两部分职责不同:
| 组件 | 安装位置 | 用途 |
|---|---|---|
PLUGIN-LyArmourers-版本.jar | Bukkit 服务端的 plugins 目录 | 负责配置、时装库、命令、实体数据、插件消息、API 和业务监听器 |
MOD-LyArmourers-版本.jar | 玩家客户端的 mods 目录 | 负责管理界面、模型读取、时装预览、玩家与实体渲染、动作、刀光、脚印和幻影 |
缺少客户端 MOD 时,服务端无法在玩家客户端打开管理界面或渲染时装、刀光、脚印、幻影等视觉内容。
客户端必须安装 MOD 吗?
必须。需要使用 LyArmourers 客户端功能的玩家都要安装配套 MOD。
客户端要求:
| 项目 | 要求 |
|---|---|
| Minecraft | 1.7.10 |
| MOD 加载器 | Forge |
| Forge 构建 | 1.7.10-10.13.4.1614-1.7.10 |
| MOD 文件 | MOD-LyArmourers-版本.jar |
| 安装目录 | 客户端 mods 目录 |
服务端 Plugin 不能代替客户端 MOD,也不应放入客户端 mods 目录。
为什么 Forge 无法加载 LyArmourers MOD?
依次检查:
- Minecraft 是否为
1.7.10。 - Forge 是否为
1.7.10-10.13.4.1614-1.7.10。 - 客户端是否使用 Java 8。
- 安装的文件是否为
MOD-LyArmourers-版本.jar。 - MOD 是否放在当前游戏实例的
mods目录。 - 是否误把
PLUGIN-LyArmourers-版本.jar当作客户端 MOD。
如果客户端实际闪退,应查看日志中第一次出现的 FATAL、Caused by 或对应的 crash-*.txt,不要只根据后续连带异常判断原因。
为什么 /lyarmourers manager 或 /lyarmourers entity 无法打开界面?
检查以下条件:
- 执行者是否拥有
lyarmourers.manager权限。 - 目标玩家是否在线。
- 目标玩家是否安装配套客户端 MOD。
- 服务端插件是否已经正常启用。
- 客户端和服务端是否正常使用
armourers插件消息通道。 - 目标玩家是否已经完成客户端插件消息通道初始化。
打开界面时,服务端会给目标玩家授予短时间 GUI 协议访问权。目录浏览、写入时装和实体设置等界面请求会经过该授权检查。
为什么打开管理界面后,目录没有刷新?
服务端每次返回目录时,都会附带当前完整相对路径。客户端只接受与最近一次请求路径一致的目录响应,较早返回的旧数据会被丢弃。
出现目录不刷新时,应检查:
- 客户端与服务端是否使用同一个业务通道,默认是
armourers。 - 服务端插件是否已经注册插件消息监听器。
- 客户端 MOD 是否已经完成网络注册。
- 时装目录请求是否被 GUI 临时授权拒绝。
- 服务端是否在处理请求时出现协议解析异常。
时装文件应该放在哪里?
服务端时装库根目录为:
text
plugins/LyArmourers/skins目录可以多层嵌套,客户端界面会显示服务端返回的完整相对路径。
当前服务端时装库识别以下格式:
| 格式 | 用途 |
|---|---|
.armour | Armourer's Workshop 时装文件 |
.lyarmourers | 按 .armour 兼容流程读取 |
.bbmodel | Blockbench 工程、Bedrock geometry 或 LyCustom ModelData 包装 |
合成功能只接受真实 .armour 文件,不能把 .bbmodel 合成为 .armour。
明明存在时装文件,为什么仍提示“时装不存在”?
检查文件是否确实位于 plugins/LyArmourers/skins 内,并确认扩展名属于受支持格式。
服务端会清理客户端传入的路径,并阻止通过 .. 访问时装库外部文件。即使客户端提交了文件名、时装 ID 或旧完整路径,最终也必须由服务端时装库索引解析到真实存在的库内文件。
执行 /lyarmourers reload 可以重新加载配置和服务缓存。
为什么物品已经写入时装,但客户端仍显示原版物品?
当前物品时装只使用以下 NBT:
text
LyArmourers
└─ skin: Stringskin 保存去除空白字符后的末级文件名 ID。客户端需要先从服务端获得完整时装库索引,才能把该 ID 解析为真实相对路径并请求模型资源。
旧物品如果只包含 armourersWorkshop、根级 skin、version 或其它旧兼容字段,不会被当前 LyArmourers 客户端识别。需要重新生成物品,或使用 /lyarmourers setskin <时装ID> 对当前手持物品重新写入 LyArmourers.skin。
/lyarmourers setskin 会替换手里的物品吗?
不会。
该指令只把解析后的时装 ID 写入当前手持物品的 LyArmourers.skin,不会替换物品材质、数量、名称或 Lore。
以下情况不会修改手持槽:
- 执行者不是玩家。
- 玩家没有
lyarmourers.manager权限。 - 玩家当前空手。
- 时装无法在服务端时装库中找到。
- NBT 写入或写入后的校验失败。
为什么关闭装备时装渲染后,部分时装仍然显示?
render-player-equipment-skins 只控制玩家原版头盔、胸甲、护腿和鞋子四个装备槽中带时装 NBT 的物品兜底渲染。
关闭后,以下来源不受影响:
- API 设置的玩家时装。
- entity 界面设置的玩家或实体时装。
- 手持物品时装。
- CustomNPCs NPC 时装。
- 普通实体时装。
该配置会在玩家进服和执行 /lyarmourers reload 后同步到客户端。客户端断开当前服务器后会恢复默认开启状态。
为什么关闭物品预览后,第一人称或第三人称时装仍然显示?
render-item-skin-preview 只控制背包、快捷栏等物品槽位中的时装模型图标,以及鼠标悬停时的时装预览框。
关闭后不会影响:
- 第一人称手持时装。
- 第三人称手持时装。
- 玩家穿戴时装。
- 实体时装。
- manager 和 entity 界面的时装库预览。
为什么时装预览一直显示“正在加载预览”?
客户端会先向服务端请求原始时装文件,再进行解析或异步烘焙。资源尚未返回或 .armour 尚未完成烘焙时,预览会保持加载状态。
可检查:
- 文件是否存在于服务端时装库。
- 服务端插件是否已经注册消息通道。
- 客户端是否安装配套 MOD。
- 服务端是否报告文件不存在、协议解析失败或回包过大。
.armour文件版本是否超出当前内置读取器支持范围。
小文件由单个响应发送,大文件会按 16000 字节分片。客户端请求超过 3000ms 未完成时允许重试。
为什么 .bbmodel 时装出现在角色身体中间?
通常是模型类型没有被正确识别。
手持型时装包括:
text
sword、bow、pickaxe、axe、shovel、hoe、shield、item、block这些类型不会作为身体模型渲染,只会在实体实际持有匹配物品时挂到手部。
如果模型本应作为全身时装,应在 .bbmodel 的 setting.type 中明确设置为 outfit,或使用能够被类型回退规则识别的文件名。显式 setting.type 的优先级高于文件名推断。
为什么手持型时装没有显示?
实体实际手持物品的类型必须与时装类型匹配:
| 物品类型 | 时装类型 |
|---|---|
| 剑 | sword |
| 弓 | bow |
| 镐 | pickaxe |
| 斧 | axe |
| 铲 | shovel |
| 锄 | hoe |
| 方块 | block |
| 其它 Full3D 物品 | item |
如果物品自身带有 LyArmourers.skin,客户端优先渲染该物品自己的时装。物品本身没有时装时,客户端才会从实体已穿戴的手持型时装中查找匹配项。
手持型时装不会在玩家空手或物品类型不匹配时强制显示到身体上。
为什么 .bbmodel 身体时装没有隐藏原版皮肤部位?
.bbmodel 不会根据 outfit 类型自动隐藏全部原版模型。需要在模型 setting 中明确声明对应隐藏项。
常用字段包括:
| 原版部位 | 可用设置字段 |
|---|---|
| 头部 | hideHead、overrideModelHead、hideModelHead、head |
| 帽子层 | hideHeadOverlay、hideModelHeadOverlay、headOverlay |
| 身体 | hideChest、overrideModelChest、hideModelChest、chest、body |
| 左臂 | hideArmLeft、overrideModelArmLeft、hideModelArmLeft、leftArm |
| 右臂 | hideArmRight、overrideModelArmRight、hideModelArmRight、rightArm |
| 左腿 | hideLegLeft、overrideModelLegLeft、hideModelLegLeft、leftLeg、leftFoot |
| 右腿 | hideLegRight、overrideModelLegRight、hideModelLegRight、rightLeg、rightFoot |
手持型 .bbmodel 不参与身体部位隐藏。
为什么 .armour 和 .bbmodel 的隐藏效果不同?
两种格式使用不同规则:
.armour根据文件中的真实 SkinType 隐藏对应原版部位。.bbmodel只根据setting中明确存在的隐藏开关处理。
.armour 的套装类型会隐藏头、帽子层、身体、双臂和双腿;.bbmodel 即使类型为 outfit,也不会在未声明隐藏字段时自动隐藏全部部位。
为什么 .bbmodel 预览上下倒置?
Blockbench 模型在解析阶段已经完成 Y 轴坐标转换。GUI 预览外层应使用正向 Y 缩放,不能再次添加负 Y 缩放。
世界实体、手持物品、物品图标和 GUI 预览使用不同的外层矩阵,不能直接复制其它渲染入口的翻转参数。
为什么 .bbmodel 动画没有播放?
自动动作会根据玩家状态从模型已有片段中选择:
| 玩家状态 | 候选动作 |
|---|---|
| 攻击 | attack_连击段、attack、swing |
| 潜行 | sneak、crouch、idle |
| 疾跑 | sprint、run、walk、idle |
| 行走 | walk、run、idle |
| 默认 | idle |
如果模型没有对应动作,会继续回退到其它候选动作。服务端强制播放自定义动作时,该动作必须真实存在于目标 .bbmodel 动画数据中;不存在时,客户端会继续使用自动动作,避免模型停在无效状态。
为什么动画播放指令有成功提示,但模型没有明显变化?
检查以下情况:
- 目标玩家是否在线并安装配套客户端 MOD。
- 目标实体当前是否穿戴支持该动作的
.bbmodel。 - 自定义动作名是否真实存在于模型动画数据中。
- 动作名是否属于客户端支持的更多动作内置名称。
- 服务端插件是否已经注册动作消息发送逻辑。
/lyarmourers animation <在线玩家> play <动作名> 固定使用非循环播放和 0 毫秒过渡。停止指令会恢复客户端自动动作选择。
为什么 CustomNPCs NPC 无法显示时装?
当前专用兼容目标是:
text
noppes.npcs.entity.EntityCustomNpc其它 NPC 模组实体不会进入 CustomNPCs 专用渲染分支,而是使用普通非玩家实体路径。
同时检查:
- NPC 是否在 entity 界面的附近实体列表中。
- NPC 是否位于玩家
16格范围内。 - 客户端是否安装了对应 CustomNPCs 环境。
- 设置请求是否同时发送运行时实体 ID 和 UUID。
- 服务端是否成功找到当前已加载的 Bukkit 实体。
- 时装文件是否能由服务端时装库解析。
为什么 CustomNPCs NPC 的时装倒置、悬空或遁地?
CustomNPCs 使用独立根矩阵和六部位模型适配,不能回退到普通实体渲染路径。
需要确认:
.bbmodel是否通过 CustomNPCs 专用渲染入口处理。- 是否使用
LyCustomNpcModelAdapter读取当前帧ModelMPM部位矩阵。 - 根矩阵是否保留
-24px角色高度基准。 - 模型单位是否只缩放一次
1/16。 - 是否错误重复应用 Y/Z 轴翻转或身体父级矩阵。
如果只有 Body 下的翅膀、尾巴、披风或其它子骨骼错位,应检查身体角色空间锚点是否仍为 1.5。
为什么 CustomNPCs NPC 穿上时装后,原版手臂或武器位置错误?
NPC 时装本体和 NPC 背包中的原版武器属于两条渲染链。
时装隐藏原版手臂时,客户端会临时移除 NPC 主副手槽位,阻止 CustomNPCs 在错误位置绘制武器;渲染结束后再恢复槽位,并使用 CustomNPCs 当前手臂的官方挂点补绘主副手物品。
如果出现武器在脚边、身体内部或方向反转,应检查是否错误使用了 .bbmodel NPC 根矩阵作为手持物品根矩阵。NPC 原版武器补绘必须使用独立的手持根矩阵和当前 modelBipedMain 手臂挂点。
模型文件内部自行建模的剑、弓或法杖仍属于时装几何,不会替换 NPC 背包中的原版武器。
为什么实体永久时装在重启后消失?
永久时装会尝试双写到:
- 实体 ForgeData NBT。
plugins/LyArmourers/entity-skins.ymlUUID 索引。
在目标 Forge/Cauldron 1.7.10 环境中,实体 NBT 会随玩家数据、实体和区块保存。纯 Bukkit 服务端如果不提供 Forge getEntityData(),NBT 反射会安全失败,此时只能依赖 YAML 索引保存和同步。
还应确认使用的是“永久保存”,而不是“临时设置”。临时时装虽然也会写入带当前会话标记的实体 NBT,但服务端重启后会话 UUID 改变,旧临时数据会被判定为过期。
为什么临时时装在玩家重新进入后仍然存在?
临时时装会同时保存在当前服务端内存和带会话标记的实体 NBT 中。因此玩家在同一次服务端运行期间退出并重新进入后,临时时装仍可能恢复。
临时时装不会跨服务端重启永久保留。服务端重启后,旧会话标记失效,数据会由永久索引覆盖。
为什么非玩家实体或 CustomNPCs 设置到了错误实体?
Minecraft 1.7.10 中,部分非玩家实体和 CustomNPCs NPC 的客户端 UUID 可能与服务端 UUID 不一致。当前设置链路必须优先使用客户端运行时实体 ID 定位已加载 Bukkit 实体,再使用服务端真实 UUID 保存。
如果只使用旧 UUID 协议,可能把数据写入错误索引或无法读取目标实体 NBT。当前 entity 界面应同时发送运行时实体 ID 与 UUID。
为什么实体界面找不到远处的生物或 NPC?
实体界面只列出客户端当前已加载、距离当前玩家不超过 16 格的 EntityLivingBase。
列表包含玩家、生物和 CustomNPCs NPC,不包含掉落物、箭或其它普通实体。列表首次构建时按距离由近到远排序,距离相同时按实体 ID 排序。界面保持打开后不会每帧重新排序。
为什么实体时装清空后又恢复了?
永久清空会在 entity-skins.yml 中保留空列表标记,用于覆盖尚未加载实体的旧 NBT。如果该标记被手动删除,实体下次加载时可能再次从旧 ForgeData NBT 恢复数据。
不要在实体未加载时手动删除对应的空列表索引。应通过插件提供的实体时装清理入口完成永久清空。
为什么隐藏部位状态在服务端重启后恢复默认?
hidepart、showpart 和 PlaceholderAPI 变量读取的是会话级显示状态。该状态只保存在服务端内存中,不写入实体 NBT,也不写入 entity-skins.yml。
服务端重启后,部位显示状态会清空。
实体时装列表内部的 隐藏部位:<type> 标记属于实体数据机制,与玩家通过 hidepart/showpart 设置的会话状态不是同一存储方式。
PlaceholderAPI 变量为什么返回空字符串?
服务端插件只会在 PlaceholderAPI 已安装并启用时注册 lysz 变量标志。
变量格式为:
text
%lysz_<部位>%正常返回值为 show 或 hide。以下情况会返回空字符串:
- PlaceholderAPI 未安装或未启用。
- 服务端插件尚未正常启用。
- 变量没有玩家上下文。
- 部位名称无效。
部位参数支持 hidepart/showpart 使用的英文或中文名称。
为什么刀光或脚印没有显示?
依次检查:
- 玩家客户端是否安装 LyArmourers MOD。
- 服务端插件是否已发送特效 YAML。
- 玩家是否绑定了有效配置 ID。
- 对应 YAML 是否成功加载且顶层
id唯一。 - 客户端本地贴图是否存在。
- YAML 中的
texture是否为对应目录下的正确相对路径。
客户端贴图目录:
| 特效 | 客户端目录 |
|---|---|
| 刀光 | resourcepacks/LyArmourers/SwordTrails/ |
| 脚印 | resourcepacks/LyArmourers/FootPrints/ |
服务端只发送 YAML 配置,不发送玩家自定义的静态图片或 GIF。缺少本地贴图时不会绘制对应特效。
刀光和脚印的 YAML 应放在哪里?
服务端目录固定为:
| 特效 | 服务端目录 |
|---|---|
| 刀光 | plugins/LyArmourers/effect-resources/sword-trails/ |
| 脚印 | plugins/LyArmourers/effect-resources/footprints/ |
每个 .yml 或 .yaml 文件是一份完整配置,顶层 id 是指令使用的唯一标识。修改 YAML 或客户端贴图后,执行:
text
/lyarmourers reload重载会重新读取配置和资源,并向在线客户端重新同步定义与玩家绑定关系。
设置 none 后,刀光和脚印的行为为什么不同?
两者定义不同:
- 脚印设置为
none后关闭脚印。 - 刀光设置为
none后使用 MOD 内置默认刀光参数和默认贴图。
因此刀光使用 none 后仍可能继续显示,这是预期行为。
为什么脚印动画中的某个动作没有执行?
脚印动画只接受已定义的动作及合法参数:
| 动作 | 参数格式 |
|---|---|
delay | 毫秒 |
scale | 目标倍率 毫秒 [缓动] |
scale-width | 目标倍率 毫秒 [缓动] |
scale-length | 目标倍率 毫秒 [缓动] |
alpha | 目标透明度 毫秒 [缓动] |
rotate | 相对角度 毫秒 [缓动] |
move | 向右格数 向前格数 向上格数 毫秒 [缓动] |
color | 红 绿 蓝 毫秒 [缓动] |
缓动只接受:线性、缓入、缓出、缓入缓出。省略时默认使用 缓入缓出。
单份 YAML 最多读取 128 个动作,单个动作最长 600000 毫秒。未知动作、参数数量错误或数值不合法的动作会被忽略,并写入客户端日志。
为什么脚印有 animation 后,lifetime 不再生效?
存在有效 animation 列表时,脚印会严格按动作顺序播放,并在全部动作完成后立即删除,此时 lifetime 不参与删除时间计算。
没有有效动画动作时,客户端才使用内置兼容效果和 lifetime 生命周期。
为什么奔跑幻影没有出现?
奔跑幻影需要同时满足:
- 服务端已为目标玩家开启幻影。
- 目标玩家处于疾跑状态。
- 玩家确实产生移动动作。
- 观察者安装配套客户端 MOD。
- 客户端已经收到幻影状态和参数同步包。
停止奔跑只会停止新增快照,已经生成的幻影会在配置生命周期内自然淡出。执行 off 才会撤销授权并立即移除该玩家的全部客户端幻影。
为什么修改幻影配置后没有立即生效?
修改 config.yml 后需要执行:
text
/lyarmourers reload重载后服务端会向全部在线客户端同步以下参数:
| 配置项 | 安全范围 |
|---|---|
afterimage.lifetime-ticks | 1~1200 |
afterimage.draw-interval-ticks | 1~1200 |
afterimage.snapshot-interval-ticks | 1~1200 |
afterimage.maximum-count | 1~64 |
afterimage.alpha | 0~255 |
新进入服务器的客户端也会收到当前配置。
为什么第一人称只有原版物品,没有时装武器?
检查:
- 实际渲染物品是否带
LyArmourers.skin。 - 客户端是否已经收到该 ID 对应的真实时装路径。
- 实体穿戴的手持型时装是否与当前物品类型匹配。
- 时装资源是否已经加载完成。
- 当前物品是否为地图;地图保留原版双手地图渲染。
资源未加载完成时,渲染桥会继续委托原物品渲染器,完成后再切换到时装模型。第一人称不会等待打开 manager 或 entity 界面后才允许加载资源。
为什么第一人称时装手臂和原版手臂重叠?
身体型 .armour 或 .bbmodel 右臂成功绘制时,应完全替换玩家皮肤右臂。只有资源缺失、模型没有右臂结构或不存在可用身体型时装时,才回退绘制原版手臂。
第一人称手臂只接受会覆盖手臂的身体型时装。head、legs、feet 以及 sword、bow、tool、item、block 等手持型时装不参与手臂替换。
为什么物品图标正常,但鼠标悬停预览或手持模型异常?
背包图标、Tooltip 预览、第一人称和第三人称使用不同渲染矩阵,不能用其中一个入口的变换规则替代其它入口。
特别是 .bbmodel:
- 背包和快捷栏图标只读取
display.gui;缺失时不会回退到第三人称 display。 - 第一人称不会读取
firstperson_righthand,而是按项目兼容顺序回退其它 display。 - Tooltip 预览会根据手持型或身体型模型使用不同观察矩阵。
- 世界手持模型会先使用原版物品矩阵,再叠加项目和文件 display 变换。
如果只有一个入口异常,应针对该入口检查模型 display 和类型识别,不要通过修改全局骨骼坐标修复。
为什么物品时装导致客户端渲染其它物品异常?
物品时装渲染需要成对恢复 OpenGL 矩阵和属性状态。项目会捕获单个时装路径的运行时异常,并按路径只记录一次日志,避免快捷栏或背包渲染直接打断客户端主循环。
如果异常后其它物品也出现错位、透明度或贴图错误,应查看客户端日志中最早出现的时装模型解析、贴图上传、动画脚本或 display list 异常,并确认使用的是配套版本 MOD。
为什么 .armour 第一次加载时闪烁或反复消失?
.armour 文件接收后需要异步烘焙。请求状态必须保留到客户端缓存能够实际读取烘焙结果,不能在提交烘焙任务时提前视为完成。
同一路径在缓存已有结果或仍处于未超时烘焙状态时,不应重复提交。若客户端日志显示同一文件被持续请求和反复烘焙,通常说明客户端 MOD 版本与当前服务端协议或缓存逻辑不配套。
为什么 .armour 文件会提示版本不兼容?
客户端读取 .armour 时会处理文件版本异常,避免不兼容文件直接导致客户端闪退。出现该提示通常表示文件由更高版本格式生成,当前内置 Armourer's Workshop 兼容读取器无法完整解析。
应换用能够被当前 Minecraft 1.7.10 客户端读取的 .armour 文件,而不是修改扩展名绕过检查。
为什么合成时装失败?
合成只支持真实 .armour 源文件,并会输出到:
text
plugins/LyArmourers/skins/时装合成输出后缀固定为 .armour。
以下文件不能参与合成:
.bbmodel.lyarmourers- 目录条目
- 不存在或无法解析的文件
为什么重载后部分功能生效,部分功能仍然无效?
/lyarmourers reload 需要 lyarmourers.admin 权限,并会重载配置、服务缓存、刀光和脚印 YAML,再同步在线玩家。
重载不能代替以下操作:
- 不能代替客户端安装 MOD。
- 不能修复不存在或格式不兼容的时装文件。
- 不能自动传输玩家客户端缺少的刀光或脚印贴图。
- 不能持久化原本只保存在内存中的玩家部位显示状态。
为什么外部插件获取到的 LyArmourers API 是 null?
公开 API 接口位于 Plugin 模块。服务端业务尚未初始化时,API 获取结果为 null。
外部插件调用前必须判断 API 是否可用。
为什么 API 设置了实体时装,但某些玩家看不到?
检查目标观察者的全局时装可见状态。如果通过 API 关闭了某玩家的全局实体时装显示,服务端会向该玩家发送空时装列表清理现有显示,并跳过后续全局实体时装广播和进服同步。
还应确认:
- 观察者安装了客户端 MOD。
- 实体当前位于客户端可见范围内。
- 服务端已发送实体运行时 ID、真实 UUID 和时装列表。
- 时装路径存在于服务端时装库。
- 客户端已经获得对应资源和 ID 到路径索引。
为什么外部插件监听不到时装更新事件?
事件契约位于 Plugin JAR 的 Ly.armourers.client.plugin.event 包中:
| 事件 | 触发时机 |
|---|---|
EntitySkinUpdateEvent | 实体时装写入前 |
PlayerSkinUpdateEvent | 玩家时装写入前 |
外部插件应依赖本地 Plugin 契约 JAR 中的事件类。
为什么 LyCustom 粒子没有显示?
当前服务端对外固定粒子名为:
text
暴雪粒子使用通道:
| 通道 | 用途 |
|---|---|
lycustom:main | 主粒子通道 |
lycustom | 兼容通道 |
粒子包由服务端发送,实际解析和渲染由客户端 MOD 完成。观察者没有安装客户端 MOD时,服务端发送粒子包也不会产生画面效果。
服务端必须安装 PlaceholderAPI 吗?
PlaceholderAPI 是可选依赖,只影响 %lysz_<部位>% 状态变量。未安装 PlaceholderAPI 时,时装库、实体时装、模型渲染和其它核心功能仍可运行。
项目文件未将 PlaceholderAPI 声明为新版 Plugin 的强制依赖,而是作为软依赖处理。
服务端必须安装 MythicMobs 或 LibsDisguises 吗?
当前新版 Plugin 资源只把 PlaceholderAPI 声明为软依赖,没有把 MythicMobs 或 LibsDisguises 声明为必需依赖。
仓库根目录存在一份旧 plugin.yml,其中包含不同的主类、别名和依赖声明;当前模块化构建实际使用的是 Plugin/src/main/resources/plugin.yml。部署时应使用 PLUGIN-LyArmourers-版本.jar,不要使用旧根目录描述文件判断当前依赖关系。
启动日志出现 CustomNPCs 的 FML construction 警告,是 LyArmourers 导致的吗?
日志中的:
text
Detected an attempt by a mod FMLMod:customnpcs... to perform game activity during mod construction表示对应版本 CustomNPCs 在模组构造阶段访问了游戏状态。该警告由 FML 标记到 customnpcs,与 LyArmourers 的 NPC 时装矩阵、实体命令和插件消息没有直接关系。
LyArmourers 对 CustomNPCs 使用可选反射探测,不把 noppes.* 类作为强制编译依赖,并通过不执行静态初始化的方式检查类是否存在。
如果客户端仍能进入主菜单,该信息通常只是启动警告。若实际闪退,应继续查看后续第一次出现的 FATAL、Caused by 或崩溃报告。
Forge Version Check 出现 JSON 异常,需要修改时装文件吗?
不需要。
Forge Version Check 线程中的 Expected BEGIN_OBJECT but was STRING 表示 Forge 版本检查接口返回了非预期内容,不代表 .bbmodel、.armour、CustomNPCs 动作或 LyArmourers YAML 解析失败。
如果游戏可以继续启动,可以先按网络版本检查警告处理。若游戏崩溃,应以主线程后续最早的致命异常为准。
日志出现 Nashorn 的 System.exit() 警告,是插件主动退出游戏吗?
项目证据中的该警告来源是 Nashorn 脚本引擎内置的 jdk/nashorn/internal/objects/Global.exit。它表示 FML 扫描并重定向了脚本引擎中的退出方法,不代表 LyArmourers 主动调用 System.exit()。
应结合警告后的第一条实际致命异常判断是否影响启动。
更新 Plugin 后可以继续使用旧客户端 MOD 吗?
不建议混用。
Plugin 和 MOD 共同依赖插件消息包号、配置同步、时装 ID 索引、实体运行时 ID、动画、特效和渲染协议。两端版本不一致,可能表现为界面打不开、目录不刷新、实体时装不同步、预览持续加载或客户端只显示原版模型。
部署时应同时更新配套的 Plugin 和客户端 MOD。