迈向规范化任务链编写｜Towards canonical task chain-writing

[Alan-Charred]

先占个位置，糊点乱七八糟的东西，并抛砖——啊，没有砖但是想要白嫖玉。

Introduction

当讨论 MAA 的时候，我们往往会将 MAA 分为五个部分：

1. Core 程序：用 C++ 编写的程序代码，被调用的外部库也被划在这一类；
2. 任务链: 由 tasks.json 文件和 template 文件夹共同构成的任务链信息；
3. 作业：由攻略作者们创作的攻略，除了战斗作业以外，集成战略中的招募、藏品购买优先级，以及基建换班作业等也被归在这一类；
4. 其他数据：包括但不限于干员信息、战斗地图格子数据等；
5. GUI：目前 MAA 有两个 GUI，分别为 Windows 平台的 WPF-GUI 和 macOS 平台的 Mac-GUI，其中 WPF-GUI 的功能最全；此外也支持 CLI 操作。（这跟我一个直接用 C++ 接口运行 MAA 的用户又有什么关系呢？）

任务链无疑是 MAA 运行的基石之一。当运行一个 接口任务¹ 时，Assistant 会根据任务类型创建对应的 InterfaceTask 的子类的对象，后者将根据接口任务的参数启用需要的插件并调用预先编写好的任务链。任务链运行时不断检测各插件的触发条件——比如特定任务执行前或执行后，若条件满足则运行插件，以实现更复杂的操作。

本 discussion 建立的目的主要是分享与讨论一些任务链编写实践，尝试归纳、总结一些其中值得推广的部分。虽说不是什么规范，但日积月累，或许能为未来的开发者提供一些便利。

可能的讨论话题有：

1. 任务命名；
2. 任务注释；
3. 如何选择 MatchTemplate 与 OcrDetect；
4. 模版匹配方法、如何更好的截取并预处理模版图像；
5. 模版任务与虚任务实践；
6. 如何更稳妥地使用 sub；
7. 改进 ProcessTask；
8. 辅助工具；
9. 对任务链的抽象与验证。

Footnotes

1. 为了消除歧义，我们将集成文档中提及的可由 AsstAppendTask 接口创建的任务，即 StartUp, CloseDown, Fight, Recruit, Infrast, Mall, Award, Roguelike, Copilot, SSSCopilot, Depot, OperBox, Reclamation, Custom, SingleStep, VideoRecognition 共 16 项，称为接口任务。 ↩

[Alan-Charred]

素材 +1

共有三个任务了使用模版 Roguelike@StageTraderRefresh.png，但是每个任务都把同样的 roi 和 action 复制了一遍。
我认为正确的做法应该是创建一个模版任务后，在需要的时候用 baseTask 调用，大多数时候只需要 baseTask, template, next 这三个参数。
简而言之，可被重复使用的单步操作应当建立模版任务以供调用。

原先的任务流为

    "Roguelike@StageTraderRefreshWithDice": {
        "template": "Roguelike@StageTraderRefresh.png",
        "action": "ClickSelf",
        "roi": [230, 47, 211, 182],
        "next": [
            "Roguelike@StageTraderRefreshWithDiceConfirm",
            "Roguelike@StageTraderRefreshWithDiceNotAvaiable",
            "Roguelike@StageTraderInvestSystem",
            "Roguelike@TraderRandomShopping",
            "Roguelike@StageTraderLeave"
        ],
        "exceededNext": [
            "Roguelike@StageTraderInvestSystem",
            "Roguelike@TraderRandomShopping",
            "Roguelike@StageTraderLeave"
        ]
    },
    "Sami@Roguelike@StageTraderRefresh": {
        "template": "Roguelike@StageTraderRefresh.png",
        "action": "ClickSelf",
        "roi": [230, 73, 212, 141],
        "next": ["Sami@Roguelike@StageTraderRefreshConfirm"]
    },
    "Sarkaz@Roguelike@StageTraderRefresh": {
        "template": "Roguelike@StageTraderRefresh.png",
        "action": "ClickSelf",
        "roi": [230, 73, 212, 141],
        "next": ["Sarkaz@Roguelike@StageTraderRefreshConfirm"]
    },

