AmberKeter 你可以搞个判断，没有OlivaDiceCore就用备用方案，当然前提是你有备用方案

AmberKeter
但是你前置插件里没写啊。

无言HideUsSaveUs 这就补上.jpg

2022.6.8更新日志：

• 追加更新内置用户系统
• 允许牌堆引用

想看看使用案例。

sfw2099 已录入需求，将在月底进行第一次案列书写。

大佬，青果三版能用么

封不语 啊？

关于更早的权限判断问题：
将于未来发布Level插件，以此代替OlivaDiceCore的Master判断，但OlivaDiceCore仍将会是主要方案之一

Favor编写手册

以下是标准Favor单元：

以下是标准配置文件：

注意：FavorChange字段可以直接定义为字符串，但将不会判断正负以选择不同回复。

以下是标准情况下Favor插件数据文件夹：

Favor单元说明：
2行的test指明何种关键词将触发本单元，格式为标准正则字符串。
3行的mode字段指明匹配格式，此处为私聊触发。
4行的cd字段指明冷却时间配置，第一个数字代表冷却的秒数，第二个字符串代表冷却未到的回复，第三个代表作用的范围，此处代表仅作用于common与favor回复，不限制special回复。如果仅需限制一个，可以使用字符串作为最后的元素。
5行的max字段指明一天最高次数上限，格式与cd类似。
6行的return指明返回内容，在无其他内容时默认为common模式，但必须确保回复单元不为dict（即被{}包裹的完整对象），形式如下：

7行的special字段定义指定用户回复，只有特定用户可以触发，特定用户组在9行的uid字段中定义，格式为标准UUID（8-4-4-4-12），获取自己的uid请使用*user info指令。
11行的favor字段定义好感区间回复，只有在好感区间内的用户可以触发，其中interval字段定义好感区间，可以直接指定一个整数，但不建议这么做。
好感区间的标准格式为[ left , right ]
好感区间实质上等同于闭区间，可以理解为由符合left ≤ x ≤ right的实数所构成的集合，当left/right为null时，代表-∞/+∞，即负/正无穷大。
14行的change定义好感变化区间，代表触发后用户的好感变化，同样为闭区间。
15行的cd定义冷却时长，在缺省情况下使用4行定义的默认配置（即4行列表的第一个元素）。
同时还有一个缺省的success字段，定义是否计入今日触发次数，默认为是。
你可能会注意到8、13、18-28行的reply字段不太一样，这是正常的，其代表回复语句的两种格式。
第一种，暴力回复。格式为字符串或元素均为字符串的列表，将不做额外处理直接回复。
第二种，精细回复。格式为元素均为dict（即被{}包裹的完整对象）的列表，此时回复将可以进行细化操作，如概率回复，不同回复产生不同效果等，在一定程度上简化书写。
以18-28行为例，19-24行定义了一个回复单元，25-27行也定义了一个回复单元。
在回复单元中，所有缺省的字段将使用上级设置的默认设置（如cd、success、change）
21行的weights定义该单元权重，默认为1。其定义该单元在总回复池内的个数，用于调节抽中概率。
20行的str定义最终回复，此时强制要求必须为字符串或元素均为字符串的列表。

以下是实际运行情况：

此时琥珀的favor为0，uid为57964ba1-4450-401a-b642-73fad0e6a0b9。
因此触发了common回复，但因为脸比较黑，好几次都没抽中加100的大包。

此时琥珀的favor已达到100，因此执行了favor回复，同时立刻再次触发，导致触发冷却，返回了冷却未到回复，等到冷却结束后再触发就又是正常的favor回复了。同时此处琥珀发现favor的回复没有改变好感，因此捉到了bug的虫脚。

标准范例文件：

favor.zip

735B

2022.8.29更新日志：

• 重修好感变化逻辑

AmberKeter 太可惜了

封不语 因为本身是在ovo3时代才开始写的插件，往前兼容需要的时间成本对我一个高三狗来说还是略高