肉鸽辅助协议
提示
请注意 JSON 文件是不支持注释的，文本中的注释仅用于演示，请勿直接复制使用
肉鸽资源存放位置
resource/roguelike/下按照主题存放各个肉鸽的作业资源- 主题文件夹：
Phantom/为傀影肉鸽资源，Mizuki/为水月肉鸽资源,Sami/为萨米肉鸽资源，Sarkaz/为萨卡兹肉鸽资源，JieGarden/为界园肉鸽资源，BlackFlow/为黑流树海肉鸽资源autopilot/内是各个关卡的作战 json关卡名.json关卡的作战逻辑
encounter/内是不期而遇类（所有非战斗和商店节点）事件逻辑default.json刷等级模式deposit.json刷源石锭模式
recruitment.json干员招募逻辑shopping.json商店购买藏品逻辑
- 主题文件夹：
特别地，在
Sami/下的foldartal.json表示萨米肉鸽密文板的使用逻辑collapsal_paradigms.json表示萨米肉鸽坍缩范式的类型autopilot/关卡名_collapse.json关卡的作战逻辑（刷坍缩范式模式）encounter/collapse.json刷坍缩范式模式不期而遇逻辑
在
Sarkaz/下的fragments.json存储了萨卡兹肉鸽思绪的基本信息map.json存储了萨卡兹肉鸽蓝图过图的模板图片信息
在
JieGarden/下的coppers.json通宝的基本信息与拾取替换逻辑map.json存储了界园肉鸽地图节点的模板图片信息
在
BlackFlow/下的strategy.json黑流树海肉鸽的高层路由策略配置node_execution.json黑流树海肉鸽的节点类型处理路由配置map_perception/黑流树海肉鸽的地图感知视觉资源scrap_market.json黑流树海肉鸽的秘境行商数据（闲置自然物的价目、刷新费用与培育保留上限）map_templates.json黑流树海肉鸽的地图布局模板
肉鸽第一步——干员招募
resource/roguelike/主题名/recruitment.json 描述了干员招募的逻辑 在 tools/RoguelikeRecruitmentTool 和 tools/RoguelikeOperSearch 中有辅助工具来帮助查看和编写
{
"theme": "Phantom", //肉鸽主题（这里是傀影）
"priority": [ //群组的优先度，有序
...
],
"team_complete_condition": [ //阵容完备度检测
...
]
}干员分类
按照你的游戏理解将干员分成不同的 groups （群组，相关概念参考 战斗流程协议）
注意
同一 group 内的干员和召唤物必须部署方式一致（即同为近战或者同为高台），攻击范围尽量相同
允许同一干员或者召唤物根据用法不同，被分类至不同的 group
请不要修改已经存在的 group 名称，以免在 MAA 更新时导致之前版本的作业无法使用
请尽量不要新增 group，尽量将新添加进作业的单位按照用法纳入已经存在的 group
提示
默认仅招募精 1 55 级以上等级干员
{
"theme": "Phantom",
"priority": [ // 群组，有序
{
"name": "棘刺", // 群组名（这个群组名是棘刺）
"opers": [ // 群组包含的干员，有序，代表部署这一组干员时的部署优先度，
// （比如需要部署该组干员时，先检测有没有棘刺，有棘刺就部署棘刺，没有棘刺再检测有没有号角）
{
"name": "棘刺", // 干员名
...
},
{
"name": "号角",
...
}
]
},
"team_complete_condition": [
...
]
]
}已有群组介绍
以萨米肉鸽的作业为例：主要将干员分为了
分组 主要考量 主要包括职业 举例干员 地面阻挡 站场和清杂 重装、近卫 奶盾、基石、羽毛笔、山、M3、令和稀音的召唤物、斑点、重装预备干员 地面单切/处决者 单独对战精英怪 处决者特种 史尔特尔、异德、麒麟 R 夜刀、M3、红 高台 C 常态和决战输出 狙击、术士 维什戴尔、逻各斯、假日威龙陈、澄闪 高台输出 对空和常态输出 狙击、术士 空弦、能天使、克洛丝、史都华德 速狙 物理输出，标准射程 狙击 艾拉、能天使、跃跃、克洛丝 术师 法术输出，标准射程 单法 艾雅法拉、逻各斯、史都华德 辅助 可以打到身后 1 格 辅助 塑心、铃兰、跃跃、梓兰 狙击 射程较远的高台 投掷手、攻城手 维什戴尔、提丰、早露 奶 治疗能力 治疗、辅助 凯尔希、浊心斯卡蒂、芙蓉、安赛尔 单奶 攻击范围纵深>=4 治疗 凯尔希、焰影苇草、纯烬艾雅法拉、芙蓉、安赛尔 群奶 攻击范围纵深<4,可以奶身后 治疗、辅助 夜莺、白面鸮、浊心斯卡蒂 回费 回复 cost 先锋 桃金娘、伊内丝、芬、香草 地刺 无阻挡，在盾前提供输出或者减速 伏击客 归溟幽灵鲨、阿斯卡纶、狮蝎 地面远程 地面长手，可以在盾后输出 教官、领主 号角、帕拉斯、棘刺、银灰 领主 地面攻击范围纵深>4，可对空 要塞、领主 棘刺、银灰、仇白 盾法 攻击范围短，有一定承伤能力 阵法术师 林、卡涅利安 炮灰 吸收炮弹、再部署 特种、召唤物 M3、红、桃金娘、预备干员 大龙 盾前承伤、紧靠阻挡方便合体 召唤物 令的小龙、涤火杰西卡的盾牌 补给站 给主 c 干员加快回转 召唤物 支援补给站、工匠类干员的召唤物 无人机 无视高台地面的治疗召唤物 召唤物 斯卡蒂的海嗣、赫默的无人机 支援陷阱 部署在地面的爆炸物 召唤物 支援雾机、支援轰隆隆 障碍物 不吃部署位吸引仇恨或者阻挡 召唤物 鸟笼、障碍物 其他地面 不希望被优先使用的地面 推拉、挡 1 先锋、剑豪 风笛、可颂 高台预备/其他高台 不希望被优先使用的高台 群法、链法、战术家 梓兰、预备干员 提示
地面阻挡主要考量干员防守的综合能力（有时候全杀了也是防守强的表现对吧），包括地面远程和领主组
奶主要考虑综合治疗能力，包括单奶和群奶，需要考虑攻击范围覆盖时要单独使用单奶（奶 4 格）或者群奶（奶身后）
高台输出只考虑输出能力，主要是狙击和术师职业的混杂排序，需要考虑输出类型、攻击范围等限制条件时单独使用速狙、术师、辅助、盾法
夹子类召唤物因为数量较多，不要放在支援陷阱中，让 maa 自动部署效果比较好
需要特殊操作的群组
除了上面那些比较笼统的分组，我们有时候需要对一些干员或者干员种类进行一些定制的精细化操作，比如
分组 包括干员 主要特点 益达 维什戴尔 高台输出，优先部署可以减轻压力 棘刺 棘刺、号角 地面远程输出，傀影肉鸽有些图有非常适配的位置 召唤类 凯尔希、令、稀音 自带地面阻挡，有的图需要优先部署，召唤物可以当阻挡也可以当炮灰 情报官 晓歌、伊内丝 既可以回费、又可以侧面输出、还可以单切 浊心斯卡蒂 浊心斯卡蒂 低压时奶量尚可，但是范围特殊，一些图有比较适配的位置 焰苇 焰影苇草 萨米肉鸽常用开局干员,兼具治疗和输出，一些图有比较适配的位置 玛恩纳 玛恩纳、银灰 地面大范围决战输出，可以针对 boss 进行部署 史尔特尔 史尔特尔 由于精二后固定携带 3 技能，这时站场能力几乎为零，需要阻挡位的部署优先度极低 骰子 骰子 水月肉鸽中的骰子需要单独操作
注意
目前固定将未识别到的地面干员归入倒数第二个编组后面（其他地面），未识别到的高台干员归入倒数第一个编组后面（其他高台）
提示
新实装的干员需要手动加入各个肉鸽的 recruitment.json，而开发者不一定能想起来要做适配 如果你发现了的话可以发 issue 提醒开发者，也可以直接进行 pr
预设阵容——阵容完备检测
在你预计能够通关或者打到高层的队伍中，哪些干员属于基本核心阵容？是比不可少的？又需要几个?
注意
目前脚本的招募逻辑是在阵容未满足阵容完备度之前，只招募 0 希望（暂时只有三星）和 key（可以理解为白名单）干员，存希望给高星 key 干员 （目前的实现方式是给高强度干员和三星干员手动标为 key 干员，招募的时候只招 key 干员）（TODO: 识别 0 希望干员）
所以需要尽量让完备度总数合适，建议所有需要的干员数量（基本核心阵容，一般是 1 核心，2 地面，1-2 奶，1 高台）加起来在 4-8 位
在队伍满足阵容完备度检测之后，每次拿到招募券会按照干员的评分和精二优先度进行招募，所以为了避免希望浪费，不希望招募的干员可以不设置评分或者设置在同职业三星/预备队员评分以下 （对于一定要和完全不想要的干员，可以特殊地赋予极高和极低的分数，详见 Sami 中的 止颂 ）
作战编队时会先对干员选择界面的默认排序（从上到下、从左到右）进行有序读取和存储 基于这个顺序，保持相对顺序地将最先出现的满足阵容完备度的干员提到开头，直到阵容完备度被全部满足或不存在满足阵容完备度的干员 然后将预备干员移至最末，形成新的顺序，按照新的顺序进行选择 特别地，由于六星临时招募干员在编队时默认位于最开头，所以实际编队中很容易编入六星临时招募干员（TODO：排除无法使用的精一临时招募干员）
对于萌新号：在 10 次招募没有满足半队 key 干员的情况下，会放弃完备度检测，按照评分有啥用啥，所以没练三星的萌新号会出现只拿了两三个六星，剩下拿了一堆预备干员的情况
{
"theme": "Phantom", //肉鸽主题
"priority": [ //群组
...
],
"team_complete_condition": [ //阵容完备度检测
{ //一个策略组 (condition)
"groups": [ //需要哪些群组中的干员
"高台输出" //（这里表示需要高台输出组的干员1名）
],
"threshold": 1 //这些干员需要多少数量
},
{ //可以有多个策略组
"groups": [
"棘刺", //（这里表示棘刺、地面阻挡、地面单切、炮灰分组的干员最少需要2个）
"地面阻挡",
"地面单切",
"炮灰"
],
"threshold": 2
},
{
"groups": [
"奶" //（这里表示需要奶组的干员1名）
],
"threshold": 1
}
...
]
}警告
当一个干员出现在多个干员组时，只进行一次计数 比如：干员 棘刺 可能同时出现在干员组 棘刺 和 地面阻挡 中，在这个策略组内，只对干员 棘刺 计入一次
但每个策略组分别计数 比如：干员 焰影苇草 可能同时出现在干员组 高台输出 和 奶 中，此时两个策略组都可以计入干员 焰影苇草
调整干员招募参数
群组内的干员顺序代表作战部署该干员组时选择干员的优先度
临时招募干员会在原有的评分基础上加 600 分
随机直升干员的评分是招募评分+精二评分加起来计算
群组内干员各个字段的意思和脚本相关的逻辑
{ "theme": "Phantom", "priority": [ "name": "地面阻挡", // 群组名（这里是地面阻挡组） "doc": "标准线为1档(清杂能力或者站场能力比山强)>山>2档(阻挡>2,可自回)>斑点,站场能力小于斑点放到单切或者炮灰组", // 带“doc”字段均为json内备注文档，对程序运行没有影响 "opers": [ // 该包括哪些干员，有序，代表部署优先度 { "name": "百炼嘉维尔", // 干员名称（这里是百嘉，在组内第1位，表示需要部署地面阻挡组的时候，首先检测是不是百嘉） "role": "Warrior", // 干员职业，可选。存在同名干员时用于区分职业，填英文职业名，大小写不限 "skill": 3, // 使用几技能（这里举例使用3技能） "skill_usage": 2, // 技能使用模式，参考 战斗流程协议，不同在于，此处不写默认为1 // （0为不自动使用，1为好了就用，2为好了就用x次（x通过"skill_times"字段设置），3暂时不支持） "skill_times": 2, // 技能使用次数，默认为1，在"skill_usage"字段为2时生效 "alternate_skill": 2, // 当没有指定技能时使用的备选技能，一般是6星干员未精二且精二后使用3技能时才需要指定（这里指没有3技能时使用2技能） "alternate_skill_usage": 1, // 备选技能的技能使用模式（该字段尚未实现） "alternate_skill_times": 1, // 备选技能的技能使用次数（该字段尚未实现） "recruit_priority": 900, // 招募优先级，数字越大优先级越高，900以上属于看到必招，400以下招募优先级比一些关键干员精二优先度还低 // 临时招募的干员优先度自动+600 "promote_priority": 600, // 进阶优先级，数字越大优先级越高，900以上属于有希望就精二，400以下招募优先级低于招募普通三星干员 // 小技巧:当你将招募优先度压低或者不写,拉高一些精二优先度,实际上就是在拉高临时招募到这些干员的精二优先度 "is_key": true, // true为key（关键）干员，false或省略为非key干员。在阵容完备检测未通过时，仅招募key干员与0希望干员，保存希望。 "is_start": true, // true为开局选择干员，false或省略为非开局干员。在队伍中没有start干员时，仅招募start干员与0希望干员 // 与用户图形界面的开局干员绑定，且用户手动填写的干员会强制设为start干员 "is_alternate": false, // true 为后备干员（允许重复招募，划到后备干员时不再往右划动），false 或省略为普通干员 "auto_retreat": 0, // 部署几秒后自动撤退，整数，大于 0 时生效，主要用于特种干员和投锋，由于肉鸽一般是2倍速，推荐设置为技能持续时间/2 "recruit_priority_when_team_full": 850, // 无需单独设置，满足阵容完备度时，招募优先级，默认招募优先级-100 "promote_priority_when_team_full": 850, // 无需单独设置，满足阵容完备度时，进阶优先级，默认精二优先级+300 "recruit_priority_offsets": [ // 按当前阵容调控招募优先级 { "groups": [ // 需要哪些组满足条件，是按组计数，这些组里不要出现重复干员，否则会重复计数 "凯尔希", "地面阻挡", "棘刺" ], "is_less": false, // 条件是大于还是小于, false是大于等于, true是小于等于，不写默认false "threshold": 2, // 满足条件的数量，不写默认0 "offset": -300 // 满足后对招募优先级的调整，不写默认0 // (这里表示当 凯尔希, 地面阻挡, 棘刺 这三个群组中有2名以上干员时, 百炼嘉维尔的招募优先级减300) } ], "collection_priority_offsets": [ // 按当前拥有的藏品调控招募优先级 { "collection": "古旧的钱币", // 藏品名称 "offset": 100 // 拥有该藏品后对招募优先级的调整，不写默认 0 } ] }, ... ], ], "team_complete_condition": [ ... ] }注意
recruit_priority_offsets的group中的群组不要有重复干员auto_retreat设置后一般不需要再在作战计划中为其设置retreat_plan按照你的理解新增群组和干员
新增群组后，你可以从已有的群组中复制干员过来，参考大佬们已有的评分，在此基础上修改
肉鸽第二步——战斗逻辑
resource/roguelike/主题名/autopilot/关卡名.json 描述了每个关卡的作战策略
MAA 肉鸽通用战斗逻辑——牛牛高血压之源
（在关卡名对应作战逻辑文件不存在时生效）
根据地图上格子类型进行基本的战斗操作
MAA 会根据地图上的格子是蓝门还是红门，是高台还是地面，能不能被部署来进行基本的战斗操作
MAA 仅根据地图名称或者编号决定使用哪份作业，不会判断地图的普通、紧急、路网、密文板使用等情况
MAA 不会判断作战中地图上无法确定的格子的情况，比如
驯兽小屋的祭坛位置，从众效应是从左边还是从右边出怪
所以在后面，你需要尽量设计一套能够应付一个地图名所有不同情况（上面提到的几种情况）的战斗逻辑,小心被大家挂到 issue 上说这张图操作高血压哦（笑）
MAA 的通用作战策略--堵蓝门
地面干员会优先部署在蓝门的格子上（为什么是格子上，请往下看）或者周围，方向朝向红门（自动计算），
优先部署地面，然后部署治疗干员和高台干员，一圈一圈的由蓝门向四周部署，
会不停的按照上面的逻辑部署可以部署的东西（干员、召唤物、支援物品等等）
优化基本战斗策略
蓝门替代方案
仅仅把干员堆在蓝门门口显然不太聪明，有些关卡有格子是一夫当关万夫莫开，防守在这里显然效率很高，
或者有些关卡有多个蓝门，MAA 不知道哪个蓝门对应哪个红门，也会胡乱部署，
这个时候你需要打开 地图 Wiki 一边对着地图一边在脑海里指挥作战了
首先在
设置里将坐标展示切换为MAA然后根据你的经验寻找需要优先防守的点的坐标和朝向（一般是朝向来怪的方向），写入到 json 的
"replacement_home"里面{ "stage_name": "蓄水池", // 关卡名 "replacement_home": [ // 重要防守点（蓝门替代点），至少需要填写1个 { "location": [ // 格子坐标，从地图wiki获得 6, 4 ], "direction_Doc1": "优先朝向，但并不代表绝对是这个方向（算法自行判断）", "direction_Doc2": "不填默认 none，即没有推荐方向，完全由算法自行判断", "direction_Doc3": "none / left / right / up / down / 无 / 上 / 下 / 左 / 右", "direction": "left" // （这里表示将干员优先部署到坐标6,4的格子朝左，周围自动部署的干员也尽量朝向左） } ],提示
蓝门替代方案会在
deploy_plan全部完成但待部署区仍有干员的情况下生效，逻辑同通用作战策略部署格子黑名单
有优先防守的点就有优先不部署干员的点，比如大火球经过的位置，boss 脚底下，一些不好输出的位置，
这个时候我们引入了
"blacklist_location"将不想让他部署干员的格子加到黑名单里注意
这里加入的格子，就算在后面的部署策略里面写进去的话，也是没法部署的
... "blacklist_location_Doc": "这里是用法举例，不是说蓄水池这个图需要 ban 这两个点", "blacklist_location": [ // 禁止程序进行部署的位置 [ 0, 0 ], [ 1, 1 ] ],其他地图策略
比如水月肉鸽中如果蓝门进怪了是不是要用骰子，缓解堆怪压力
"not_use_dice_Doc": "蓝门干员撤退时是否需要用骰子，不写默认false", "not_use_dice": false,
还是高血压？是时候展现你真正的技术了——定制作战策略！
使用"deploy_plan"和"retreat_plan"实现定制化操作
定制化策略优先于通用战斗策略，当定制化策略中的所有步骤都尝试执行完毕后，剩下的干员或者倒下再部署的干员会按照通用战斗策略不断部署
有时候不需要设置太多的定制策略，完成关键步骤后再交给 MAA，二者结合可能效果更好
使用各个群组部署干员
"deploy_plan": [ // 部署逻辑，按从上到下、从左到右的顺序进行检索，并尝试部署找到的第一个干员，如果没有就跳过 { "groups": [ "百嘉", "基石", "地面C", "号角", "挡人先锋" ],//这一步从这些群组中寻找干员 "location": [ 6, 4 ], //遍历百嘉群组、基石群组、地面C群组等等群组 "direction": "left" //将找到的第一个干员部署到6,4这个坐标上并朝向左边 }, //没找到就进行下一个部署操作 { "groups": [ "召唤" ], "location": [ 6, 3 ], "direction": "left" }, { "groups": [ "单奶", "群奶" ], "location": [ 6, 2 ], "direction": "down" } ]注意
MAA 会将所有部署指令扁平化后，执行最优先级部署操作 例：在[6,4]部署[ "百嘉", "基石", "地面 C"]，在[6,3]部署[ "基石", "地面 C"]，那么 MAA 会将部署指令扁平化成附带坐标的[ "百嘉", "基石", "地面 C"，"基石", "地面 C"] 如果在战斗中[6,4]位置的"百嘉"组干员倒下，手里有有可部署的“基石”组干员，会优先布置到[6,4]而不是[6,3]
这意味着从宏观上来看，每次执行完部署动作之后都会从头开始检查可执行的策略（当前步骤的位置没有已经放置的干员，且待部署区有干员属于此步骤的干员组）
提示
一些常用的干员组用法:
1.很多作业中主要防守点的组合是[ "地面阻挡", "处决者", "其他地面"]，这意味着当主要抗伤位干员死了会尝试用处决者拖延 cd;当这个点生存压力过大时,考虑使用[ "重装","地面阻挡", "处决者", "炮灰", "其他地面"];盾后的点则可以优先盾后输出[ "地面远程","地面阻挡", "处决者", "其他地面"]；单纯吸引仇恨 or 送死可以使用[ "炮灰", "障碍物", "其他地面"]
2.高台位组合常用[ "高台输出", "其他高台"]，想要无论什么高台都可以放置可以使用[ "高台输出", "狙击", "辅助", "盾法", "其他高台"]
3.一些地面位置叔叔和地刺类干员都比较适合[ "玛恩纳", "地刺"]
在某个时间点部署干员
提示
适用于某些单切干员或者需要炮灰的使用场景
"deploy_plan": [ { "groups": [ "异德", "刺客", "挡人先锋", "其他地面" ], "location": [ 5, 3 ], "direction": "left", "condition": [ 0, 3 ] // 该操作仅在击杀数为0-3时进行 }, { "groups": [ "异德", "刺客", "挡人先锋", "其他地面" ], "location": [ 5, 3 ], "direction": "left", "condition": [ 6, 10 ] }, ... ]在某个时间点撤退干员
提示
有时候炮灰过强站住场或者需要部署位腾挪阵容怎么办，撤退！
同一位置的部署和撤退命令的 condition 数字尽量不要重叠，否则会秒上秒下
"retreat_plan": [ // 在特定时间点撤退目标 { "location": [ 4, 1 ], "condition": [ 7, 8 ] // 在击杀数为7-8时，撤去位置[4,1]的干员，没有就跳过 } ]在某个时间点释放技能（to do）
一些其他的字段（不推荐使用）
"role_order_Doc": "干员类型部署顺序，未写出部分以近卫，先锋，医疗，重装，狙击，术士，辅助，特种，召唤物的顺序补全，输入英文", "role_order": [ // 不推荐使用，请配置deploy_plan字段 "warrior", "pioneer", "medic", "tank", "sniper", "caster", "support", "special", "drone" ], "force_air_defense_when_deploy_blocking_num_Doc": "场上有10000个阻挡单位时就开始强制部署总共1个对空单位（填不填写均不影响正常部署逻辑），在此期间不禁止部署医疗单位（不写默认false）", "force_air_defense_when_deploy_blocking_num": { // 不推荐使用，请配置deploy_plan字段 "melee_num": 10000, "air_defense_num": 1, "ban_medic": false }, "force_deploy_direction_Doc": "这些点对某些职业强制部署方向", "force_deploy_direction": [ // 不推荐使用，请配置deploy_plan字段 { "location": [ 1, 1 ], "role_Doc": "填入的职业适用强制方向", "role": [ "warrior", "pioneer" ], "direction": "up" }, { "location": [ 3, 1 ], "role": [ "sniper" ], "direction": "left" } ],
注意
当 maa 无法找到当前关卡对应的定制作战策略时，会自动执行通用作战策略
当 maa 对当前关卡名称识别失败后，不会执行任何作战逻辑
对某个干员打法有特殊理解？——精细化操作特定干员
请将这位干员单独分组
编写作业时请考虑这位干员与现有作业的顺序优先度
你也可以不考虑那么多，单独为这个干员写一份作战逻辑
仅使用一位干员也是可行的！使用 MAA 来凹单人通关吧（由于其他逻辑的不完善，可能性很低）
参考例子：1.傀影肉鸽的棘刺，2.水月肉鸽的异德，3.萨米肉鸽的焰影苇草/维什戴尔，4.萨卡兹肉鸽的维什戴尔
肉鸽第三步——不期而遇类节点逻辑
resource/roguelike/主题名/encounter/default.json 描述了刷等级模式下不期而遇事件选择的策略
resource/roguelike/主题名/encounter/deposit.json 描述了刷源石锭模式和刷开局模式下不期而遇事件选择的策略
MAA 现有对不期而遇的判断方法
OCR 识别不期而遇事件名称，但是选项是操作固定的位置
事件名识别失败的话会点击选项类型图标（若有），或点最下面的选项
一个常见的卡死原因就是选项类型的图标存在但选项不可选（TODO）
改进肉鸽逻辑时，一般只需要微调或者不调整(大佬都写好了嘛)
优化不期而遇选项的优先度
请结合 prts.wiki 查看各个事件的选项效果，注意选项不一定固定
可以自己修改不期而遇事件选项以指引 MAA 走向某些图的特殊结局
{
"theme": "Sami", //肉鸽主题
"mode": [1, 4], //限定该文件在哪些模式下生效，可选；不写则对所有模式生效
"stage": [ //不期而遇类事件
{
"name": "低地市集", //不期而遇事件名称
"option_num": 3, //总共有几个选项（这里是3）
"choose": 3, //优先选择第几个选项（这里优先选第三个），如果选不到就选跑路选项（基本上是最后一个）
"choices": [ //对特定选项的额外要求
{
"name": "选择碎草药", //选项的名字
"choose": 1, //满足下方条件时优先选择的选项序号，可选；不写时该条不生效
"requirements": [ //生效条件，可选
{
"name": "Vision", //条件类型，目前仅支持 Vision（灯火值）
"value": "3", //要求的数字
"type": ">" //是大于还是小于（还可以是 =，这里表示灯火大于 3 时该条 choose 才生效）
}
]
},
{
"name": "选择好看的织物",
"choose": 1,
"requirements": [
{
"name": "Vision",
"value": "3",
"type": ">"
}
]
},
...事件还支持以下可选字段：
option_text：字符串数组，事件各选项的文本，用于辅助识别匹配next_event：字符串，该事件处理完后要跳转到的下一个事件名fallback_choices：形如[[实际选项数, 优先选择], ...]的数组，当实际识别到的选项数与option_num不一致时，按实际选项数匹配并选择对应的选项
黑流树海事件策略与选择结果
黑流策略模块支持 encounter_rules。规则使用事件标题 event_name 匹配事件，when 复用策略条件语法。 例如，先行一步对应的事件标题是“未涉足之树”。多个规则同时满足时，先比较 rank，数值小的优先； 相同 rank 按规则 id 的字典序决定顺序。未命中规则时沿用事件默认配置。
选项可以按 option_text 中的文字顺序匹配，也可以同时指定 option_num 与 choose，在实际选项数 与 option_num 相等时选择从 1 开始编号的 choose。两种表达方式互斥。allow_fallback 默认为 true，目标不可用或选择失败时从下向上尝试可用选项；设为 false 后，目标选择失败就结束本次选择。
事件判断可读取以下内置页面事实，无须在 facts 中重复声明：
| 事实 | 类型 | 含义 |
|---|---|---|
encounter.name | string | 当前识别到的事件标题。 |
encounter.option_count | int | 实际识别到的选项数量。 |
encounter.available_options | string_list | 本次决策时可用的选项文字。 |
encounter.route_known | bool | 进入事件时，是否保留了有效的完整单条剩余路线。 |
encounter.remaining_battles | int | 该路线中当前事件之后的战斗数，仅在路线明确时提供给决策。 |
encounter.selected_option | int | 实际选中的选项序号，从 1 开始。 |
encounter.selected_text | string | 实际选中的选项文字。 |
encounter.used_fallback | bool | 实际选择是否使用了兜底。 |
encounter.rule_id | string | 本次选择请求命中的规则；未命中时为空。 |
available_options、route_known 与 remaining_battles 供事件决策使用。判断无战斗必须同时要求 route_known 为 true、remaining_battles 为 0。空路线、多个落点以及后续节点身份不明确时， 均不能认定无战斗。这里读取进入事件时的计划，不约束后续重新规划。
选择成功后，共享事件插件发出 RoguelikeEventSelected 回调，包含 name、option_num、 choose_option、option_text、rule_id、rule_description 与 used_fallback。界面日志显示实际选中的 文字；命中规则且未兜底时附带规则的 description 作为理由，因此不同策略即使选择同一选项也可以 各自说明理由。黑流会话将实际选择写入页面事实， 随后刷新里程碑。rule_id 表示原先的选择请求，使用兜底时不能据此认定目标选项已选中；里程碑应检查 实际选择事实。选择结果不代表干员已派出；对于确认选择就必然获得的物品，可由规则的 on_selected 明确更新对应事实。
on_selected 是整局事实名到值的映射，只允许已声明且类型匹配的 run 事实，不允许写入 milestone.*。只有实际选中文字属于该规则的 option_text 才应用赋值；兜底选中其他文字时不应用。 这些赋值与本次选择记录统一写入后再刷新里程碑，失败时不保留部分更新。二结局“线人”确认选择 “我受雇于梅兰德”后立即将 sandtable_a 设为 true，节点结束仍沿用奖励与收尾流程。
页面任务结果同样先校验整组事实和页面变更，再统一写入。已完成页面不能再次接收完成结果，避免 同一次收藏品结果重复累计。里程碑变化沿用现有回调，不增加来源记录；错过里程碑的结束判断仍在 地图观测时执行。
黑流事件默认配置支持 option_tasks，以实际选中的完整选项文字为键，以已存在的任务名为值。 匹配后经 JustReturn 入口转发到对应任务链，目标任务以自己的名称执行，保留其模板配置、任务名回调 和执行次数统计。由该任务链处理后续页面；本次不再执行事件级 next_event。没有对应项时继续原有的 奖励和事件收尾流程。所有配置的任务须在选择之前能够解析，缺少任务时不点击选项。
连续单选项事件
黑流事件默认配置中的 continue_single_option 默认为 false，目前仅为“安眠一隅”启用。 启用后，每一页重新识别选项，仅在恰好一个选项可用时选择它，不按固定文字、数字或倒序兜底选择。 零个或多个可用选项以及选择确认失败都按选择失败处理。
每次选择继续使用确认按钮及 LoadingText 等待链。随后处理奖励和事件对话；出现选项时核对事件标题， 标题仍为当前事件才重新识别下一页，明确识别到地图后才结束整个事件。相邻页面可以使用相同的选项文字。 加载、识别失败和用户停止均不能视为事件完成。此字段只支持黑流，且不能与 next_event 或 option_tasks 同时启用。每次成功选择仍分别回传实际选项，页面完成只在整个事件结束后报告。
根据队伍情况动态调整某些选项的优先度（TODO）
肉鸽第四步——商店藏品的优先度
resource/roguelike/主题名/shopping.json 描述了商店购买藏品(和战斗后选择藏品?)的策略
{
"theme": "Phantom", //肉鸽主题名（这里是傀影）
"priority": [ //优先度,有序,顺序即为优先级,越在前面越优先购买,
//但优先级判断在chars,roles的筛选之前, 可能出现高优先级商品被筛掉, 什么都不买的情况
{
"name": "金酒之杯", //藏品名字（这里金杯）
"no_longer_buy": true, //true表示获得该藏品后不在花钱买藏品，false或者省略表示继续花钱买藏品
"ignore_no_longer_buy": true, //true表示商店有该藏品时忽略"no_longer_buy",就是还会买它，false或者省略表示拿到有"no_longer_buy"的藏品后不会购买这个藏品
"effect": "每有5源石锭，所有我方单位的攻击速度+7", //藏品效果（不影响程序运行，备注效果方便排序）
"No": 167 //藏品编号,wiki可查（不影响程序运行，备注方便排序）
},
...
{
"name": "扩散之手",
"chars": [ //队伍中有这些干员的时候买这件藏品
"异客" //（这里表示队伍中有异客时，遇到扩散之手，就会尝试购买）
],
"effect": "【扩散术师】、【链术师】和【轰击术师】每对一个单位造成伤害就回复2点技力值",
"No": 136
},
...
{
"name": "折戟-破釜沉舟",
"roles": [ //队伍中有这些职业的时候买这件藏品
"WARRIOR" //（这里表示队伍中有近卫干员时，遇到折戟-破釜沉舟，就会尝试购买）
], //仅支持大写英文职业名
"effect": "所有【近卫】干员的防御力-40%，但攻击力+40%，攻击速度+30",
"No": 16
},
...
{
"name": "Miss.Christine摸摸券",
"promotion": 2, //不为 0 时，队伍中存在待晋升干员才会购买，默认为 0，不作要求
"promotion_rarity": 6, //统计待晋升干员的稀有度上限，只统计稀有度低于该值的干员，可选，默认为 6（即不限制）
"effect": "立即进阶两个干员（不消耗希望）",
"No": 15
},
...
{
"name": "警戒篱木",
"effect": "坍缩值-2，目标生命上限+2",
"No": 198,
"decrease_collapse": true // true表示获得该藏品会降低坍缩值。在mode为5时将不会购买
},
...除 priority 外，shopping.json 还可以声明命名买表与卖表，供按策略选表的主题使用：
{
"theme": "BlackFlow",
"priority": [ ... ], // 默认买表，名称为 default
"buy_tables": { // 可选，命名买表；商品项写法与 priority 相同，default 保留给 priority
"表名": [ { "name": "..." } ]
},
"sell_tables": { // 可选，命名卖表，列出允许出售的名称；列表顺序不决定出售顺序
"cultivation_final": [ "血蕈", "雾滚草", ... ]
}
}命名买卖表、price 和购物时的余额预筛选目前只对黑流树海生效；其他主题继续读取 priority，沿用原有解析规则。
各主题的 roles 都只接受上文的大写职业名。黑流树海另外要求商品名称不能为空，roles 与 chars 必须是字符串数组。 任一项不符时整个文件解析失败。空买表表示没有购买候选，空卖表表示不出售。
黑流树海的商品项可以填写正整数 price。读到商店余额时，余额不足的商品会被跳过，继续看下一件；不填写时行为不变。
黑流树海按策略选择买卖表
黑流策略模块支持 shopping_rules，在页面分派时按当前页面意图和事实选择一对买卖表：
"shopping_rules": [
{
"id": "cultivation_final", // 同一策略内唯一
"description": "第三层培育后结束，加工品卖出换种子", // 可选
"page_intent": "scrap_shop.cultivate", // 可选，省略时对该策略的所有页面生效
"rank": 0, // 可选，默认 0，数值小的优先
"when": { "fact": "current_floor", "op": "eq", "value": 3 }, // 可选，复用策略条件语法
"buy_table": "default", // 可选，默认 default
"sell_table": "cultivation_final" // 可选，省略或为空时不出售
}
]多条规则同时满足时，先比较 rank，相同时按 id 的字典序，与 encounter_rules 一致。每次只采用一条规则的 买卖表，不混合不同规则的字段；未命中规则时使用 default 买表且不出售。每次页面分派都会重新选表，上一页面的 选择不会延续到下一页面。
when 不能读取候选路线事实。规则引用的表名必须存在于黑流的 shopping.json，否则策略配置解析失败。 通用购物使用选中的买表；秘境行商培育使用选中的卖表筛选出售名称。
肉鸽特殊机制
萨米肉鸽——密文板
resource/roguelike/Sami/foldartal.json 描述了萨米肉鸽密文板的策略
{
"theme": "Sami", //肉鸽主题名（这里是萨米）
"groups": [ //对使用情况和用法的分组
{
"usage": "SkipBattle", //用法（这里是跳过战斗,用于刷钱和烧水模式的作战节点,使用板子跳过战斗以节省时间）
"doc": "跳过战斗,刷钱和烧开水模式",
"pairs": [ //板子对(遇到对应的节点时,会判断有没有符合下面设定的板子对,如果有,就使用能用的全用,如果没有就直接进点)
{ //（这里伤痕只能和空无联结）
"up": [ //上板子
"伤痕"
],
"down": [ //下板子
"空无"
]
},
{ //（这里会按顺序搜索 "黜人"+"惊讶","黜人"+ "疑惑","黜人"+...,"猎手"+"惊讶","猎手"+ "疑惑","猎手"+... , ...）
"up": [
"黜人",
"猎手",
...
],
"down": [
"惊讶",
"疑惑",
...
]
}
]
},
{
"usage": "Boss", //（这里表示遇到boss点会用的板子对）
"doc": "有的用全用了",
...
}
],
"foldartal": [ //密文板效果备注（这里仅做备注方便查看板子效果，不影响程序运行）
{
"name": "布局", //密文板类型（上板子还是下板子）
"foldartal": [
{
"name": "黜人", //密文板名称
"effect": "选择所有右侧邻近的战斗节点" //密文板效果
},萨米肉鸽——坍缩范式
当check_collapsal_paradigms为true时，MAA 将以两种不同的手段检查坍缩范式：
- 在选关界面点击屏幕中上方展开坍缩状态栏，以下称 Panel Check ；
- 观察屏幕右侧是否有坍缩范式通知 以下称 Banner Check 。
获取坍缩值的方法多种多样，我们考虑到了以下情况：
- 战斗后因非完美战斗而使坍缩值增加，进行 Banner Check 。
- 战斗后因获得收藏品而使坍缩值变动，进行 Banner Check 。
- 在不期而遇等节点中因选择选项而使坍缩值变动，进行 Banner Check 。
- 再诡异行商节点中因购买收藏品而使坍缩值变动，进行 Banner Check 。
- 因使用密文版而使坍缩值减少，进行 Banner Check 。
- 因进入新的一层而使坍缩值增加，进行 Panel Check 。
- 若进行 Banner Check 时发现坍缩范式消退，因不知道会不会一次性消退两层（即便会也概率极低），会在下一次回到选关洁面的时候额外触发一次 Panel Check 。
- 在
double_check_collapsal_paradigms为true的情况下，每次回到选关界面的时候都会额外触发一次 Panel Check 以验证是否之前有漏、多记录坍缩范式。
以下为刷隐藏坍缩范式的任务配置示例：
{
"theme": "Sami",
"mode": 5,
"investment_enabled": false,
"squad": "远程战术分队",
"roles": "稳扎稳打",
"core_char_list": [
{ "name": "维什戴尔", "use_support": false },
{ "name": "斑点", "use_support": false },
{ "name": "史都华德", "use_support": false }
],
"expected_collapsal_paradigms": ["目空一些", "睁眼瞎", "图像损坏", "一抹黑"]
}当mode为5时：
- 优先使用
stage_name为关卡名_collapse的作战策略，例如resource/roguelike/Sami/autopilot/事不过四_collapse.json； - 使用
resource/roguelike/Sami/encounter/collapse.json中描述的不期而遇事件选择的策略， - 不会购买
decrease_collapse为true的藏品。
当mode不为5但check_collapsal_paradigms为true时，仍会检测坍缩范式并在遇到expected_collapsal_paradigms列表中的坍缩范式时停止任务，但在遇到其他坍缩范式时将不会重开。
刷隐藏坍缩范式时，推荐 N10 难度，建议使用以下队伍：
- 维什戴尔 + 斑点 + 史都华德；
- 焰影苇草 + 梓兰 + 泡普卡；
- 提丰 + 斑点 + 史都华德。
界园肉鸽——通宝
resource/roguelike/JieGarden/coppers.json 描述了界园肉鸽通宝的配置和交换策略
{
"theme": "JieGarden", //肉鸽主题名（这里是界园）
"addons": { //通宝附加属性说明（仅作注释，不影响程序运行）
"锈色": "投出时，每经过一个节点，获得源石锭+1",
"存护": "加入钱盒时，获得护盾值+2",
"入幻": "加入钱盒时，获得希望+1",
"引光": "加入钱盒时，获得烛火+1",
"巡游": "投出时，每完成一场战斗，获得票券+1"
},
"coppers": [ //通宝列表
{
"name": "大炎通宝", //通宝名称
"desc": "普通又空白，什么也没有", //通宝效果描述（仅作注释，不影响程序运行）
"rarity": "NORMAL", //稀有度：NONE/NORMAL/RARE/SUPER_RARE（仅作注释，不影响程序运行）
"pickup_priority": 0, //拾取优先级，在掉落选择时使用，数值越高越优先拾取
"discard_priority": 1000 //丢弃优先级，在交换时使用，数值越高越优先被丢弃
},
{
"name": "衡-奇土生金",
"desc": "投出时，立即获得源石锭+4（下次投钱前变化为-大炎通宝）",
"rarity": "NORMAL",
"pickup_priority": 200,
"discard_priority": 800,
"cast_discard_priority": 999 //可选字段，已投出时的丢弃优先级，仅在已投出且值>=0时替代 discard_priority
//这通常适用于一些投出后效果发生变化的通宝（如变为大炎通宝的通宝）
},
{
"name": "厉-西廉贞",
"desc": "投出时，精英及领袖敌人的生命值、攻击力+10%，在险路恶敌及岁兽残识中攻击力、生命值额外+20％",
"rarity": "NORMAL",
"pickup_priority": 0,
"discard_priority": 1998,
"cast_discard_priority": 2098 //同上，有时也会用在一些投出后带来负面效果的通宝
},
...
]
}通宝交换逻辑
MAA 在界园肉鸽中会自动处理通宝的拾取和交换：
拾取掉落通宝：在战斗结束后，如果出现通宝掉落选择界面，MAA 会根据
pickup_priority选择优先级最高的通宝交换钱盒通宝：当新拾取的通宝需要与钱盒中的通宝交换时：
- 识别钱盒中所有通宝的类型、名称和是否已投出状态
- 找到钱盒中
discard_priority最高（最不重要）的通宝 - 如果新通宝的
discard_priority比最不重要的现有通宝更低，则放弃交换 - 否则将最不重要的通宝替换为新通宝
已投出通宝的特殊处理：
- 对于标记了
cast_discard_priority的通宝，在已投出状态时使用该优先级而非discard_priority - 这通常适用于一些投出后效果发生变化的通宝（如变为大炎通宝的通宝）
- 对于标记了
通宝识别机制
MAA 使用以下方法识别和处理通宝：
- 通过模板匹配识别通宝的类型图标（厉/衡/花）
- 基于类型图标的位置，使用 ROI 偏移进行 OCR 识别通宝名称
- 识别通宝是否处于"已投出"状态
- 在通宝交换界面中自动滑动列表，扫描所有通宝进行比较
识别流程示意
注意
- 如果 OCR 识别的通宝名称在配置文件中未找到，MAA 会保存调试图像到
debug/roguelike/coppers/unknown目录，以供排查
希望实现的逻辑（TODO）
自动编队逻辑
可以根据不同地图设置不同的地图阵容完备性检测和技能优先度
可以根据现有阵容避开一些难度高的作战
优化寻路算法（已初步实现）
比如可以实现前三层多战,后面的少战,这样发育会更好
比如识别节点间的连线来判断更优路径
技能保留
某格部署的干员，技能转好后等待 x 秒再开，方便对轴；可以写 Deploy_plan 下的 Skill_hold，也可以写 Skill_hold_plan
技能关闭
对弹药类干员有用