修正后的任务流为

    "Roguelike@StageTraderRefresh": {
        "roi": [230, 47, 211, 182],
        "action": "ClickSelf"
    },
    "Roguelike@StageTraderRefreshWithDice": {
        "baseTask": "Roguelike@StageTraderRefresh",
        "template": "Roguelike@StageTraderRefresh.png",
        "next": [
            "Roguelike@StageTraderRefreshWithDiceConfirm",
            "Roguelike@StageTraderRefreshWithDiceNotAvaiable",
            "Roguelike@StageTraderInvestSystem",
            "Roguelike@TraderRandomShopping",
            "Roguelike@StageTraderLeave"
        ],
        "exceededNext": [
            "Roguelike@StageTraderInvestSystem",
            "Roguelike@TraderRandomShopping",
            "Roguelike@StageTraderLeave"
        ]
    },
    "Sami@Roguelike@StageTraderRefresh": {
        "template": "Roguelike@StageTraderRefresh.png",
        "next": ["Sami@Roguelike@StageTraderRefreshConfirm"]
    },
    "Sarkaz@Roguelike@StageTraderRefresh": {
        "template": "Roguelike@StageTraderRefresh.png",
        "next": ["Sarkaz@Roguelike@StageTraderRefreshConfirm"]
    },

此外，field 的顺序也应当有讲究。单个任务实际上指定了任务触发的 guard 和任务实际的 action。（此处甚至可以引入 Process Algebra 等形式化验证的内容）roi 参数应为 guard 的一部分。
因此我倾向于使用以下顺序：
1 - doc
2 - algorithm
3 - template / text
5 - roi
... 其他 guard 相关参数 ...
n - action
... 其他 action 相关参数 ...

[crazysmile-PhD]

我認為自動化將原本的任務列表规范化任务链编写更現實一點，因為一個一個打太坐牢了

