建议 HMCL 内置 LogShare 以简化用户日志分享流程

[qitry]

目前，许多中文 Minecraft 普通用户不清楚如何将报错日志分享给能帮助他们的人，尤其是在不支持文件上传的群聊或平台中。相比之下，安卓启动器如 FoldcraftLauncher 和 ZalithLauncher 2 内置了 LogShare.CN 工具，允许用户将日志转换为链接分享，并提供初步分析和更高的可读性。
因此，我建议 HMCL 也内置此工具。这样可以减少用户仅截取报错窗口截图的情况，或在用户截图后快速引导其使用一键分享功能上传崩溃日志。
API 文档：https://logshare.cn/api-docs

[zkitefly]

我觉得也可以自动上传日志，并提供二维码展示在游戏崩溃提示页面，防止那些拍照或截图的人不上传日志？🤔

[qitry]

二维码确实是个不错的解决方案，问题就出在二维码大部分时候是为移动端用户设计的，很多PC不支持二维码扫描，这会导致提供帮助的人在阅读崩溃日志的步骤变得繁琐，且移动端的可读性远远小于PC端。

[zkitefly]

二维码确实是个不错的解决方案，问题就出在二维码大部分时候是为移动端用户设计的，很多PC不支持二维码扫描，这会导致提供帮助的人在阅读崩溃日志的步骤变得繁琐，且移动端的可读性远远小于PC端。

我觉得这样子至少可以获得日志，而且 微信 和 qq 的图片查看器好像是可以右键扫描的？

[qitry]

而且 微信 和 qq 的图片查看器好像是可以右键扫描的？

或许是个好主意 不过这具体得看 HMCL 团队的决策了，如果有需要，LogShare 可以新增二维码返回

[LiuJiewenTT]

二维码确实是个不错的解决方案，问题就出在二维码大部分时候是为移动端用户设计的，很多PC不支持二维码扫描，这会导致提供帮助的人在阅读崩溃日志的步骤变得繁琐，且移动端的可读性远远小于PC端。

即便是二维码也能在角落塞文字的，这样即便没有扫码也能通过短链path获得实际链接

[qitry]

麻烦问一下有考虑内置吗

[zkitefly]

#5712

[qitry]

感谢，是会在下次更新中（大概率是明天或者今天）做一个二维码base64的接口

[zkitefly]

#5725

[DeliciousBread481]

我先说一下我的看法：
一、首先这个功能确实是适用于不方便发文件的网络论坛（如MC百科，小黑盒，B站）
但是HMCL有自己的官方挂牌帮助解决报错的QQ群 并且至少对于我个人来说 我觉得还是直接下载文件本地看的情况下还是更方便的
所以我觉得可以通过点击「导出错误详细信息」按钮 然后接着自行再在新窗口或新页面点击「导出文件」和「导出链接」按钮来实现

说起为什么那个按钮不改成「导出错误报告」，我觉得这个更简单通俗而且刚好又和PCL统一了一下（）还省字（）

二、其次我觉得那个网站依然有我难以接受的缺陷
1.上传压缩包时 产生的链接分享是压缩包里所有文件单独的分享链接 我的期望是只产生一整个压缩包的分享链接
2.下载链接里的文件时 文件名不是我上传时提供的原文件名 而是用分享链接的路由命名的文件名 这样对我分析报错确认文件有不方便的地方（如快速辨识崩溃前输出.txt/minecraft.log与latest.log）
3.而且此网站上传文件的大小和再次下载文件的大小不一样 也就是说此网站会截断文件 这对分析有很大的障碍

[qitry]

很抱歉：最近在重写网站UI 一直没更新后端

其次我看到您的描述和本工具的初衷偏了
工具确实是简化了日志分享流程
但我希望HMCL内置此工具是因为目前网络上存在大量在游戏崩溃之后，错误地将崩溃窗口截图发送到如QQ群的人，实际上我最开始的想法是在崩溃窗口基于LogShare显示简短的日志链接 这样即使用户只截图了崩溃窗口也能发送出日志，但楼上提供了一个更好的解决方案：二维码

至于文件截断、日志重命名则是技术债务
关于日志截断：我此次前端重构优化了日志渲染性能，截断会在后续更新中恢复至25000行。
日志重命名是因为我们使用MongoDB数据库，文件名没有单独做索引以保存文件名。
关于压缩包被分为多个链接，我们目前的解决方法是首页新增了批量复制功能，后续更新我可能会制作你说的功能。

同时网站有一个我个人认为非常重要的功能 如果直接分享日志文件，玩家uuid、IP地址、目录等信息都可能泄露 而网站提供了日志预处理，可以针对隐私信息脱敏。

[DeliciousBread481]

我觉得降低解决报错的门槛可能不是好事

1.现在有不少AI大模型可供国内用户使用（如Deepseek，Kimi，豆包，千问等） 但是大众AI来解决MC报错 让它提供解决方案的准确率并不高
2.那么按照以上的逻辑背景下 当用户更便利地使用此分享功能时 那么也更容易让某些“好为人师”的人使用AI来给别人解答 这样会让误会or麻烦的情况出现的概率大大增加
3.关于：

但我希望HMCL内置此工具是因为目前网络上存在大量在游戏崩溃之后，错误地将崩溃窗口截图发送到如QQ群的人，实际上我最开始的想法是在崩溃窗口基于LogShare显示简短的日志链接 这样即使用户只截图了崩溃窗口也能发送出日志

那么你的初衷是让启动器自动上传网站并生成链接 然后在崩溃弹窗展示吗？
我不明白为什么当启动器明确说明了：

游戏崩溃后在崩溃界面点左下角「导出游戏崩溃信息」（不要点「日志」），然后把导出的压缩包整个发上来

那么用户首先不按照要求来做 这是用户的过错对吧 你的想法是：让用户不仔细看描述的情况下 发送弹窗截图 这样别人也能获取到文件
那....问题依旧是问题 用户不仔细阅读的错误只是被掩盖了罢 如果不加以纠正的话
那么用户对于给出的解决方案也会不看仔细 从而浪费双方时间 不是吗？

如果你只是给出一个将文件手动可选导出为链接形式的功能我没有太大意见 但是你说此工具的初衷不是这个 如果要满足你初衷的功能 我认为这并不是利大于弊的
4.关于日志截断的问题：

我此次前端重构优化了日志渲染性能，截断会在后续更新中恢复至25000行。

你的意思是日志还是会在浏览器里的25000行截断？可是我并没有提关于浏览器内浏览截断的问题

而且此网站上传文件的大小和再次下载文件的大小不一样 也就是说此网站会截断文件 这对分析有很大的障碍

我提出的问题是下载下来的日志文件和原文件不一样 我根本不使用浏览器内的浏览功能 也就是说你的上传/下载/存储有大小限制 这和「渲染性能」无关吧

以及截断 你想的是从第1行到第25000行保留 后面的一律截断？我比较怀疑你对MC报错解决的熟悉 因为大多数情况都是结尾和开头的信息最重要 如果你采用「从第1行到第25000行保留 后面的一律截断」的方式的话 这依旧会对报错解决有障碍