一、核心原理：StdMode与Shape的对应关系
成捆物品无法解包，根本原因是物品数据库（StdItems.DB）中“单个物品”与“捆装物品”的字段对应关系断裂。系统无法通过Shape值找到解包后的目标物品。
关键字段逻辑：
• StdMode（物品大类）：0 代表普通消耗品（如单瓶药），31 代表捆装物品（如六包药）。
- Shape（物品子类/标识）：这是连接单件与成捆的唯一桥梁。
• AniCount（功能参数）：在解包逻辑中，它通常存储对应的捆装物品Shape值。
正确对应规则（以强效金创药为例）：
物品类型 物品名称 StdMode Shape AniCount 逻辑说明
单个物品 强效金创药 0 0 100 它的AniCount指向Shape=100的捆
捆装物品 超级金创药 31 100 1 它的Shape等于单个药的AniCount
如果“强效金创药”的AniCount不是100，或者“超级金创药”的Shape不是100，双击解包就会失败。
二、DB数据库修正步骤（以GOM/HERO引擎为例）
请使用DBC2000或数据库编辑器打开 MirServer\Mir200\DB\StdItems.DB，按以下步骤排查：
1. 检查并修正“单个物品”条目
找到无法解包的那个单个物品（如“强效金创药”）。
• 确认StdMode：必须为 0。
• 查找AniCount值：记录下该字段的数字（假设是100）。这个数字必须与对应的“捆”的Shape一致。如果此处为0或空，解包必然失败。
2. 检查并修正“捆装物品”条目
找到对应的捆装物品（如“超级金创药包”）。
• 确认StdMode：必须为 31。
• 核对Shape值：此处的Shape必须等于第1步中记录的AniCount值。如果“单个药”的AniCount是100，那么“捆药”的Shape也必须是100。
• 检查AniCount：捆装物品的AniCount通常表示药品类型（1=红，2=蓝，3=红蓝），若设置错误可能导致解包后无法自动使用。
3. 修正示例
错误情况：双击“超级金创药包”无反应。
排查：
1. 查“强效金创药”：StdMode=0, AniCount=100。
2. 查“超级金创药包”：StdMode=31, Shape=101（错误！应为100）。
修正：将“超级金创药包”的Shape由101改为100，保存DB，重启M2加载数据库。
三、GOM引擎特殊配置：UnbindList.txt
GOM引擎除了DB设置，还依赖 MirServer\Mir200\Envir\UnbindList.txt 文件。如果DB字段正确仍不能解包，99%是此文件配置错误。
文件格式：
;Shape值 解包出的物品名 数量 类型(1红 2蓝 3红蓝 4卷轴)
100 强效金创药 6 1
101 强效魔法药 6 2
排查重点：
1. Shape值对应：第一列的100必须与DB中“捆药”的Shape值完全一致。
2. 物品名对应：第二列必须是解包后物品的准确名称（与DB的Name字段一致），不能有错别字。
3. 文件编码：该文件必须为ANSI编码，若保存为UTF-8可能导致M2无法识别。
四、常见报错与快速排查清单
1. 双击无任何反应：DB中“捆装物品”的StdMode不是31，或Shape值在UnbindList.txt中不存在。
2. 解包出错误物品：DB中“单个物品”的AniCount与“捆装物品”的Shape不匹配，指向了其他物品。
3. 解包后数量不对：UnbindList.txt中第三列的“数量”设置错误。
4. 转换版本后失效：HERO转GOM引擎时，常因UnbindList.txt未配置或DB的AniCount遗留旧值导致。建议使用引擎包自带的“捆绑DB转换”工具处理。
自检顺序：先核对DB的StdMode和Shape对应关系 -> 再检查UnbindList.txt的配置行 -> 最后重启M2并重载物品数据库。