``` import yaml

# Function to fill in template parameters dynamically
def fill_template_parameters(template, parameters):
    for key, value in parameters.items():
        placeholder = f"{{{{{key}}}}}"
        if isinstance(template, dict):
            for k, v in template.items():
                if isinstance(v, str) and placeholder in v:
                    template[k] = v.replace(placeholder, str(value))
        elif isinstance(template, str):
            template = template.replace(placeholder, str(value))
    return template

# Function to normalize task chain and automate parameter inputs
def normalize_task_chain_with_dynamic_params(task_data):
    templates = {}
    normalized_tasks = {}

    # Step 1: Extract common templates based on 'roi', 'action', and 'template'
    for task_name, task_details in task_data.items():
        # Convert list to tuple to make it hashable for dictionary keys
        roi = tuple(task_details.get('roi', []))
        action = task_details.get('action', '')
        template = tuple(task_details.get('template', '')) if isinstance(task_details.get('template', ''), list) else task_details.get('template', '')

        # Create a unique key based on 'roi', 'action', and 'template' to identify common templates
        template_key = (roi, action, template)

        # Check if this template already exists
        if template_key not in templates:
            template_name = f"TemplateTask_{len(templates) + 1}"
            templates[template_key] = {
                "template_name": template_name,
                "roi": "{{roi}}",  # Placeholder
                "action": "{{action}}",  # Placeholder
                "template": "{{template}}"  # Placeholder
            }

        # Step 2: Create a normalized task using the baseTask (template) and pass dynamic parameters
        base_task = templates[template_key]['template_name']
        parameters = {
            'roi': task_details.get('roi', []),
            'action': task_details.get('action', ''),
            'template': task_details.get('template', '')
        }

        # Fill template with parameters dynamically
        filled_template = fill_template_parameters(templates[template_key].copy(), parameters)

        normalized_tasks[task_name] = {
            "baseTask": base_task,
            "next": task_details.get('next', []),
            "parameters": parameters,  # Include the parameters for transparency
            "filled_template": filled_template  # Show the filled template for reference
        }

    # Step 3: Generate the final normalized task chain with templates and tasks
    normalized_chain = {
        "templates": {tpl['template_name']: tpl for tpl in templates.values()},
        "tasks": normalized_tasks
    }

    return normalized_chain

# Example task data for dynamic parameter testing
task_data = {
    "Roguelike@StageTraderRefreshWithDice": {
        "template": "Roguelike@StageTraderRefresh.png",
        "action": "ClickSelf",
        "roi": [230, 47, 211, 182],
        "next": [
            "Roguelike@StageTraderRefreshWithDiceConfirm",
            "Roguelike@StageTraderRefreshWithDiceNotAvaiable"
        ]
    },
    "Sami@Roguelike@StageTraderRefresh": {
        "template": "Roguelike@StageTraderRefresh.png",
        "action": "ClickSelf",
        "roi": [230, 73, 212, 141],
        "next": ["Sami@Roguelike@StageTraderRefreshConfirm"]
    }
}

# Normalize the task chain with dynamic parameter inputs
normalized_chain_dynamic = normalize_task_chain_with_dynamic_params(task_data)

# Save the normalized task chain to a new YAML file
normalized_yaml_dynamic_path = '/mnt/data/normalized_task_chain_dynamic_params.yaml'
with open(normalized_yaml_dynamic_path, 'w') as f:
    yaml.dump(normalized_chain_dynamic, f, default_flow_style=False)

# Return the path to the normalized YAML file
normalized_yaml_dynamic_path
自動化樣本參數輸入的步驟：
識別動態欄位：範本將包含佔位元（例如,、、 ），需要根據特定於任務的數據進行填充。{{roi}}{{action}}{{template}}
提取相關參數：對於每個任務，提取參數（、 等）並將其傳遞到範本中。roiaction
自動填充參數：實施一個系統，當任務引用基本範本時，該系統會自動將佔位元替換為特定於任務的數據。
方法：
動態範本系統：使用佔位元定義範本。當任務使用 時 ，它將提供必要的參數，這些參數會自動插入到範本中。baseTask
解釋：
佔位元替換：範本定義、 和 等佔位元。當任務引用範本時，實際值（例如 ， ）會使用該函數自動替換為範本。{{roi}}{{action}}{{template}}roiactionfill_template_parameters()
Dynamic Parameters：字典包含每個任務的特定值。這些值將動態插入到範本中，從而允許每個任務重複使用相同的範本，但具有不同的值。parameters
結果：現在，每個任務都包含對基本範本的引用和帶有實際參數值的填充範本。

[crazysmile-PhD]

上面太亂了這裡重新解釋自動化執行與實現
程式碼詳解
填充範本參數的函數 fill_template_parameters：

此函數的主要功能是根據傳入的參數動態地替換範本中的佔位符。
它會檢查範本是否為字典或字串：
如果是字典，則遍歷字典的每一個鍵值對，檢查值是否為字串並包含佔位符，若有則進行替換。
如果是字串，則直接替換佔位符為實際值。
最後，返回已填充的範本。
標準化任務鏈的函數 normalize_task_chain_with_dynamic_params：

此函數負責處理一組任務，並將它們標準化，將重複的任務合併為共用的範本。
步驟：
提取共用範本：
從每個任務中提取 roi（感興趣區域）、action（動作）和 template（範本），並用這些信息建立唯一的鍵值 template_key。
如果這個鍵值尚未存在於 templates 字典中，則為其創建一個新的範本。
生成標準化任務：
將任務的參數傳遞給相應的範本，使用 fill_template_parameters 函數將佔位符替換為實際值，然後將生成的任務加入 normalized_tasks 字典。
生成最終的標準化任務鏈：
最後，將所有範本和任務整理到一個結構中，便於後續使用。
自動化執行的實現
自動化的實現主要是通過以下幾個步驟來進行的：

動態參數填充：

每個任務都可能有不同的參數（例如 roi、action 和 template），這些參數在執行時被動態提取並填充到範本中。
這樣的設計允許相同的範本用於多個任務，而每個任務都會根據其特定需求自動填充對應的值。
共用範本系統：

使用共用範本來減少重複的程式碼和配置，增強可維護性。
透過建立唯一的範本鍵（template_key），系統能夠識別哪些任務可以共享相同的範本，從而避免冗餘。
自動生成最終結構：

透過將所有標準化的任務和範本整合在一起，最終生成的結構（normalized_chain）便於後續的儲存、使用和維護。
這也讓整個任務鏈的管理變得更為簡單和高效。

[crazysmile-PhD]

validated_normalized_task_chain_with_template_handling.zip
成品差不多就是這樣，懶得修了(❁´◡`❁)草，頭髮不見了

