WTAzureSky

前面几篇文章处理的都是单次判定的问题：这一下打得对不对、这次攻击能不能开启 combo、这个窗口有多少容错。它们回答的是“某一拍”。 但在实际游戏里，combo 不是凭空出现的，它是一条线走到的结果： 两个人先靠近 → 进入互相能打到的距离 → 开始对刀 → 双方轮流命中、互相推挤 → 直到某一轮，其中一方出现失误，被推着向后走 → 另一方抓住这一下，把他锁住。 combo 就是在这条线的最后一刻

在 Minecraft 1.8.9 中，疾跑不是客户端和服务器共用的一枚开关。客户端有自己的疾跑状态，服务器有自己的疾跑状态，客户端还保存着一个“我最后一次告诉服务器的疾跑状态”。服务器改变状态后，又会通过实体元数据把结果发回客户端。 这些状态大多数时候会保持一致，但攻击会主动清除疾跑。要理解按住疾跑攻击、手动重置疾跑以及硬直期间重新同步，必须先把一个客户端 tick 和一个服务器 tick 按源

上一篇文章把问题定义成了一个窗口判断：从需要回看的 B 过去位置开始，一直到 B 收到 A 造成的击退速度包。在这篇文章里，我们进一步问：根据这个窗口，A 应该怎样移动和出手，才能稳定开启或维持 Combo？ 这里讨论的是操作条件和几何关系，不介绍自动化策略，也不使用模拟器中的具体配置。 文中的源码对应关系如下：PlayerControllerMP.attackEntity 创建并发送攻击包；En

上一篇文章介绍了 Minecraft 1.8.9 的玩家同步：自己的位置由本地客户端立即更新，其他玩家的位置则来自服务器的位置包，并经过三 tick 插值。 有了这些基础，就可以严格定义一个问题：A 当前的这次攻击，能不能保证在生效过程中不被 B 打到，从而开启 Combo？ 本文只讨论这一次攻击本身。它不预测后续如何追击，也不设计任何自动操作策略。 文中提到的类名都来自仓库 src/minecr

Minecraft 里的“一个玩家”其实同时存在于几份状态中：自己的客户端有一份，服务器有一份，其他玩家的客户端也各自保存一份。 这些状态描述的是同一个人，却不一定处于同一个时刻。本文直接沿着 1.8.9 源码的执行顺序，解释玩家位置如何从客户端到服务器，再从服务器到其他客户端。 下面的源码都来自仓库中的 src/minecraft/net/minecraft/。文中的代码片段是对应原版逻辑的简化

用数学模型分析网络同步延迟如何影响实时交互与攻击判定。

对不同玩家与点击方式的间隔数据进行分布拟合和比较。

从运动模型出发，定量推导 Minecraft 击退距离及其影响因素。

Hexo 的安装、写作、本地预览与 GitHub Pages 部署速查。