Anstiya 发布的帖子

@rubyhikato 任何你能用的传文件方式，网盘，qq。
以及我需要明确你的需求是什么，是不是希望在群聊开放的同时限制私聊只给你的授权用户，还是想把所有的都限制了只给你的授权用户。
昨天更新的main2.exe理应已经能满足上面两个需求了，但按你说的依然不行，那就得拿到你的所有文件看看是哪里的问题。

@rubyhikato ？完整配置文件和截图。最好能把整个文件夹打包发给我。

@rubyhikato 我刚上传了临时修复 可以下载这个试试看，仅替换main2.exe

@rubyhikato

glmReply: true
friendRep: false
privateGlmReply: true

如前所述，只要glmReply为True，群聊和私聊都将对所有人开放，这是个冗余设计，周末将移除。之后才能实现，私聊仅对授权用户开放。

glmReply: false
friendRep: false
privateGlmReply: true

授权群无论在任何情况下都可以触发，glmReply: false
friendRep: false为false的时候意味着群聊和私聊都关闭，同时信任用户全局可用。并没有问题。

glmReply: false
falsefriendRep: true
privateGlmReply: true

意味着群聊关闭，私聊全面开放，同时信任用户全局可用。这里也没有问题。

因此问题不变，还是我之前说的，私聊触发中只要glmReply为True就一定会触发的问题。周末更新移除就能实现你的需求。目前主要工作是调整项目的新UI，等新版UI做好一块更新

@v1kt0r firefly调用的是抓包的api，目前来看，原本的url失效被重定向到了新的网址，基于原有抓包的模拟请求不适用于新的网站，这个模式暂时不能用了。
周末我试试抓一下新网站

@rubyhikato 这里的判断逻辑很简单
群聊内 glmReply为True 或 trustglmReply为true且用户为信任用户 或 群在授权群内
在满足了以上三种任一情况，必然可以触发，如果还不行那我也不知道了。

私聊的逻辑则是 glmReply == True 或 trustglmReply为true且用户为信任用户 或 friendRep为True
前面说了这个glmReply是冗余的，并且它的存在导致了不能在开放群聊的同时限制私聊，这将在周末更新中修复。

如果你满足了以上触发条件并且仍然无法正常触发，我的建议是，把你现在整个文件夹压缩打包给我。

@rubyhikato 这样的话，问题就在于overflow没能对这两种消息来源进行区分，解决这一问题最好从overflow入手，因为对Petunia主程序来说，它只知道overflow传递过来的数据都是FrinedMessage，无法分辨它们的来源是正常私聊还是频道。
目前我不清楚频道消息转换成的FriendMessage是什么样，等周末看看，如果能区分的话我尽量区分。
如果按你说的，频道来源的friend id都是0的话，那就好办了，我只需要加一个判断即可。

@loyu 刚传了个临时修复版本，覆盖原先的main2.exe即可。
因为是临时传的，没有做充分测试，最好还是把原先的main2.exe先放一边备份，如果新的不能用就把旧的换回来。

@rubyhikato QQ频道？

@loyu 它拿不到你的nickname，即用户名，不清楚原因。等周五我抽空处理。

@rubyhikato 目前的设定是，当glmReply和friendRep都为false，trustglmReply为true时仅信任用户可用(私聊和群聊都是)。
我能否把你的需求理解为，希望能在群内保持聊天开放，私聊仅对信任用户开放。
如果我的理解正确，目前的版本无法实现，因为friendRep是临时加入的开关，没有考虑到这样的需求，glmReply或friendRep为true时，无论是否是信任用户，都将被视为开放了私聊，而进入聊天。
要实现这一需求需要等下一版本，我周末应该有空。

@loyu 确保已安装mirai-api-http 并正确配置 ，如不确定直接下载我的配置文件覆盖。
检查settings.yaml中，bot配置。
botqq必须是你已经登录overflow/mirai的botqq，确保botqq正确。
http-api-key是mirai-api-http设置的key，port是mirai-api-http中配置的ws的port，而不是http。
如果使用我给出的配置文件，就不要动http-api-key和http-api-port。

@Chaluo
/clear
修改设定后，需要清除先前对话记录，并且重启启动器。
另外，不推荐指定免费模型，免费模型大多不稳定。你可以在random模式下，将grop模型的优先级提前。

你的配置存在的另一个问题是，狐妖_ZH 这一speaker是中文speaker，但是语言类型却是 <jp> ，可能导致ai回复时调用语音合成出现问题。

@SiinaYuki 我测试正常。
留空会自动用默认cookie，那个cookie用好几个月了没啥事；至于你说的不显示cookie，等我晚上看看。

修复日文语音翻译失效问题
Gemini-1.0pro升级为Gemini-1.5flash(无需修改配置文件，默认升级)

更新星铁查询功能

@rubyhikato 嗯，刚想了想这里应该是个bug，如果你在【处理冲突】后，没有重启启动器，一旦进行了配置修改操作，写入settings.yaml就仍然是启动时加载的那个旧的settings.yaml。
下个版本修复这一问题，目前的解决方法只能是【处理冲突】后重新启动【启动器】。

@rubyhikato
截图中的这个配置文件注释仍然是旧的，成功【处理冲突】后注释会随之更新，可能此前没有更新成功。
建议重新下载0.6.2，并解压，将旧的settings.yaml放入(新下载的0.6.2的)oldConfig文件夹并执行处理冲突。

旧的注释有很多过时了，比如outVits语音合成功能已被弃用，可能影响使用。

@rubyhikato 图中缺少了

  FriendMesVoiceRate: 60        #私聊语音几率

这一配置项，可手动添加。

配置文件如下

chatGLM:
  model: random  
  .......省略中间部分.......
  voiceGenerateSource: firefly  #可选modelscopeTTS和firefly
  maxLen: 70                    #语音合成最大长度限制，超出则返回文本。
  voiceRate: 60                 #语音回复几率,为0则不开启
  FriendMesVoiceRate: 60        #私聊语音几率

@rubyhikato 目前猜测原因是配置文件的语音设置部分。
0.61的settings.yaml无法直接用于0.62的启动器，必须经过【处理冲突】后才能使用。
完整的0.62配置文件与0.61相比多了
私聊语音设置的配置项。
如果直接将0.61的settings.yaml用于0.62的启动器，将导致

TypeError: ‘＜‘ not supported between instances of ‘NoneType‘ and ‘int‘

发生