[crazysmile-PhD]

第二張圖的設計思路涉及到將任務的轉換標籤簡化為 "redo when blocked"，以提升任務鏈的可視化清晰度。以下是對這個做法及其實現的詳細說明。

第二張圖的思路
在第二張圖中，我們對場景 A 和場景 B 之間的轉換進行了重新設計：

行為 (action1)：

從場景 A 到場景 B 的初始行為。
重做 (redo when blocked)：

在場景 A 中，當進行 action1 之後，若因某些原因（如場景切換動畫或加載延遲）導致無法立即轉換到場景 B，則系統會自動重做 action1，直至成功。
保護條件 (guard)：

當達到場景 B 時，需要檢查是否可以執行 action2，同時確保場景 A 是否可以正常重做。
實現步驟
以下是具體實現這一邏輯的步驟：

定義任務狀態：

每個場景（如場景 A 和 B）都應定義為狀態 (state)。
為每個狀態添加相關的行為和條件，這些將在狀態轉換時使用。
設置轉換邏輯：

定義從場景 A 到場景 B 的轉換，並附上 action1。
對於 "redo when blocked"，在轉換邏輯中添加檢查，如果在轉換過程中遇到障礙，則重新執行 action1。
使用保護條件：

在從場景 B 返回場景 A 的轉換中，使用 guard 來決定是否可以執行 action2，這樣可以避免不必要的行為執行。
可視化簡化：

在可視化工具中，將這些轉換標籤設置為簡化形式，這樣使用者在查看任務鏈時能夠一眼明瞭整個流程。
範例代碼
這裡是一個簡化的範例代碼，示範如何使用 Python 實現這種邏輯：

``` class TaskState:
    def __init__(self, name):
        self.name = name
        self.actions = []
        self.guards = []
        self.transitions = {}

    def add_action(self, action):
        self.actions.append(action)

    def add_guard(self, guard):
        self.guards.append(guard)

    def add_transition(self, action, target_state, guard=None):
        self.transitions[action] = (target_state, guard)

# 定義場景 A 和場景 B
scene_A = TaskState("场景 A")
scene_B = TaskState("场景 B")

# 添加行為
scene_A.add_action("action1")
scene_B.add_action("action2")

# 設置轉換
scene_A.add_transition("action1", scene_B, guard="check_if_can_go_to_B")
scene_A.add_transition("redo when blocked", scene_A)  # 重做行為

# 可視化
def visualize(task_state):
    print(f"State: {task_state.name}")
    for action in task_state.actions:
        print(f"  Action: {action}")
    for action, (target, guard) in task_state.transitions.items():
        guard_info = f" with guard: {guard}" if guard else ""
        print(f"  Transition: {action} -> {target.name}{guard_info}")

# 可視化場景 A
visualize(scene_A)
這樣子?

[crazysmile-PhD]

使用 python 腳本對任務進行自動整理是一個極好的思路，只是我現在對於“由程式自動判斷是否應該合併任務 A 與任務 B”這件事還沒有信心
你要人工整理你知道這是多大一筆開支嗎(時間成本，還不排除打到一半放棄的成本PS論屎山代碼的傳承)，先讓程式自動判定有問題自動化生成報告時在尋找這才是我認為可行的方案(就算不可靠，經過調適即可)
自動整理任務的實現步驟
定義相似性判斷規則：

``` import yaml
from sklearn.metrics.pairwise import cosine_similarity
from sklearn.feature_extraction.text import CountVectorizer

