关于支持 Minecraft 服务器客户端自动更新的方案

[6get-xiaofan]

检查项

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

您是什么类型的用户

第三方网站管理/负责人（MC相关的）

请简单的说一下您的想法

我们团队开发了关于对 Minecraft 服务器游戏客户端的更新后端程序，并把这一套称为 McHMR 服务器客户端自动更新解决方案，并开放了 API 接口，已进入公测阶段，待稳定版上线会对开源社区完全开放所有源代码，希望各大中国 Minecraft 启动器能够接入此 API 实现 Minecraft 服务器游戏客户端在开始游戏前的检查更新功能。

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

如果是服务器服主制作好了服务器的客户端，通过启动器启动游戏，可以提前对游戏文件自动更新，而不是通过重新下载打包的游戏客户端，同时 McHMR 会支持公告、启动器背景、服务器帮助等一系列针对启动器的 API，使启动器可以在服务器客户端的应用上更加定制化。

期望的结果

支持启动器自动更新客户端功能。

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

https://doc.dooper.top
https://dev.dooper.top/login admin/admin123
https://xiaofans.lanzouq.com/itYFx26khccf

附注

目前 McHMR 已经完善了更新相关的 API，正在广泛征集意见，争取在规范性和合理性上做出更大的改进；
目前启动器相关的 API 正在开发中，预计 2 个月内上线。

[6get-xiaofan]

推荐的实现方法是在启动器设置页面添加一个用于配置连接版本管理端的按钮，点击后，在弹出页中粘贴版本管理端提供的 API，然后启动器请求这个 API，能够获取到基础的 API，然后通过这个 API 访问更新相关的 API，在启动游戏的生命周期里实现检查更新的逻辑。

目前更新器实现方式是：
更新器区别于启动器，而是在打开启动器前，先打开更新器，更新器通过 API 实现客户端文件的更新，更新完成后，更新器会直接启动配置好的启动器。

启动器支持之后，就是将角色转变为更新器直接负责检查更新、返回差异文件、下载增量包、替换/删除文件，然后直接启动游戏。

[Pigeon0v0]

这些功能可以直接打包进 MCBBS 整合包 v3...？

[6get-xiaofan]

这些功能可以直接打包进 MCBBS 整合包 v3...？

你可以自己部署版本管理端，在任何整合包或者服务器客户端配置更新器（但是不建议整合包，你需要自己承担服务器成本

[LJS08]

不太明白您的意思

如果您的平台对于启动器进行了定制
我想 您的平台对您平台定制的启动器您有责任对其进行更新和维护

[6get-xiaofan]

不太明白您的意思

如果您的平台对于启动器进行了定制
我想 您的平台对您平台定制的启动器您有责任对其进行更新和维护

就以这些功能用 HMCL 启动器举例：
启动器背景：
当在管理端设置了启动器的背景图片，HMCL 启动器在运行后，只需要请求 API，并下载背景进行设置启动器背景的操作。
公告：
当在管理端设置了公告，HMCL 启动器在运行后，只需要请求 API，并将公告内容添加到启动器空白位置展示或者弹出对话框。
帮助 API 类似 HMCL 启动器的帮助文档 API，PCL 启动器的帮助文档 API 等等

至于提到的更新和维护，都是由服主在版本管理端进行维护这些内容，不是由我们平台维护，就是将启动器这些功能交给了服主去自定义。

因为版本管理端是一个独立部署的程序，而不是一个我们搭建好，让服主参与进来的平台，所以一切的定制都交给了服主。

要使用这些功能，服主要主动搭建 McHMR，然后使用生成的 API，再和启动器进行配置，启动器就会主动请求服主搭建的 McHMR

[tnqzh123]

记得之前在 MCBBS 看到过同名项目，不知道是不是同一个项目。

我有点没理解，你们是打算做 SaaS，还是只做开源，所有想用的服主都要自己部署服务端？

[6get-xiaofan]

记得之前在 MCBBS 看到过同名项目，不知道是不是同一个项目。

我有点没理解，你们是打算做 SaaS，还是只做开源，所有想用的服主都要自己部署服务端？

只做开源

[zyxkad]

很好的一个想法，只是，为什么不直接让启动器去 poll 整合包链接呢？相对于整合包来说你这种有什么优势？

