对 Koishi 的误解合集 / Koishi ド偏見 bot

好久不见,我是 Koishi ド偏見 bot。这是《Koishi ド偏見 bot》系列第二弹,不定期更新。

这次我们来盘点一下形形色色的群友对 Koishi 产生的各种误解;绝大多数误解在 308 中已有提到,但也有一些和 308 无关的误解。接下来就由我给大家一一分析。

快速导航:

1 个赞

那么,开始的开始,自然要先请出最负盛名的 308/2——

「这段日志 Koishi 绝对没有。」

这位群友在使用外置 go-cqhttp 的过程中发现了奇妙的报错,而 Koishi 的日志中并没有出现这样的报错,由此得出了「Koishi 的日志显示不全」的结论。

这位小伙伴自己的配置文件有误,因此日志中出现了报错。Koishi 自动生成的配置文件正确无误,因此没有报错。

感想:日志多并不一定代表方向正确,判断自己操作是否正确还是要根据资料判断当前步骤是否真正生效。

1 个赞

接下来,是 308 一系列规则中被触碰最多的——

「相比起其他方式,Docker 更易于使用。」

据粗略统计,308 所有规则中触碰 Docker 的人次比其他所有规则触碰的人次加起来还要多许多。容器化带来的几乎不可动摇的稳定性和可复现性吸引着一批又一批的群友们安装和尝试 Docker 中的 Koishi。不过——

真相 1:有相当比例的 Docker 用户不知道如何做到以下几件事:

  1. 在容器启动后获取容器内的文件。
  2. 在容器无法启动时修改容器内的文件。
  3. 在容器反复重启时拿到容器上一次启动失败的日志。
  4. 在容器运行时在容器内安装其他软件包。
  5. 使容器中的 Koishi 访问容器外的服务。

真相 2:Docker 在 Windows 和 macOS 上均会预先启动一个 4G 内存的虚拟机,并在后台持续运行。在 Windows 上,根据容器引擎的模式,Docker 的资源占用有概率不在任务管理器中显示。

感想:前段时间有群友在群内询问「我的内存为什么不够用了」,经过群友分析后发现他的所有进程只占了内存的很少部分空间,而使用内存却几乎占满。那么,究竟是什么原因呢?

2 个赞

可以直接翻到下面的部分。

1 个赞

「设备信息页面只包含设备文件,因此无法实现配置迁移。」

该误解实际上是因为 gocqhttp 插件的按钮描述误导所致。「设备信息」按钮在此处指代「设备的所有信息」,而非仅 device.json

设备信息可以实现配置迁移。

虽然绝大多数人都没有使用过这个功能,但 qdvc 同时具有 device.jsonsession.token 的托管功能。使用设备信息页面和 qdvc 实现配置迁移是没有问题的。


更新:

1 个赞

接下来是和魔改相关的问题:

「要想卸载插件,只需要将对应的 koishi-plugin 文件夹删除即可。」

这个误解的产生也非常自然,因为世界上除了 Node 以外,其他框架的单个依赖项大多数都是置于单个文件或文件夹内。然而 Node 并非如此,美少女客服也曾在群内多次强调——

Koishi 的插件并非单个文件或文件夹,而是会有很多不同的位置。

具体信息可以参考下面的帖子:

特别地,只删除对应的插件文件夹一般并不会对 Koishi 的运行造成影响。但这仍然会导致你进入 308。

2 个赞

可以直接翻到下面的部分。

1 个赞

可以直接翻到下面的部分。

1 个赞

很害怕,但是我还是问一下 :cry:

我之前报登录提示 Code: 45,尝试先自己解决问题,猜想是设备问题。我并没有修改device.json,而是删掉了。然后重新启动gocqhttp,重新自动生成了一个新的device.json,然后登录成功,请问这样算是怎么一回事。

2 个赞

这不是生成了一个全新的设备吗,然后成功了 是好事啊

旧的设备信息报 Code45 说明是设备连坐,删掉生成新设备是正确的做法

2 个赞

PS 目前「设备信息」已经改成「登录信息」了

2 个赞

可以直接翻到下面的部分。

1 个赞

最近不知道怎么着又有各种奇怪的问题被提出,这里吱一声。
image

「我从koishi文档下载的koishi最新版本还是x.xx,可是最新版的koishi已经是x.xx,安装包没有跟上koishi的更新」

“我从文档下载下来安装的koishi版本是4.13.9,我要怎么更新4.14”
“为什么我下载的koishi是0.xx.x而不是和你们一样的4.x.x”
image

从官网下载的是Koishi Desktop,而非Koishi框架。

koishi Desktop,简单的说,可以粗暴理解为koishi的GUI,koishi Desktop通过可视化的面板,大幅降低了koishi框架的使用难度,并且可以在系统上实现更多事件。koishi Desktop自行完成了koishi框架所需的各种准备,例如nodejs等运行环境。
如同mirai的mcl一键启动脚本
image
当我们打开koishi时,我们实际上运行的是koishi Desktop。然后Desktop启动了koishi框架。

koishi≠koishi Desktop

koishi框架每当有特性更新时,都会在官方发布板块发布新内容。

当你需要用到这些新特性时,你只需要在koishi Desktop左侧边栏中依赖管理中找到koishi就可以直接更新体验到。目前更新到4.14.0


koishi Desktop可以直接在文档中下载到最新的版本。更新也是从此处直接下载最新安装包覆盖安装,仅koishi Desktop需要以此种方式更新,其他插件均可以用更新koishi的方式更新。

koishi Desktop通常不会更新,更新通常是增加了十分有趣的功能,亦或者为了解决插件冲突,亦或者整合最新、最稳定的全套官方插件。你可以通过右上角的全部更新或自行更新将插件更新到前沿、更稳定,或是在测试中的不稳定版本。目前更新到0.10.6

7 个赞