hundun000 发布的帖子

@moeik 其他问题我就不懂了，等其他人解答吧。我自己也不是很熟悉这个插件的具体逻辑，只是第一个问题报错显示是关于配置文件格式的，我就提出来。

看起来是config/MiraiApiHttp/setting.yml写得不对，贴这个文件内容出来看看

@rickyliyiqi 新版发布在github了

@rickyliyiqi 嗯，所有由插件写出的文件，都会报错。

我看到代码里的具体原因了。不是忘设置了，是我以为只需要关注ObjectMapper，而jsonString.getBytes()时没指定编码。

晚点我改了更新一版。

@rickyliyiqi 问下你那的“整点报时”功能正常吗？
因为整点报时读取配置时也是相同实现，ObjectMapper反序列化HourlyChatConfig.json，里面也有中文。

@rickyliyiqi
你的WeiboUserInfoCacheRepository.json看起来正常。这就怪了，我自己不论是在windows上测试，还是长期运行在linux上的，也是同样的订阅内容，都没有这个问题。

以下求助万能的坛友：

1. 上述的报错结合读取的文件来看，TopCardInfoRepository.json [Source: (File); line: 7, column: 28] 和 WeiboUserInfoCacheRepository.json[Source: (File); line: 4, column: 26] 都恰好是“泰拉记事社”的社和"之间，我想不到为什么这个位置会出现“Invalid UTF-8 start byte 0xbc”。

2. TopCardInfoRepository和WeiboUserInfoCacheRepository这两个类，序列化和反序列化都是使用同一个com.fasterxml.jackson.databind.ObjectMapper实例，该ObjectMapper实例应该是使用默认的utf-8编码，现在序列化时正常，反序列化出错，有什么可能的原因吗？

@rickyliyiqi 发下这个文件的内容，我看看
data/hundun.fleet.amiya/WeiboFunction/repositories/WeiboUserInfoCacheRepository.json

@rickyliyiqi

使用说明里写漏了，晚点补上。

【指令】更新订阅数据

第一次启用该插件，或修改WeiboConfig.json添加了新的微博uid后需要执行一次。在miral-console内执行该指令即可。

特别的，该指令只有第一套的格式：

-> /阿米娅WeiboFunction 刷新微博订阅
<- 已刷新

@amlisa

提供下更完整的报错日志？

另外本ZacaFleetBot已不再维护。其中阿米娅有关功能已迁移至独立的阿米娅插件，建议使用后者。

简介

插件功能：使bot扮演角色阿米娅，作为《明日方舟》游戏助手作为和群员的玩耍对象。

下载

项目地址

功能说明

功能基础说明。对于本插件，文档中的<角色名>代入为阿米娅。

• 微博推送
• 报时与提醒
• midi生成
• 阿米娅闲聊
• 阿米娅画图
• 复读、立刻聊天
• 帮助
• 权限管理

你想要的功能对应这个issue把，还是待开发状态
https://github.com/mamoe/mirai-console/issues/352

Him188 created this issue in mamoe/mirai-console

open 为 CompositeCommand.SubCommand 增加 secondaryNames #1813

贴一下该设计在mirai-fleet-prinzeugen插件实际使用的例子。'hundun.fleet.prinzeugen.cos:INSTANCE'对应本帖讨论的自定义权限。

授权后的config/Console/PermissionService.yml内容示例：

grantedPermissionMap:
'hundun.fleet.prinzeugen:*': # 常规Command权限
- 'm111111.*' # 允许111111群的任意群员使用本插件的所有Command
'hundun.fleet.prinzeugen.cos:INSTANCE': # 特殊权限，表示本插件(Event功能和定时器功能)的开关
- m111111.222222 # bot账号222222在群1111111启用本插件

注册特殊权限(源码简化后展示)：

// on init
Permission characterCosPermission = registerCosPermission();

protected Permission registerCosPermission() {
        String newHost = "hundun.fleet.prinzeugen.cos";
        String newName = "INSTANCE";
        Permission newParent = Permission.getRootPermission();
        try {
            return PermissionService.Companion.getInstance().register(
                    new PermissionId(newHost, newName), 
                    "略", 
                    newParent
                    );
        } catch (PermissionRegistryConflictException e) {
            plugin.getLogger().error(e);
            return null;
        }
    }

检查特殊权限(源码简化后展示)：

protected boolean checkCosPermission(Bot bot, Group group) {
        Permission targetPermission = characterCosPermission;
        ExactMember exactGroup = new ExactMember(group.getId(), bot.getId());
        return PermissionService.testPermission(targetPermission, exactGroup);
    }

快进到要求mirai框架每分钟广播一个ClockEvent

忙完重构，准备加新功能，结果发现好像并没有什么游戏辅助信息是需要用bot查的。你游有专用浏览器，浏览器内的插件直接提供了游戏需要的各种辅助功能。该转行开发poi插件了

这欧根在群里，只图一乐，群员最喜欢就是噗噗闲聊。

