Scaffolding 联机协议

[burningtnt]

检查项

• 我充分理解提交的建议可能无法所有启动器作者参与，并尊重所有启动器开发者的选择
• 我确认在Issues列表中并无其他人已经提出过与此问题相同或相似的问题
• 我确认该反馈并非针对单个启动器的，如果是，我将会去该启动器的反馈页面反馈

您是什么类型的用户

启动器作者

请简单的说一下您的想法

Scaffolding 联机协议 是由 HMCL、PCL CE、FCL 共同编写的 Minecraft 联机客户端数据交换协议。

在 EasyTier 的基础上，它允许联机客户端相互交换和 Minecraft 联机的相关数据，带有充足可拓展性，允许联机客户端自定义“子协议”交换更多数据。

Scaffolding 联机协议由社区驱动。如果您想修改协议内容，可依照 Scaffolding-MC/Scaffolding-MC#3 规范递交 Scaffolding Enhancement-Proposal (SEP)。

它能解决什么样的问题/带来什么样的帮助

我们希望更多启动器能够加入这一协议，实现高级别的跨启动器联机互通。

期望的结果

各启动器依据文档实现 Scaffolding 联机协议。

是否有对这个方案的相关链接？

https://github.com/Scaffolding-MC/Scaffolding-MC

附注

No response

[Silverteal]

由于我没有参与起草，理解上产生了几个问题：（更新）

• （修改意见已提交至 SEP-3 草案）虽然没有具体格式规定，但是 machine_id 从协议模型上是否是和房间码，网络名（文档中称为联机网络），以及两种子协议同级的一等概念？

• （修改意见已提交至 SEP-3 草案）”通用协议“和”玩家“为何是同级的副标题？所有的”通用协议“接口调用和”玩家“接口调用都是由客户端主动发起的吗？虽然以server的名字应该能猜出来是，但不能总是猜。

• （已于 SEP 3 草案中解决）”标准协议“，”通用协议“，”拓展协议“的名字没有很好地表达协议的层级关系，我想”通用协议“可能是一个”标准协议“下的分类？

• （已于 SEP 3 草案中解决）另外，”xx协议“等看起来实际上是定义了一组接口，为了与上层的协议（”联机信息获取协议“）作区分，或许应该叫”xx接口“？

另外有些建议：

• （修改意见已提交至 SEP-3 草案）建议对小标题编号，并将名词定义扩充为术语表（简要说明后面提到的房间码，网络名以及两种子协议，甚至直接移过去），否则阅读时可能搞乱层级关系，也不方便引用。

• （撤回）不应该把与“扩展”相对的概念称为“标准”，因为“扩展”的部分本身也是在标准框架内定义的、合法的扩展机制，而不是与”标准“相对所暗示的“非标准”，将“标准”改为“核心“等可能更妥当。

• （撤回）”联机信息获取协议“外层的封包格式，我个人认为应该避免使用“标准”这个词语表示，因为“标准”一词和“协议”类似，位格比较高。不过很可能不是所有人都这么认为，如果社区领导不认同就当我没说吧。

由于一些问题可能是沟通不畅导致的，没有直接提交 SEP。

[burningtnt]

感谢您指出的问题。现在这一版本的文档仍有不少不清晰的地方，我将会在之后逐步提交 SEP 解决上述问题。如果您认为有问题迫切需要解决，可以直接提交 SEP。

[Silverteal]

另外我注意到，目前版本的协议文本主要聚焦于数据格式，而对于客户端与服务端的具体行为只采用了较少的篇幅描述和规定，期待后续版本的文档能够持续优化，并维持低水平的心智负担。

[burningtnt]

我已递交 Scaffolding-MC/Scaffolding-MC#5 ，希望社区能提出意见。

[Silverteal]

已向 SEP 3 提交修改意见：burningtnt/Scaffolding-MC#1