def load_tasks(file_path):
    with open(file_path, 'r', encoding='utf-8') as file:
        return yaml.safe_load(file)

def save_tasks(tasks, file_path):
    with open(file_path, 'w', encoding='utf-8') as file:
        yaml.dump(tasks, file, default_flow_style=False, allow_unicode=True)

def calculate_similarity(text_a, text_b):
    vectorizer = CountVectorizer().fit_transform([text_a, text_b])
    vectors = vectorizer.toarray()
    return cosine_similarity(vectors)[0][1]

def task_context_similarity(task_a, task_b):
    # Compare templates and ROIs
    if (task_a['template'] == task_b['template'] and
        task_a['roi'] == task_b['roi']):
        
        # Calculate similarity of task descriptions
        doc_a = task_a.get('doc', {}).get('description', '')
        doc_b = task_b.get('doc', {}).get('description', '')
        similarity_score = calculate_similarity(doc_a, doc_b)

        # Use a threshold for merging
        return similarity_score > 0.7  # Example threshold
    return False

def merge_tasks(tasks):
    merged_tasks = {}
    issues = []

    task_names = list(tasks.keys())
    for i in range(len(task_names)):
        task_a_name = task_names[i]
        task_a = tasks[task_a_name]
        
        if task_a_name not in merged_tasks:
            merged_tasks[task_a_name] = task_a

        for j in range(i + 1, len(task_names)):
            task_b_name = task_names[j]
            task_b = tasks[task_b_name]

            if task_context_similarity(task_a, task_b):
                # Prompt for manual confirmation
                print(f"Suggest merging '{task_a_name}' and '{task_b_name}'")
                user_input = input("Do you want to merge? (y/n): ")
                if user_input.lower() == 'y':
                    # Merge logic
                    merged_tasks[task_a_name]['next'].extend(task_b.get('next', []))
                    # Add redo when blocked transition
                    merged_tasks[task_a_name]['next'].append({
                        'target': task_b_name,
                        'label': "redo when blocked"
                    })
                    print(f"Merged '{task_a_name}' with '{task_b_name}'.")
                else:
                    merged_tasks[task_b_name] = task_b

    return merged_tasks, issues

def format_for_visualization(tasks):
    visual_data = {"states": [], "transitions": []}

    for task_name, task_details in tasks.items():
        # Create state entry
        state = {
            "name": task_name,
            "description": task_details.get('doc', {}).get('description', '')
        }
        visual_data["states"].append(state)

        # Create transitions
        for transition in task_details.get('next', []):
            transition_info = {
                "from": task_name,
                "to": transition['target'],
                "label": transition.get('label', 'redo when blocked')  # Use default label
            }
            visual_data["transitions"].append(transition_info)

    return visual_data

# Example usage
tasks_file_path = 'path/to/tasks.yaml'  # Update with actual path
tasks = load_tasks(tasks_file_path)
merged_tasks, issues = merge_tasks(tasks)

# Save the merged tasks back to a new file
save_tasks(merged_tasks, 'path/to/merged_tasks.yaml')  # Update with desired output path

# Generate visual data
visual_data = format_for_visualization(merged_tasks)
with open('path/to/visual_data.yaml', 'w', encoding='utf-8') as file:
    yaml.dump(visual_data, file, default_flow_style=False, allow_unicode=True)

# Report any issues found
if issues:
    print("Issues found during merging:")
    for issue in issues:
        print(issue)
else:
    print("All tasks merged successfully.")


這樣的腳本能夠自動化整理過程，減少人工介入的必要。如果自動合併過程中出現問題，腳本會生成報告以供檢查。

[crazysmile-PhD]

