好久不见,我是 Koishi ド偏見 bot。这是《Koishi ド偏見 bot》系列第二弹,不定期更新。
这次我们来盘点一下形形色色的群友对 Koishi 产生的各种误解;绝大多数误解在 308 中已有提到,但也有一些和 308 无关的误解。接下来就由我给大家一一分析。
快速导航:
好久不见,我是 Koishi ド偏見 bot。这是《Koishi ド偏見 bot》系列第二弹,不定期更新。
这次我们来盘点一下形形色色的群友对 Koishi 产生的各种误解;绝大多数误解在 308 中已有提到,但也有一些和 308 无关的误解。接下来就由我给大家一一分析。
快速导航:
那么,开始的开始,自然要先请出最负盛名的 308/2——
这位群友在使用外置 go-cqhttp 的过程中发现了奇妙的报错,而 Koishi 的日志中并没有出现这样的报错,由此得出了「Koishi 的日志显示不全」的结论。
感想:日志多并不一定代表方向正确,判断自己操作是否正确还是要根据资料判断当前步骤是否真正生效。
接下来,是 308 一系列规则中被触碰最多的——
据粗略统计,308 所有规则中触碰 Docker 的人次比其他所有规则触碰的人次加起来还要多许多。容器化带来的几乎不可动摇的稳定性和可复现性吸引着一批又一批的群友们安装和尝试 Docker 中的 Koishi。不过——
感想:前段时间有群友在群内询问「我的内存为什么不够用了」,经过群友分析后发现他的所有进程只占了内存的很少部分空间,而使用内存却几乎占满。那么,究竟是什么原因呢?
可以直接翻到下面的部分。
该误解实际上是因为 gocqhttp 插件的按钮描述误导所致。「设备信息」按钮在此处指代「设备的所有信息」,而非仅 device.json
。
虽然绝大多数人都没有使用过这个功能,但 qdvc 同时具有 device.json
和 session.token
的托管功能。使用设备信息页面和 qdvc 实现配置迁移是没有问题的。
更新:
接下来是和魔改相关的问题:
koishi-plugin
文件夹删除即可。」这个误解的产生也非常自然,因为世界上除了 Node 以外,其他框架的单个依赖项大多数都是置于单个文件或文件夹内。然而 Node 并非如此,美少女客服也曾在群内多次强调——
具体信息可以参考下面的帖子:
特别地,只删除对应的插件文件夹一般并不会对 Koishi 的运行造成影响。但这仍然会导致你进入 308。
可以直接翻到下面的部分。
很害怕,但是我还是问一下
我之前报登录提示 Code: 45,尝试先自己解决问题,猜想是设备问题。我并没有修改device.json
,而是删掉了。然后重新启动gocqhttp,重新自动生成了一个新的device.json
,然后登录成功,请问这样算是怎么一回事。
这不是生成了一个全新的设备吗,然后成功了 是好事啊
旧的设备信息报 Code45 说明是设备连坐,删掉生成新设备是正确的做法
PS 目前「设备信息」已经改成「登录信息」了
可以直接翻到下面的部分。
最近不知道怎么着又有各种奇怪的问题被提出,这里吱一声。
“我从文档下载下来安装的koishi版本是4.13.9,我要怎么更新4.14”
“为什么我下载的koishi是0.xx.x而不是和你们一样的4.x.x”
koishi Desktop,简单的说,可以粗暴理解为koishi的GUI,koishi Desktop通过可视化的面板,大幅降低了koishi框架的使用难度,并且可以在系统上实现更多事件。koishi Desktop自行完成了koishi框架所需的各种准备,例如nodejs等运行环境。
如同mirai的mcl一键启动脚本
当我们打开koishi时,我们实际上运行的是koishi Desktop。然后Desktop启动了koishi框架。
koishi框架每当有特性更新时,都会在官方发布板块发布新内容。
当你需要用到这些新特性时,你只需要在koishi Desktop左侧边栏中依赖管理中找到koishi就可以直接更新体验到。目前更新到4.14.0
koishi Desktop通常不会更新,更新通常是增加了十分有趣的功能,亦或者为了解决插件冲突,亦或者整合最新、最稳定的全套官方插件。你可以通过右上角的全部更新或自行更新将插件更新到前沿、更稳定,或是在测试中的不稳定版本。目前更新到0.10.6