如果是公告，那么我认为游戏内公告和启动器显示的公告并无太大区别。如果要看及时性，启动器所展示的公告也并没有社交媒体上发的更及时

[zyxkad]

另外该程序有三路合并相关的处理么?
我指如果用户更改了某个配置文件后服务端也更改了该配置文件，本程序会如果处理差异?

[6get-xiaofan]

很好的一个想法，只是，为什么不直接让启动器去 poll 整合包链接呢？相对于整合包来说你这种有什么优势？

如果是公告，那么我认为游戏内公告和启动器显示的公告并无太大区别。如果要看及时性，启动器所展示的公告也并没有社交媒体上发的更及时

所以说这并不是为整合包做的，只是在实现游戏服务器客户端更新的同时能够实现整合包更新，在未来也不会特别的对整合包的更新特别做一些功能

[zkitefly]

客户端更新和整合包更新有什么区别（

[6get-xiaofan]

另外该程序有三路合并相关的处理么?
我指如果用户更改了某个配置文件后服务端也更改了该配置文件，本程序会如果处理差异?

一般情况下服务端提供的配置是不能被客户端所更改的，另一种情况是客户端提供配置文件，服务端不提供配置文件（提供也是一个默认的配置文件）。

这些配置文件类似于mod的配置文件，他们被储存在了.microsoft文件夹下config目录

这些文件都是客户端的配置文件服务端不应该对其做更新或更改，所以服务端可以设置该目录为白名单目录，类似的目录有材质包、光影包目录等。

也就是说，服务端不会更新玩家的自定义配置（需要设置白名单），但服务端会更新其他的所有文件，配置白名单都是可以在管理端进行设置的，并且提供了获取白名单的api接口。

同时目前也不打算支持您说的这个三路合并，因为它实际上在游戏客户端的更新上面是没有任何用处，实现这个更新是用的哈希值差异对比，而不是像git版本管理工具那样做到文件每一行都能精准判断是否有变化，如果加这个功能的话，就有点大材小用了，现在的任何游戏客户端更新方案里面都不会用你说的这个三路合并，除非这个游戏叫(Git :)

[6get-xiaofan]

客户端更新和整合包更新有什么区别（

本质上没有区别，都是将本地的游戏资源更新到与服务器上的游戏资源相同。

但是，服务器的客户端更新都是商业模式驱动的用户服务，整合包呢，整合包作者本身没有收益，除了为爱发电，如果你想给整合包上这种自动更新也是可以，除非作者能够承受用户更新让服务器所带来的成本。

[6get-xiaofan]

这些配置文件类似于mod的配置文件，他们被储存在了.microsoft文件夹下config目录

好像写错了

这不重要😅，理解那个意思就行

[6get-xiaofan]

很好的一个想法，只是，为什么不直接让启动器去 poll 整合包链接呢？相对于整合包来说你这种有什么优势？

如果是公告，那么我认为游戏内公告和启动器显示的公告并无太大区别。如果要看及时性，启动器所展示的公告也并没有社交媒体上发的更及时

你可以参考许多游戏启动器的商业模式，比如说原神等的游戏，他们的米游社社区也是非常活跃，群组也是非常活跃，但是活跃并不代表的所有人都喜欢去看社区，去看群，大部分玩家加群后下载完客户端就选择屏蔽群聊天了，除非遇到游戏上的问题才会选择去看，而社区(或者说群)到游戏到玩家之间的关联性就降低了，当把游戏启动器作为载体就能充分的增加之间的关联性，形成闭环，同样在服务器的商业运营模式上，这种可以非常有效的对活动等进行宣传。

还有就是你说的游戏内公告和启动器显示的公告是有区别的，游戏内的通知通常更应该是处于同一时刻对于玩家的时效性通知，而启动器的通知时效性相对较为宽泛。虽然一些重要的更新通知也希望玩家能够尽快知晓，但不像游戏内通知那样需要立即响应。

启动器显示的公告比如说：停服维护通知、版本更新详情通知等，一些活动通知可能会提前几天甚至几周发布，给玩家足够的时间来了解和安排参与活动的计划，让玩家直接跳转到公告的链接或者页面。

虽然二者在理论上有区别，事实上是可以混用的，主要看服主的选择，当然这个公告API最大的功能可能就是玩家不必进入游戏就能看到的通知。

[zyxkad]