@Alan-Charred 怎麼與你聯絡，郵箱還是什麼的

[Alan-Charred]

（挠头）好像 github 没有好用的私信功能。我们先在帖子下面交流吧，也方便其他人参与讨论。

您的意思是通过脚本进行初步筛查以减少重写的工作量。是个好主意！
关于可视化的部分我还得再想想（挠头）。
您先关注之前那个 discussion 下的动态吧，我这个帖子估计得等一阵子了（还是得先忙论文）。

[crazysmile-PhD]

我的意思是說你有沒有你自己的郵箱因為我在你的個人資料，裡面沒看到你的聯絡方式（因為用這個慢慢回覆的話很難溝通，有些文檔需要調適的時候，可能會變得很沒效率，再加上不會有人一個一個評論去看，只要把重要貼出來就好了，可視化早就用好了?我都打好了啊(●'◡'●)
1.新增的 "redo when blocked"：在合併任務時，將 "redo when blocked" 轉換標籤自動添加到 next 列表中，這樣在可視化時能夠簡化展示。
2.可視化數據的生成：在生成可視化數據時，將轉換標籤設置為 "redo when blocked" 以提高可讀性，並清楚表達任務之間的關係。

[crazysmile-PhD]

[ABA2396]

我有点没看懂，maa 有什么地方用到 yaml 和 csv 了吗？
自動格式化字段，如日期、時間、貨幣和布爾值，並處理嵌套字典和列表。 又是哪里的代码提到了

[Alan-Charred]

#10742

素材 +1
一直以来我都倾向于使用较小的 roi。一般是我裁剪 template 时所用的 roi 上下左右各留出 10px 的冗余。
然而我忽视了外服适配，导致了这个 issue 的产生。事实证明，在这种同时带图标和文字的按钮上，图标的位置是会变化的。如果以后再写类似的任务，我或许应当从一开始就让 roi 占据整个按钮中心的位置——唔，可是我怎么知道外服不会拉长这个按钮呢——不好办不好办……总之至少在左右给出更多的容错空间。
这时候我们可能会选择，是为所有服务器增大 roi，还是为单个服务器调整 roi 位置。鉴于模版匹配是很快的操作，我本人倾向于前者，除非我们真的很希望通过压缩 roi 大小来挤出那可能只有几毫秒的运行时间。——真的有几毫秒吗？

[Manicsteiner]

如何选择 MatchTemplate 与 OcrDetect

以我个人的习惯和经验来说，尽可能对所有目标内容为常规文字的内容使用 OcrDetect，无法使用的再改用 MatchTemplate。

OcrDetect 的优缺点

• 可以热更新推送，这对于需要及时推送的新活动内容非常重要
• 结果明确
• 通过添加 ocrreplace 可以实现一定的纠错能力
• 对于非常用字识别不准，比如 黍 ，不过一般会是固定的几个常用字作为结果，一般通过 ocrreplace 就可以纠正
• 对于花里胡哨的背景内容，可能会识别出不存在的文本
• 相似文字间可能会识别错误，一般通过 ocrreplace 可以纠正，过于相似的可以添加到 ocr_config.json 的 equivalence_classes 中（目前日服独有）
• 无法判断文本内容是否完整
  • 比如 红云 红，远山 山，有一部分文字未被扫进识别区域或被卡在屏幕外的话有可能识别为其他内容，尤其是左右滑动的面板的内容，理论上无法避免
  • 再比如日服已经出现的 ベナ ペナンス，国服的干员名识别要求全字匹配，而日服则只需要包含指定文本，此前的解决方法是在正则表达式中限定开头结尾，使这一条变成全字匹配，但是战斗中的识别会因为背景杂乱而追加一些不存在的文字，目前的方案是要求后续内容不与其他冲突词条相同 "^ベナ[^ンソシ]" ，这必须要人力搜索和判断
• 目前无法拼接有换行的文本
  • 比如肉鸽投资时或塌缩增进、衰减时右上角的弹窗，每一行的内容都不具有独特性，会难以区分
  • 理论上可以实现，桃一个