关于拆分

本插件在设计之初就已经考虑过，“明日方舟游戏助手+舰队收藏游戏助手+More”这样打包多个游戏助手在一个插件，不太合适。（见架构设计：抽离出“纯bot逻辑”？）

按照计划，会新建两个独立的明日方舟插件和舰队collection插件，尽量还原地把本项目的对应功能迁移到对应新插件。未来的新功能会优先/仅加在新插件。应该会把主要精力放在舰队collection插件，因为已有他人开发的更多功能的明日方舟插件。

目前独立的舰队collection插件已发布。

技术实现细节

在本项目基础上抽离出了名为fleet的自创框架，新插件基于此框架开发。fleet框架里包括名为Function的功能组成单元，可被基于该框架的插件复用。例如，明日方舟插件和舰队collection插件将会复用WeiboFunction。（有关复用功能组成单元的讨论）

fleet框架对比本插件的优化：

• 不再需要mongoDB：持久化数据直接读写文本文件
• 不再基于Spring：缩小了插件体积，避免Spring与插件体系对接的问题
• 加强联动console：使用MiraiConsole意义上的指令，使用MiraiConsole权限系统管理

使用

插件功能：使bot扮演角色欧根，作为舰队collection游戏助手。

• 推送微博： 艦colle鎮守府情報（可配置）
• 事项提醒： 整点报时（可配置）
• 舰娘百科查询： 舰娘信息（舰娘百科网页链接、改造链、初始装备……）
• 闲聊

下载

更多说明见项目地址

前身

欧根，前身是ZacaFleetBot插件里的角色之一，经历了近代化改造，现在单独作为舰队collection助手插件。

改造的重点内容：

• 不再需要mongoDB：持久化数据直接读写文本文件
• 不再基于Spring：缩小了插件体积，避免Spring与插件体系对接的问题
• 加强联动console：使用MiraiConsole意义上的指令，使用MiraiConsole权限系统管理

未来增加更多舰队collection相关的功能，会优先/仅加在本插件。

@pigeoner 参考论坛里专门讨论这类问题的帖子吧

@karlatemp 多谢，用起来了

一般性的，一个插件除了Command为入口的功能，还可能包括其他途径触发的功能：

• Event为入口的功能
• 由定时器触发的功能

这些其他途径触发的功能，如果需要做权限控制，或者说服务开关控制，一个方案是自行实现配置文件。如屏蔽消息的思路提到的关闭EventHandler对某个群的服务：

// onGroupMessage(GroupMessageEvent event)
if(this.main.getConfig().isBlackList(sender.getSenderID())) {
  return;
}
// do sth

以及关闭定时器对某个群的服务：

// on MyTimer run()
bot.getGroups().foreach(group -> {
  if(timerConfig.isBlackList(group .getID())) {
    return;
  }
  // do sth
})

该方案的缺点是需要自行实现和维护多个XXXConfig，需要在文档多个地方说明，增加一个群时涉及多个配置文件……

故考虑复用Permissions系统，用PermissionId对应EventHandler/Timer的开关，拥有权限则表示启用服务。这样把插件内所有的功能的权限控制/开关，都统一交给Permissions系统,用一份配置文件管理，可动态授权……

// on init
val PERMISSION_A = PermissionService.INSTANCE.register(permissionId("eventHandlerA"), "对应eventHandlerA开关");
val PERMISSION_B = PermissionService.INSTANCE.register(permissionId("timerB"), "对应timerB开关");

则PermissionService.yml会形如：

grantedPermissionMap: 
  'myPlugin:eventHandlerA': 
    - 'g111111' # 表示只有111111群的群员可以使用eventHandlerA
  'myPlugin:timerB': 
    - 'g222222' # timerB只定时服务222222群

EventHandler的判断变为：

// onGroupMessage(GroupMessageEvent event)
Permittee permittee  = permitteeFromGroupId(event.getGroupId());
if(!permittee.hasPermission(PERMISSION_A) return;
// do sth

Timer的判断改变为：

// on MyTimer run()
bot.getGroups().foreach(group -> {
  Permittee permittee  = permitteeFromGroupId(group .getID());
  if(!permittee.hasPermission(PERMISSION_B) return;
  // do sth
})

目前的问题是：如何实现permitteeFromGroupId()，重点是返回哪个permittee子类？
Command为入口已经有了CommandSender；我倾向于Event为入口，由Timer触发也分别有平级的一支子类，然而console文档指出注意：请不要自主实现 Permittee。虽然可以让他们也构造某个CommandSender子类，但毕竟这样的调用确实不是
来自command，希望能有更合适的方式实现。

@hundun000 在 gradle加载mirai速度怎么这么慢,每次进idea都要等半天,有什么办法提高速度嘛 中说：

刚刚试了下加上这行，刷新gradle时还是会尝试一遍从dl.bintray.com下载，怎么回事?

没事了，是我workspace有好几个插件工程，那些工程还没这行