召唤预设
骷髅陷阱骑兵预设
骷髅陷阱骑兵预设现在已经是一整套完整的 Summon 工作流程，把根实体、passenger 关系、输出审查和游戏内表现一并串起来。当你想要骷髅陷阱那种视觉冲击力、又不想耗着等自然雷击或罕见生成时，就用这条预设。整篇文章把召唤命令当作需要肉眼复核的遭遇数据来对待，而不只是一道语法题。图库里把 Workbench 状态和生成结果并排摆放，方便你在命令变成正式遭遇触发器之前，先把根实体、passenger 堆、装备和最终输出全部审视一遍。
预设结果
一匹骷髅马，背上骑着一个手持弓的骷髅弓箭手 passenger，随时可以拿来测试陷阱关卡或罕见遭遇。
输出
骷髅陷阱骑兵召唤命令
/summon minecraft:skeleton_horse ~ ~ ~ {SkeletonTrap:1b,Tame:1b,Passengers:[{id:"minecraft:skeleton",equipment:{mainhand:{id:"minecraft:bow",count:1},head:{id:"minecraft:iron_helmet",count:1}}}]}预设截图
构建预设
- 打开 Summon Workbench，把根实体设为骷髅马。
- 添加或核对 passenger 和装备细节，让骷髅陷阱骑兵在游戏里一眼能认出来。
- 在复制命令之前，再过一遍预览和 passenger 树。
- 查看输出面板里最终的 /summon 行，留意命令长度。
- 复制命令做一次小范围冒烟测试，或者先把它保存到 Project 里再叠加后续指令。
- 在一个干净的测试世界里把命令真的跑一遍，确认游戏里的效果和 Workbench 里的树是吻合的。
为什么骷髅陷阱骑兵值得做成预设
想要骷髅陷阱那种视觉冲击力，又不愿意等自然雷击或罕见生成时，这条预设就派上用场。
真正起作用的是结构本身：骷髅马掌握生成位置，可见的 passenger、装备或显示数据则赋予这条预设独有的遭遇身份。让整棵树一直保持可见，可以在命令离开 Workbench 之前就拦截掉括号错误。
用预设来组装遭遇战，应当方便日后回头审视。Workbench 截图记录下哪个实体掌握移动和碰撞，第二张截图记录 passenger 或装备细节，输出截图让生成的 /summon 行一直留在视野里。最后，游戏内截图证明 Minecraft 真的渲染出了同样的关系——这一步是纯文本示例永远给不了的。
测试与版本细节
自然生成的骷髅陷阱还涉及到额外的游戏逻辑。这条预设只聚焦于可见的 rider 堆，后续的雷击效果、音效或触发命令请单独再补。
第一次测试请放在开阔的 Java 世界里跑，并留意命令长度警告。结构紧凑的 rider 预设可以直接粘贴使用，而更长的 BOSS 或装备变体则建议改用命令方块或数据包函数。
在叠加效果、战利品表、音效或计分板之前，先让第一次冒烟测试保持精简。敌对的 passenger 可能会乱跑、起火、消失，或者因为体型和难度的不同而表现各异，因此请在可控的条件下确认基础的 rider 或装备组合。等画面效果稳定之后，再添加标签，让后续命令通过标签来定位目标，不要依赖显示名称或就近选择器。
- 让根实体和 passenger 各自扮演不同的角色，互不混淆。
- 在添加清理或后续命令之前，先把标签布好。
- 正式上线之前，先把难度和维度行为都测一遍。
下一步去哪里
在把它扔进真正的遭遇之前，先让 rider 隐身在触发器后面，把清理标签也跑通。
想看相邻的 rider 组合方案，可以对比猪灵骑乘疣猪兽预设、spider jockey 召唤命令预设和劫掠兽载掠夺者预设。
FAQ
这条骷髅陷阱骑兵的命令能直接粘进聊天框吗？
看命令长度警告就知道。如果生成的命令短于聊天上限，那就可以做快速聊天测试；超过的话请把它挪到命令方块或数据包函数里。
这在基岩版里能用吗？
不能——这是 Java 版的 Passengers 写法。基岩版需要另一套独立的骑乘流程，因为它没法嵌入和 Java 一样的递归 passenger NBT。
为什么非要附一张游戏内截图？
因为只有游戏内截图能证明 passenger 树或实体配置在 Minecraft 里真的被渲染对了，而不仅仅是 Workbench 预览看起来对。
打开这个工作流
从相关 Summon 工作台开始，然后按你的世界调整预设字段。