open-pics是一个随机发送本地文件图片的插件，支持本地图源
假设我在本地的某个文件夹收藏了很多很nice的图片，想把他分享给群友。
在 imagePath一栏，填入你涩涩图片所在的路径：
我在D:/img/xp文件夹 这里存了11张伊内丝的图片，我们看看效果：
指令是xp
非常完美！
在插件开发过程中，开发群的大佬对我提供了很多有用的建议，特此鸣谢！
以下昵称来自开发群的群名称
感谢s4a （梦梦）
以及风佬、42、苜蓿…
还有其他很多很多人，这里就不一一列出了，感谢你们提供的帮助！
下一版本要不要加入对自建云端图源的支持呢 
这个插件是不是没有人用……
听起来很不错，想起来被尘封的pr社.rar
//
感觉不错，文件夹
有1024张图片，有时候调用会慢一点。
//是否可以后续优化
没事，这只会使我更卷
设置最大图片数量怎么样，如果文件夹内有1024张图片，但是是你设置最大图片数量为100的话，只会第在1∽100张图片里面循环
是否可以实现,读取全部数量只需要加载一次,后续在内存或者缓存里解决了.或者分文件夹分块随机,设2个随机数,第一个读取随机文件夹,第二个随机文件夹里的文件序号,这样也可以得到快速响应.
我平时用的nnhr的，但支持正义卷飞nnhr。
你可能需要做的：
大家都好热情…
指令中加人数量 option这个建议很好，会加入到未来的规划里面
修改随机像素需要图像库了，nodejs 没啥在 Koishi 好用的图像库。
能不能设置多个文件夹位置 实现 能让图片分类发送
图片很多觉得很慢的话可以在启动时扫一遍文件夹，并将图片建立一个 mapping（空间换时间大法）。
可以结合 hmr 插件做到运行时监听文件夹更改，实时更新这个 mapping.json。
二编：
且建立 mapping 的过程可以是异步的，建立完成后就可以得到更快的速度了。
mapping 的元数据可以有这么一些：
{
storeId: 'uuid', // 存储 id，可以为未来的多个文件夹做支持
count: 114, // 图片数量
images: ['/foo/bar/loli.jpg', ...] // 图片地址数组
...
}
// 如果想给图片加入更多功能，还可以是一个对象
{
...
images: [{
name: 'image name',
tags: ['loli', ...],
... // more data
path: ''
}, ...]
...
}
天才般的想法！
我怎么就没有想到
1.0.5版本更新后，支持随机多张图片
格式：xp n ，n为你单次随机的图片数量
以及加入了单次最大图片限制，防止被：xp 114514 炸掉群聊
可能存在的问题：
吞图情况：用户群有人反映，但我目前没有遇到过
大文件夹读取慢：比如一个文件夹有900张图片，读取起来就会很慢
1.1.0版本更新，这是一次了不起的更新，我在这里面加入了一个优质图源
插件预览：你可以选择是否发送原图（默认关闭）
并加入了r18检测（应该有用）
比如上面这张，虽然他有R-18标签，但是请相信 R18：false ，那就不是r18
https://i.pixiv.re/img-original/img/2022/09/21/00/00/24/101373014_p0.png
附图片：
注意！图片比较大，如果选择了发送图片选项，记得一定要修改发送消息时的超时时间，不然会因为超时而收不到图片！
了不起的更新，这下可以实现P站图片（尽管用的是api ）随机图片自由了
1.1.0到1.1.6版本的更新：
1.可以修改发送图片的尺寸，有原图、标准、和省流，默认为regular（标准）
2.为了防止社死，我在1.1.6以后的版本的加入了请求参数r18=0
3.优化了配置页面的外观
4.增加了新的可配置项：uid
效果：
附图片：
希望可以自定义是否发送r18
