メニュー
理解并维护 SlimefunHelper 中 `ElytraExtra.applyAxisLimit2` 的 Elytra 烟花容错盒、两帧 look 叠加、目标逼近与爬升策略选择。用于分析 `currentMotion = currentRotation * 1.7` 一类上推方案，判断斜向追点、竖直拉升、前后折返等 rotation 序列的收益与约束。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
Analyze server-side block interaction flow around ServerPlayerInteractionManager.interactBlock, BlockState.onUseWithItem/onUse, ItemStack.useOnBlock, and BlockItem.useOnBlock in this merged Yarn Minecraft tree. Use when tracing whether right-clicking a block can fall through into item use or block placement, when classifying PASS vs PASS_TO_DEFAULT_BLOCK_ACTION behavior, or when summarizing special interactable block families.
Grim 中 Elytra 预测、烟花容错、offset 判定与 setback 回滚的结果逻辑。用于直接回答滑翔检测、fireworksBox、1.7 来源与拉回后高速原因。
在 SlimefunHelper 中兼容多个 Baritone 发行形态，尤其是“全混淆”版本。用于区分无混淆、仅方法混淆、类与方法全混淆三种形态，并决定 MixinPlugin、目标类定位、成员定位、反射桥接和 hooks 访问层该如何拆分。
在 SlimefunHelper 中新增或改造模块配置屏幕时，统一复用 `WidgetUtils` 的配置屏幕组装链，而不是在模块里重复手写 `DynamicListWidget + RefKeyValueInputWidget`。用于把 `BaseModule` 的 `editableConfig`、显示条件、模块标题、主题色和自定义 widget 接到同一条打开链路上。
理解并维护 SlimefunHelper 中 `NBTType`、`NBTParsable`、`NBTRef`、`AttrKeyValue` 的自动配置链。用于分析或新增 NBT 配置类型时，追踪它如何在字符串、原始对象、NBT、Ref、可编辑 GUI 之间自动转换，并据此实现新的 `NBTParsable` / 组合型配置结构。
为 SlimefunHelper 新模块补全 BaseModule 基础注册骨架。用于创建或改造模块时，统一完成模块名、ModulePath、Flag 绑定、不同类别 Ref、监听器、常用监听器、热键和命令注册。
SOC 職業分類に基づく
| name | elytra-axis-limit-target-climb |
| description | 理解并维护 SlimefunHelper 中 `ElytraExtra.applyAxisLimit2` 的 Elytra 烟花容错盒、两帧 look 叠加、目标逼近与爬升策略选择。用于分析 `currentMotion = currentRotation * 1.7` 一类上推方案，判断斜向追点、竖直拉升、前后折返等 rotation 序列的收益与约束。 |
| disable-model-invocation | true |
处理 me.matl114.hacks.modules.move.ElytraExtra 的飞行追点问题时，统一按 applyAxisLimit2 这套运行时模型思考：
Y 攀升、横向逼近、还是两者折中不要退回到“单 tick 只看当前朝向”的直觉。
applyAxisLimit2 不是直接给一个“速度上限球”，而是用“当前 look + 上一 tick look”构出一个三轴容错盒，再把本 tick 请求速度压进这个盒允许的边界里。
所以 rotation 不是只影响“这一刻往哪飞”，还会影响“下一刻的允许空间长什么样”。
ElytraExtra.applyAxisLimit2EntityUtils.calculateGlidingVelocityLivingEntityMixin.travelGlidingPlayerStateManager.lastKnownRealMovementSpeed、lastPitch/lastYaw这一层至少有 4 个量：
v1：上一 tick 真实移动速度lookNow：当前 rotationlookPrev：上一 tick 的 pitch/yaw 对应 rotationrequest：本 tick 想申请的运动量，常见就是 currentRotation * 1.7先把 v1 和 lookNow 丢进 Elytra 物理，得到本 tick 的基础可达结果 v3。
这一步的结构是：
Y 和前向分量直接结论：
Y，不能只看 look.yapplyAxisLimit2 的盒子不是只由当前朝向决定，而是：
threshold，通常就是 min(autoRescaleAmount, request.length)可以把它理解成：
系统最后看的不是 request 的模长，而是：
X 是否超过 uMinX/uMaxXY 是否超过 uMinY/uMaxYZ 是否超过 uMinZ/uMaxZ谁先超，谁就决定整体缩放比例。
所以这是一个典型的三轴瓶颈问题：
讨论“怎么飞最好”时，先明确目标函数，否则结论会错位。
Y 尽快增加重点是：
uMaxY 要大v3.y 要大重点是：
Y 攀升同时横向逼近重点不是极端，而是同向复利：
Y 和目标方向横向轴同时得到两帧增强下面默认目标不是静止点，而是“横向仍在移动的点”，因此横向逼近不能被忽略。
这是当前模型下最合理的主策略。
因为它同时满足 3 件事：
look.y 仍为正，Y 轴容错和本体递推仍能吃到上升收益它不是“单 tick 最高飞”，而是“多 tick 综合收益最高”：
Y 持续增加适合绝大多数“追一个移动点并继续拉高”的场景。
如果抬头过猛，水平投影会太小，横向收敛会变慢。
如果过于平飞，Y 轴收益又不够。
所以它本质上是一个折中角度问题，不是纯竖直，也不是纯前冲。
这不是追移动目标的优先策略，只适合非常特殊的局面。
因为一旦水平投影过小，会同时出现两个问题：
如果目标几乎就在正上方，或者短窗口内只关心 Y 抬升、不关心横向误差，那么竖向策略可以作为临时动作。
所以它更像“短时抢高度”，不是“追点爬升”的主方案。
这套策略对“逼近移动目标并尽快上升”的综合目标不优。
如果两 tick 都保持向上，那么 Y 轴确实还能持续吃到正向贡献。
它会把横向主轴做成相互对冲：
这会直接带来两个后果：
如果目标是“边爬边追移动点”，折返策略基本劣于稳定斜向。
它最多只在一种偏门目标下有讨论价值：
Y但这已经不是“逼近移动目标”的同一问题了。
如果目标是：Y 攀升尽量快，同时横向逼近一个仍在移动的点。
默认排序应当是：
其中：
先预测目标下一小段时间的横向位置，不要只盯当前点。
每个 tick 的 look 水平分量尽量持续指向目标预测位置，不要频繁反向。
在能维持横向收敛的前提下，再尽量增大 look.y。
如果连续两 tick 的横向主轴发生反转，要先默认这是坏信号，而不是优化。
只有在“目标几乎正上方 / 短时只抢高度”时，才考虑临时切到更竖的姿态。
找“最佳 rotation 序列”时，不要把每 tick 独立贪心。
正确的搜索单位至少要是 2 tick：
Y 与横向逼近也就是说，rotation 序列优化至少要同时评估：
state:
lastVelocity
lastLook
targetPredictedHorizontalPos
for tick in horizon:
candidateLook = chooseLook(
horizontal -> point to targetPredictedHorizontalPos,
vertical -> as high as possible without killing horizontal convergence
)
box = buildBox(candidateLook, lastLook, threshold)
v3 = glideStep(lastVelocity, candidateLook)
request = candidateLook * 1.7
accepted = clampRequestIntoBox(request, box, v3)
score = gainY(accepted, v3) + approachTarget(accepted) - oscillationPenalty(candidateLook, lastLook)
advance state
lookNow1.7 理解成“最终实际速度固定等于 1.7”