tiehu
tiehu
Expected feature: The TOTK savegame editor can modify koroks seeds, visited locations, and defeated bosses in the game, and mark them as finished or mark locations on the in-game map,...
#故障表现： 使用bilibili/twitter -s uid获取动态时，bot回复“发生未知错误”，日志中出现报错（附在下方）。 #预期行为： bot正常返回动态图片。 #复现步骤： 1.打开kbot配置中的B站或推特订阅功能。 2.启用图片模式。 3.在沙箱/平台环境下使用bilibili/twitter -s uid获取动态 PS：复现概率似乎不是百分百，有时候能成功获取，有时候就会报错。 #相关日志： B站动态获取时报错如下： [W] app Error: property puppeteer is not registered, declare it as `inject` to suppress this...
### Describe the bug 在`4.17.7`更新到`4.17.8`时发现了一个相当奇怪的问题，这里附上我的详细操作过程便于诊断和复现（可能略长）： 在更新完成，重启Koishi之后从浏览器访问WEB控制台，此时发现页面完全卡死，表现为： 1.左侧活动栏只显示出不全的几个图标，有时是3个，有时是4个。 2.点击任何按钮皆无反应。 3.右下角一直显示正在加载页面组件，进度条卡住不动。 4.片刻后浏览器提示网页无响应。 5.此时bot本身功能正常，在聊天平台中有响应，只是WEB控制台无法访问。 6.**后台日志中的输出与平时启动时完全一致，无任何警告或错误信息。** 7.即使启动后等待相当长一段时间再访问控制台，此问题仍然会出现。 遂尝试重启Koishi、系统，皆无法解决问题。 随后回滚更新操作： 1.将项目目录下的`./data`、`./package.json`，`./koishi.yml`还原为更新前的状态。 2.使用`yarn && yarn start`重新获取依赖包并启动Koishi。 3.此时上述问题不再复现。 此后重启系统、重启Koishi后问题皆未出现，但再一次尝试更新到`4.17.8`后问题再次出现。这一系列操作已尝试过多次，在我的环境中复现率为**100%**。 接着，尝试使用`yarn dev`以开发模式启动Koishi，控制台的启动速度相较`4.17.7`略慢（日志中输出`console webui is available at http://x.x.x.x:xxx`后，需要等待一段时间后才能在浏览器中正常打开WEB控制台），但之后能够正常访问和使用。 再次更新至`4.17.8`，经多次试验，发现如果**在`package.json`的`scripts`中，给`start`加上`dev`里的`cross-env...
### Verify steps - [X] 我已经在 [Issue Tracker](……/) 中找过我要提出的请求 I have searched on the [issue tracker](……/) for a related feature request. - [X] 我已经仔细看过 [Documentation](https://wiki.metacubex.one/) 并无法找到这个功能 I have read the...
### Description A clear and concise description of what you want to happen. I'm not sure if this is the expected behavior of the program, but the program will pop...
### 功能描述： 考虑将koishi接入fail2ban，将多次尝试登录WEB管理界面失败的IP地址ban掉，因此希望koishi能在日志中记录失败的登陆尝试（目前登陆失败会输出一条`debug`级别的日志，但并不会记录IP），最好能为这个功能添加一个开关。 `auth`自身似乎目前也没有实现类似防止爆破的功能——诚然，在WEB暴露在公网环境下时，给`admin`账户设置强密码是一个良好的实践，但考虑到进入koishi控制台后，实际上是可以再通过安装`spawn`插件在服务器上执行终端命令的，多一重保险总是好的。 ### 替代方案： 就像上面提到的，也可以考虑由koishi自身来实现类似的功能，例如用户可以配置在WEB界面失败多少次尝试后禁止登陆（当然，最好是禁止IP而非禁止账号，否则遭遇爆破后用户自己也会被拦在外面），这样也可以顺带解决部分用户只配置了弱密码就把koishi暴露在公网所带来的安全隐患。
这个问题严格来说应该不算一个bug，但当在播放列表和封面浏览器中滚动时（尤其是后者）看起来不太流畅，主要体现为滚动时的帧数偏低（目测可能不到30帧）。 随后整了个简单的Python脚本来测试一下窗口的刷新率（通过检测窗口图像内容变化来估算刷新率，开始测试后不断滚动使窗口内容发生变化），发现封面浏览器滚动时的刷新率大概只有15帧左右：  播放列表则接近25帧：  但是在音乐可视化界面下则很流畅，刷新率测试出来是40帧左右。 我原本以为这是因为封面图片过多导致的，但是在尝试了把媒体库移动到SSD上、缩减媒体库内的专辑数量后情况仍未改善。且即使所有封面已经加载出来并且缓存了，此问题仍然存在。 个人是第一次接触foobar2000，对这方面不是很了解，但稍微看了一眼封面浏览器的面板代码，看起来`refreshRate`的默认值是`25`，也就是理论刷新率应该是在每秒40帧。硬件也没有特别差，不确定为什么实际刷新率这么低... 以下给出测试环境，个人感觉应该很容易复现： Windows 11 Pro x64 foobar v2.24.5 汉化版（By Asion） foobox-cn 8.3 媒体库约100张专辑，总乐曲数2500+（测试时已经尝试过缩减媒体库内的专辑数量）
### Minecraft Version - [ ] 1.12.2 (End of support) - [ ] 1.16.5 (End of support) - [ ] 1.18.2 (End of support) - [ ] 1.19.2 (End of...
After logging into my Microsoft account using the `login` command (via the browser link https://www.microsoft.com/link?otc=...), the login consistently fails every 3 days (very precisely, always 3 days apart) with the...