Zh:Protocol FAQ

人们总是会有一些关于Minecraft Modern 协议的问题，所以我们将在本文档中讲述其中一些最常见的。如果你仍有麻烦，在IRC上加入我们，irc.freenode.net上的频道#mcdevs。

协议文档完备了吗？

取决于你的定义，是的！所有的数据包类型都是已知的，而且已经记录了它们的布局。尽管丢失了一些小细节，但是你编写功能性程序所需的一切在这里都有。我们同样收集了预发布版更改的信息，这使得我们快速记载新的发布版。

客户端的正常登入顺序是什么样的？

有关与Mojang服务器的交流，见认证。

推荐的登入流程看起来像这样，其中C是客户端而S是服务端：

1. 客户端连接至服务端
2. C→S: 握手状态=2
3. C→S: 开始登入
4. S→C: 加密请求
5. 客户端认证
6. C→S: 加密响应
7. 服务端认证，都启用了加密
8. S→C: 设置加密（可选的，启用加密）
9. S→C: 登入成功
10. S→C: 加入游戏
11. S→C: 插件消息：带有服务端铭牌的minecraft:brand（可选的）
12. S→C: 服务端难度（可选的）
13. S→C: 玩家能力（可选的）
14. C→S: 插件消息：带有客户端铭牌的minecraft:brand（可选的）
15. C→S: 客户端设置
16. S→C: 手持物品改变
17. S→C: 声明配方
18. S→C: 标签
19. S→C: 实体状态
20. S→C: 声明命令
21. S→C: 解锁配方
22. S→C: 玩家位置和外观
23. S→C: 玩家信息（添加玩家动作）
24. S→C: 玩家信息（更新延迟动作）
25. S→C: 更新视图位置
26. S→C: 更新光照（以玩家位置为中心的方形，每个区块发送一个）
27. S→C: 区块数据（以玩家位置为中心的方形，每个区块发送一个）
28. S→C: 世界边界（一旦世界结束加载）
29. S→C: 生成位置（“家”生成，不是登入时客户端生成的位置）
30. S→C: 玩家位置和外观（必需的，告诉客户端已准备好生成）
31. C→S: 传送确认
32. C→S: 玩家位置和外观（来确认生成位置）
33. C→S: 客户端状态（在接受区块之前或之时发送，还需进一步测试，如果没有发送服务端也可正确处理）
34. S→C: 物品栏、实体等等

离线模式

如果服务端为离线模式，它不会发送加密请求数据包，相似地，客户端也不应发送加密响应。在这种情况下，从不会启用加密，也不会出现任何认证。

如果服务端发送了一个不含加密请求的登入成功，那么客户端就会知道服务器为离线模式。

我觉得我啥都没做错，但是…

…我的玩家没有生成！

发送一些常规的数据包之后（握手、开始登入、物品栏、指南针和区块数据|区块），你最后会需要将玩家的初始位置发送给他们，这样他们就会离开“加载地图中”的屏幕。

注意如果使用了以下步骤，那么一个Minecraft客户端会生成玩家：

1. 执行握手（见协议加密)
2. 发送生成位置数据包
3. 发送玩家位置和外观数据包

上述步骤对于Minecraft 1.4.5来说已经足够了，发送数据包是一种很好的形式，因为这会在允许玩家生成之前告知客户端玩家周围的世界。

…我的数据包没有接受到完整的地图区块！

主条目：如何编写客户端

标准Minecraft服务端只会在你的客户端发送玩家状态更新数据包时发送完整的区块（任何通过玩家位置和外观（0x06）的玩家（0x03））。

…所有连接的客户端都无法控制地鬼畜了起来

对于较新的客户端来说，你的服务端需要提前发送49个区块而不只是一个。在生成连接客户端之前发送7×7的方形区块，中心为他们的位置。

…客户端试图发送0xFE01开头的无效数据包

客户端尝试合法ping，这只会在你的服务端没有合适地响应服务端列表Ping，包括发送了格式不正确的JSON。

…“超时”错误不久后客户端失去了连接

服务端理应每秒发送一个Keep Alive数据包，然后客户端应该使用该数据包的服务端方版本响应。如果任何一方在一段时间内没有接收到Keep Alive，那么它们会断开连接。

我应该怎样打开/保存命令方块？

客户端打开命令方块窗口的过程有一些复杂；客户端实际上使用了更新方块实体（0x09）数据包来打开它。

首先，客户端必须拥有至少一个为2的OP权限等级，否则客户端会拒绝打开命令方块（OP权限等级使用实体状态数据包设置）

要打开命令方块：

1. C→S: 玩家方块放置（0x1C），带有位置为右键的命令方块。
2. S→C: 更新方块实体（0x09），带有命令方块的NBT。

要保存它，使用MC|AutoCmd插件通道。