• 无法识别竖排文本（DT-6，不敢想象外服的迷宫饭联动该怎么办）
• 无法识别过于花哨的艺术字 （WBChapterToWB）
• 字号过小时可能无法识别 （SN-8）
• 文字有较大倾斜角度时无法识别 （ICChapterToIC）
  • 这个问题或许可以通过截取区域后旋转图片再识别解决，对于固定位置的小图标来说，可以不考虑坐标改变，识别成功直接点击原目标区域即可，但对于大区域内找指定文本的来说就必须考虑坐标变换，而且旋转图片的算法相当耗时，且有进一步的画质损失

MatchTemplate 的优缺点

• 什么都能用
• 某种程度上讲，精确
• 目前不能热更新推送
  • 尤其是对于新活动来说，首先要开服进游戏才能截取图片模板，然后再测试、进主线、发测试版，以目前的更新方式来说相当麻烦
• 可以通过特定手法从复杂背景中提取需要的内容，不过效果如何就不好说了
• 反馈结果是个0至1之间的浮点数置信度，虽然可以手动修改这个数值的限制，但是高了低了都可能出现意料外的情况
• 任何的修改字号、色号都可能会导致匹配失败
  • 比如颜色在0-255的尺度上变动十几二十几，人眼可能看不出来，但计算机就会认为内容不匹配 (日服 无法识别家具掉落 #7275 (comment))
  • 小幅度的改变UI大小和字号 chore: YoStarKR modified ocrReplace and template image #8418
• 对于一些文字内容，如果会因为分辨率改变换行规则，将完全无法使用，好消息是目前没有
• 对于花里胡哨的背景内容和小而简单的目标模板，可能会识别到不存在的内容 fix: 避免识别到不存在的连续作战图标 #8951
• 有些画面会在区域边缘添加阴影效果，导致正常的图片模板无法识别 （feat: 活动商店购物 #10111 未上传内容，商店下侧的物品边框会有更重的阴影）

[Alan-Charred]

原来如此原来如此，是否支持热更新是一个我从未考虑过的角度，感谢分享！
我之前想的是，我们的 OCR 经常出奇怪的字，而且还得考虑全语言适配，不如尽量模版匹配，比 OCR 还快一些。
因此即便可以识别文字，我也偏向于做模版匹配（一般文字边上有个icon之类的）。一来是简化国际服适配，免得 Yostar 在国际服搞了什么小字体，二是得死死盯着大家反馈的识别错误，更新几轮 OcrReplace 才能放松筋惕。（有时候你甚至怀疑，这几个简单的字符怎么还能识别错）

虽然我偏好模版匹配，但是在半透明背景下纯色图案的模版匹配，依然是个大问题。现在越来越多的半透明元素出现在 ui 中。极端情况下 Android 模拟器用户仅可以刚刚超过 0.8 一点的分数通过检测，而使用 PlayCover 的 M 芯片 Mac 用户的匹配分数就更低了。寻找对主体形状更敏感、对半透明背景容错率更高的模版匹配方法也在我的 Todo 里。
另外，一直以来，我认为那些 Icon 的位置是固定的、统一的。近期的一个 issue #10742 让我意识到部分按钮在国服和国际服上的位置有区别（由于边上的文字长度变化，随之左右浮动），模版匹配的便利性又低了一些。

模版匹配不支持一些简单的形变，一旦模版本身需要略微改动，就必须得等下一个版本，另外新功能支持更慢更费劲一些，是一个我之前没有考虑过的问题（一直在做旧的模式没有和时间赛跑过哈哈哈）。

我之后如果用什么怪方法做模版匹配，也会发到这个帖子来作为素材。（越来越多需要考虑的东西了）
（还是先督促大佬们把 OCR 的模型升级一下吧。

[Alan-Charred]

总之我目前的一个原则是，模版匹配不应用于带文字的内容。如果模版中带有 OCR 能精确识别的文字，那我估计会想换成 OCR。