但是，服务器的客户端更新都是商业模式驱动的用户服务，整合包呢，整合包作者本身没有收益，除了为爱发电，如果你想给整合包上这种自动更新也是可以，除非作者能够承受用户更新让服务器所带来的成本。

目前curseforge和modrinth都支持免费分发整合包（用modrinth还有钱拿

[zyxkad]

这些文件都是客户端的配置文件服务端不应该对其做更新或更改，所以服务端可以设置该目录为白名单目录，类似的目录有材质包、光影包目录等。

整合包经常需要更改客户端配置以让客户端用户获得最佳的沉浸式体验。服务端也有可能删除/替换一些用户希望保留的客户端 mod。

[6get-xiaofan]

但是，服务器的客户端更新都是商业模式驱动的用户服务，整合包呢，整合包作者本身没有收益，除了为爱发电，如果你想给整合包上这种自动更新也是可以，除非作者能够承受用户更新让服务器所带来的成本。

目前curseforge和modrinth都支持免费分发整合包（用modrinth还有钱拿

我上文写的很清楚，这不是给整合包作者使用的😅

[zyxkad]

如果对于非整合包，好像就只用更新一个 minecraft 本体了吧？那么也就是说你提供的这个程序主要功能在公告上面？
如此根 #4 有点像

[6get-xiaofan]

如果对于非整合包，好像就只用更新一个 minecraft 本体了吧？那么也就是说你提供的这个程序主要功能在公告上面？
如此根 #4 有点像

没错，更新minecraft本体+启动器相关功能

[6get-xiaofan]

如果对于非整合包，好像就只用更新一个 minecraft 本体了吧？那么也就是说你提供的这个程序主要功能在公告上面？
如此根 #4 有点像

我们本身的产品定位就不在整合包上面

[IceCream-QAQ]

你没有平台，用户需要自行部署，对比现有基于整合包的更新方案来讲，没有任何优势。

如果你是一个平台，愿意替用户承担下存储和流量成本，那还可以考虑。
你并不是，对比现有方案没有任何优势，你又靠什么来吸引别人开发呢？

任何启动器的开发者的精力都是有限的。
他们要优先把精力用来支持在更有吸引力的方案。
你希望你的东西能被人支持，被人喜爱，那你得先拿得出来足够打动人的功能。

BMCLAPI 为什么被广大启动器支持了呢？
因为他确实改变了 Minecraft 下载体验。
以至于开发者们愿意为了 BMCLAPI 以及 BMCLAPI 的节点提供者们，冒着一些风险在启动器内展示节点提供者信息。

[6get-xiaofan]

你没有平台，用户需要自行部署，对比现有基于整合包的更新方案来讲，没有任何优势。

你说的我能够理解，我想说的是：首先我选择开源代表着不会去做商业运营，这些功能使用权利和定制化能力都交给了用户，我们不会去干涉，如果以平台去提供储存 Minecraft 的游戏资源及更新等服务，涉及到的法律风险是我们承受不起的，选择开源是打算为社区做贡献和热爱 Minecraft 做出的决定，当然如果开源启动器的开发者愿意，我们可以提交相关接入的 PR

[6get-xiaofan]

个人省流，功能重复讨论/价值不大

没谁看重公告等客制化需求，成本太高没人考虑；整合包功能有点用但不多；游戏客户端如果指的是 client.jar 不是毫无意义吗…？都更新整合包里的 mod 了难道分开更新 client？

~~需要自己部署，没有社区托管，开服得专门开个推送/更新服务…启动器接入成本更是逆天

公告等客制化服务如果是已有服务可能会有更多服务器用，但若是提供托管则有 #4 (comment) 的风险

整合包功能受众受限于整合包经常更新的 Mod 端服务器玩家

开发成本巨大，开服的使用成本也巨大。这种操作如果是小型、非营利服务器不会持久，三分钟热度，因为是 self hosted…但如果是商业服务器，会考虑自行实现以上功能，而非寻求社区

介于以上原因，您可以尝试将此服务先面向服务器专用启动器，不止于客制化内容，进一步客制化启动器，并自行基于已有的开源启动器实现

如果能积攒一定的用户存量，自然会有玩家要求开源启动器提供此功能，自然启动器会合并功能…~~

理解，那我们先基于开源启动器做分叉版本