239 个 TYPE 的行为解释

本文回答什么：[EFFECT] 块写成某个样子，游戏里到底会发生什么。 239 个 TYPE 的数值槽对照表 解决的是「能填哪些键」，本文解决的是「填了会怎样」， 239 个 TYPE 的实例速查 则给出每个类型的真实数据样例。

分析依据：基于 IDA 对 32 位可执行文件 Torchlight2.exe（基址 0x400000）的逐指令反汇编分析。 两个分派器的字节索引表与跳转表已逐字节读出并交叉校验（表长与 case 数完全吻合）， 所以「哪些类型有分支、哪些落空」可证。消费方一侧是逐调用点回读得到的，完整度见第 8 节。

1. 判定框架：六条路径 ​

一个效果挂上去之后，引擎里只有六个地方会因为它的 TYPE 做出不同的事。

1.1 两个跳转表是怎么解出来的 ​

两个分派器都编译成 MSVC 的「字节索引表 + 跳转表」双层结构，可以直接读表得到完整映射。

; INSTANT —— CUnit__executeInstantEffect
0055971C  mov   eax, [edi+1Ch]              ; eax = eff->TYPE
0055971F  add   eax, 0FFFFFFFAh             ; -6        ← 覆盖 TYPE 6..236
00559722  cmp   eax, 0E6h
00559727  ja    def_559736
0055972D  movzx eax, ds:byte_55CB6C[eax]    ; 231 项字节索引表
00559736  jmp   ds:jpt_559736[eax*4]        ; 54 项跳转表，default 槽位 = 53

; 挂载 —— CUnit__applyEffectToSelf_dispatch
005626E2  mov   ecx, [edi+1Ch]
005626E5  add   ecx, 0FFFFFFF9h             ; -7        ← 覆盖 TYPE 7..228
005626E8  cmp   ecx, 0DDh
005626EE  ja    def_5626FB
005626F4  movzx ecx, ds:byte_564484[ecx]    ; 222 项字节索引表
005626FB  jmp   ds:jpt_5626FB[ecx*4]        ; 27 项跳转表，default 槽位 = 26

表长与 case 数完全对得上（231/54、222/27），无剩余、无越界。 tick 分派器没有跳转表，是一长串 cmp dword ptr [reg+1Ch], <类型号> 的 if 链。

2. 路径 1：数值查询 ​

效果挂上时，数值被累加进 CEffectManager+0x60 的 float statCache[239]，下标就是类型号—— 这一步对所有类型无差别执行。真正决定行为的是有没有代码去查。

查询走 CUnit__getStat(类型号, 伤害类型, 是否向上取整)，全二进制 371 个调用点。 调用约定是 push 取整标志; push 伤害类型; push 类型号; call——紧邻 call 的 push 就是类型号。

除 CUnit__getStat 外还有三个包装器直接调 sumStatOfType_filtered： CBaseUnit__getEffectStat_selfPlusInventory（0x518930，16 个调用点，15 个在 CCharacter__resolveStrikeHit 里）、 sub_5188F0、sub_512C40。漏掉这几个包装器会让一整批类型看起来「没人用」—— 吸血、偷蓝、击退、腐蚀护甲全在那 16 个点里。

2.1 伤害加成是七个桶，不是一个数 ​

10 DAMAGE BONUS 与 25 PERCENT DAMAGE BONUS 按伤害类型 0–6 各记一份账， 效果的 DAMAGE_TYPE 决定进哪个桶，伤害结算逐桶取：

0052DDC1  push 0 / push 6 / push 19h  → getStat(25, 6, 0)   ; 桶 6（通用）
0052DDDC  push 0 / push 0 / push 19h  → getStat(25, 0, 0)
0052DE17  push 0 / push 2 / push 19h  → getStat(25, 2, 0)
0052DE69  push 0 / push 3 / push 19h  → getStat(25, 3, 0)
0052DEBB  push 0 / push 4 / push 19h  → getStat(25, 4, 0)
0052DF0D  push 0 / push 5 / push 19h  → getStat(25, 5, 0)
0052DFAD  push 0 / push 2 / push 0Ah  → getStat(10, 2, 0)   ; DAMAGE BONUS 同理

DAMAGE_TYPE 写错等于把加成放进没人取的桶。26 PERCENT DAMAGE TAKEN 的读取方 CUnit__getDamageTakenPct_stat26（0x51ADF0） 是「按传入伤害类型查一次 + 桶 6 查一次」，桶 6 就是那个「对所有元素通用」的桶。

2.2 近战与远程是一对镜像函数 ​

sub_52DA30 与 sub_52E9D0 各 0xF95 字节，结构逐行同构，区别只在基础伤害类型： 近战读 getStat(0, …)（MELEEDAMAGEBONUS），远程读 getStat(1, …)（RANGEDDAMAGEBONUS） （0x52F53D 处 push 0; push 7; push 1）。 sub_52BD90 / sub_52C170 是另一对同样的镜像。改一边不改另一边，近战和远程的行为就会不一致。

2.3 物品需求减免是按 UNITTYPE 选型的 ​

sub_57D930（另有 0x57DA30／0x57DB30／0x57DC30 三份副本）先无条件取 93 REDUCED ITEM REQUIREMENTS，再按物品的 UNITTYPE 追加一个专用类型：

最后 需求 = max(0, 原需求 − 减免合计)。 注意 34 PERCENT ITEM REQUIREMENTS 不在这条链里，它没有任何消费方（见第 8 节）。

2.4 抗性间址表把「全部抗性」错读成类型 0 ​

CBaseUnit__getResistanceOfType(idx)（0x520A40）按 idx 取一个类型号：

dword_216FD9C = { 35, 36, 37, 38, 39, 40, 0 }
                   ↑物理 ↑魔法 ↑火  ↑冰  ↑电  ↑毒  ↑ idx==6「全部」

前六项是对应的 * DEFENSE 类型，第七项是 0，也就是 MELEEDAMAGEBONUS。 所以查询「全部抗性」时，引擎把这个单位的近战伤害加成当成抗性加了进去。这是错位，不是设计。

另外这个函数里的 switch 映射也不按 idx 递增： case 2 → 219 INNATE FIRE、case 3 → 218 INNATE ICE、case 4 → 220 INNATE ELECTRIC、case 5 → 221 INNATE POISON。

2.5 DAMAGE_TYPE 只有六个类型真的会读 ​

DAMAGE_TYPE 是数值查询路径的过滤参数，存在 CEffect+0x14。 它不是每个效果都有用——绝大多数类型写了等于没写。先看这个键是怎么进来的。

七个合法值，运行时构造。 名字表在 byte_3B9CAB0，由静态构造函数 sub_1F876C0 填：

7 不是合法值，是「不过滤」的哨兵。CEffectMgr__sumStatOfType_filtered（0x7AEA40）第一行就是 if (damageType == 7 && !onlyLocalSource) return statCache[typeId];（0x7AEA53）—— 直接返回 239 缓存、连表都不扫。绝大多数 getStat 调用传的就是 7。

解析过程（CEffect__ctorFromDat 0x7AB479 起）：

默认值 "PHYSICAL" → getString("DAMAGE_TYPE") → toUpperW
  ↓
if (var_1F9)  { +0x14 = 1 /*Magical*/; 跳过解析 }      ← 0x7AB4DB
else          逐项比 7 个名字（cmp ebp, 0C4h = 7 × 28）
                命中 → +0x14 = 序号                    ← 0x7AB545
                全不命中 → **不写 +0x14**              ← 落 0x7AB548

两处细节都要紧。先说第一处。

九个类型被强制成 Magical，键根本不读 ​

var_1F9 由 0x7AAC03 的跳转表决定。这张表本身已经在 数值槽对照表 §7 的「特判」列里记过（代号 M， 那边引的是索引计算处 0x7AABEF）——本节补的是它的逐字节解码与数据侧后果。

它是本系列解出的第四张跳转表（前三张是 INSTANT、挂载、施法模式）： 索引表 idx_forceMagical_117（0x7ABB54）共 117 项、索引式为 TYPE - 2（覆盖 TYPE 2..118）， 跳转表 jpt_7ABB4C 两项：slot 0 = 0x7AAC0A（置位）、slot 1 = 0x7AAC0F（默认，不置位）。 逐字节解出落 slot 0 的九个类型，与 IDA 解析的 case 列表一致：

九个全是 DEFENSE 家族。对它们，+0x14 被无条件写成 1（Magical）， DAMAGE_TYPE: 那一行连读都不读。 原版自己在这九个类型上写了 166 处 DAMAGE_TYPE，MOD 库 1269 处，合计 1435 处全部无效。

v6 = getStat(17, 7, 0)   // 不过滤，拿走全部 PERCENT DEFENSE
v2 = getStat(17, 6, 0)   // 只要 DAMAGE_TYPE == 6（All）的那些
体力 = base + ceil((v2 + v6) * 0.01 * base)

值写错了，+0x14 干脆不被写入 ​

匹配循环跑完七项都没命中时，0x7AB545 的 mov [esi+14h], eax 被跳过。 基类构造 sub_405910（0x405910）只设 vftable 和 this[1]，也不碰 +0x14； 函数内对 [esi+14h] 的写入总共只有两处（0x7AB4DB 与 0x7AB545）。 未追分配器，所以无匹配时该字段的实际取值取决于这块内存原本是什么。

实测数据里出现的非法值：

DAMAGE_TYPE:MAGIC 是这里面最值得说的：合法名字是 MAGICAL， 少一个 AL 就整条匹配不上。MOD 库里 168 个 52 DAMAGE 块这么写—— 而 52 是真的会按伤害类型分桶的类型（CEquipment__bakeDamageEffectsIntoTable）。

六个真读的类型 ​

其余情况下 +0x14 只有在消费方传了非 7 的过滤值时才有意义。逐调用点核实后， 只有六个类型存在这样的消费方：

8／23 的用法见 2.4 节的 getResistanceOfType——每种抗性都做两次读： 一次按具体伤害类型（变量），一次按 6（All），两者相加。 所以在护甲类效果上写 DAMAGE_TYPE:FIRE 只加到火抗，写 ALL 才是全抗。

汇总 ​

两库合计 48263 个 [EFFECT] 块写了 DAMAGE_TYPE，分布在 101 个类型上：

也就是说 9980 个块的 DAMAGE_TYPE 是白写的， 其中原版自己占 538 处。最典型的是 37 FIRE DEFENSE 写 DAMAGE_TYPE:FIRE—— 原版写了 43 次，一次都不生效。

2.6 [EFFECT] 块里写了、但没人读的键 ​

上一节只查了 DAMAGE_TYPE 一个键。同样的问题对所有键都成立，索性一次查完。

哪些键会被读，有两个来源：

1. CEffect__ctorFromDat（0x7AAA30–0x7ABB4B）里所有 push offset 的键名字面量，共 24 个：
   TYPE ACTIVATION DURATION NAME LEVEL ICON LINK_NAME PARTICLE_FX UNITTHEME
SAVE EXCLUSIVE NONMAGICAL REMOVEONOWNERDIE USEOWNERLEVEL DISPLAYPOSITIVE
MODIFIERISBONUS DISPLAYMAXMODIFIER NOGRAPH GRAPHOVERRIDE SOAKSCALE
DAMAGE_TYPE STATMODIFYNAME STATMODIFYPERCENT STAT_SOURCE_TYPE
2. EFFECTSLIST.DAT 里那一行给出的五个槽位别名（239 行去重后共 62 个不同名字， 见 数值槽对照表）。

数据侧：两库的 [EFFECT] 块里一共出现过 98 种键名，其中 84 种能对上上面两个来源， 14 种对不上。逐个查证后分成四类：

甲、二进制里根本没有这个字符串 —— 必然无效 ​

宽窄两种编码都搜过，全码段无此串，所以不可能有任何代码读它。

合计 74 处。

.text:0055A957   mov  eax, [edi+14h]      ; 效果的 DAMAGE_TYPE
.text:0055A95E   cmp  eax, 6              ; 是 All 吗
.text:0055A961   jz   short loc_55A97D
.text:0055A965   push eax                 ; ← 不是 All，就拿它当过滤值
.text:0055A966   push 19h                 ;   类型 25 PERCENT DAMAGE BONUS
.text:0055A96A   call CUnit__getStat

乙、字符串存在，但读它的函数不碰效果节点 ​

合计 51 处。 VALUE1／VALUE3 这一类很好理解——把「表里那一行的列名」当成了「效果块里能写的键」。 正确写法是查该类型的槽位别名（MIN／MAX／CHANCE／…），别名逐行不同。

丙、由 CEffect__ctorFromDat 的调用方在同一个节点上读 —— 有效 ​

TARGET（848 处）不在效果解析器的 24 个键里，但它确实会被读： sub_7C0FA0（0x7C10B1）与 CSkillEffectAndAffixes__ctorFromDat（0x6C6B8C 等三处） 都从同一个数据节点取这个键，而这两个函数正是 CEffect__ctorFromDat 的调用方。 键的归属不等于「谁 new 了这个对象」，这一类不算白写。

丁、未定论 ​

MINLEVEL（254 处）与 MAXLEVEL（244 处）在二进制里存在， 但引用它们的只有 ItemDB__buildIndexFromDats（0x65EBD1／0x65EC4F）与 sub_660A00， 都与效果节点无关。不过这两个键也可能是嵌套子块的键被本次扫描一并计入了 （扫描取的是 [EFFECT] 到最近一个 [/EFFECT] 之间的全部 <类型>键:值 行）， 所以这里不下结论。AFFIX（1 处）同理。

3. 路径 2：直接扫表 ​

CEffectMgr__accumMissileReflect（0x7AE710）不走 statCache， 自己扫 PASSIVE + DYNAMIC 两张表，只挑 TYPE == 60 MISSILE REFLECT：

单条反射量 = (evalSlot(eff,2) + evalSlot(eff,3)) * 0.005     // (DMGPCTMIN+DMGPCTMAX)/2/100
合成概率   P = 1 - (1 - p_old) * (1 - p_new)                 // 独立事件叠加，永不超 100%
合成量     A = (a_old * p_old + 单条反射量 * p_new) / P       // 按概率加权的均值

4. 路径 3：按类型的布尔／查找查询 ​

这条路径只问「身上有没有这个类型的效果」，不关心数值。 入口是 CUnit__hasActiveEffectOfType（0x512C90，20 个调用点）、 CEffectMgr__hasEffectOfType（0x7AE100）、CEffectMgr__findEffectByTypeAndName（0x7ADEE0）。

5. 路径 4：INSTANT 执行 ​

DURATION:INSTANT 的效果不进三张表、不参与 tick，执行一次就丢。 寄存器约定：esi = 被作用单位，edi = CEffect*。56 个类型有真分支：

两组共用槽位：6/123（0x55A856）与 7/124（0x55A92B）在 INSTANT 路径上行为完全相同， 区别只在数值查询侧的消费方不同；213 RETARGET 与 214 AGRO 共用 0x559ADF。

6. 路径 5：挂载时执行 ​

28 个类型有真分支：

227 SKILL ENABLE / 228 SKILL DISABLE 有前置特例：函数开头先判 CEffect+0x20 == 2， 命中就走 CItem_AttachDynamicEffect 直接返回，根本到不了 switch。

00564308  cmp  eax, 1            ; eax = CEffect+0x20（宿主种类）
0056430B  jz   loc_564316
0056430D  test eax, eax
0056430F  jz   loc_564316        ; (0, 1) → 执行挂接
00564311  cmp  eax, 2
00564314  jnz  loc_56432C
00564316  call CItem_AttachDynamicEffect
0056432C  call CUnit__rollSkillToggleDuration
00564344  call CCharacter__isHostileTo

6.1 分支里反复出现的几个族 ​

拆完 56 + 28 个分支后，重复的结构比独特的逻辑多得多：

• 状态抗性统一模式：CUnit__getStat(<对应抗性类型>) → CUnit__applyDifficultyResistBoost → 概率判定。难度加成在抗性之上二次放大，所以同一个概率在不同难度下的实际命中率不同。
• 元素状态四兄弟 106/107/108/109：挂载路径与 tick 路径各有四份逐条同构的副本。
• 传送四兄弟 157/158/235/236：INSTANT 路径四份同构，前缀完全一致，只在落位函数（teleportToClampedPoint vs teleportRandomNearby）与粒子标志上分叉。
• 属性操作 3×2 矩阵 146–151：{addToStat, setStat, removeStat} × {普通, 按等级}。
• 属性永久化七兄弟 114–120：hasUnitType → evalSlot → __ftol2_sse 同一个三调用模式。
• 充能族 168/169/171/181/182：前三个是单调用薄封装，后两个把充能换算成属性。

7. 路径 6：每帧 tick ​

CUnit__tickActiveEffects_dispatch 没有跳转表，是一长串 cmp dword ptr [reg+1Ch], <类型号> 的 if 链， 共 45 处比较点。

7.1 两条 OR 链 ​

第二条链值得看一眼形状——20 次比较，20 个 jz 指向同一个地址：

0056701A  cmp  dword ptr [eax+1Ch], 4Ah   ; 74  CAST SKILL
0056701E  jz   loc_5671B9
00567030  cmp  dword ptr [ecx+1Ch], 4Ch   ; 76  CAST SKILL AT TARGET
00567034  jz   loc_5671B9
          …（中间 17 次同构比较）…
005671B3  cmp  dword ptr [eax+1Ch], 4Bh   ; 75  CAST SKILL ON TARGET
005671B7  jnz  short loc_5671C6
005671B9  mov  ecx, [esp+228h+var_218]    ; ← 20 条 jz 的共同落点
005671BD  cmp  dword ptr [ecx+1BCh], 0
005671C4  jnz  short loc_567205

命中的 20 个类型恰好等于 CAST SKILL ON x 家族的全部成员，一个不多一个不少。

7.1.1 这条链是「清理」，不是「门禁」 ​

两处需要读准，否则会得出完全相反的结论。

第一，整段只在效果到期时才跑。 进入 OR 链前有一道 cmp var_1EC, 0（0x567005）， 而 var_1EC 是「本帧到期」标志，在循环开头这样置位：

00566EEF  fld  dword ptr [edx+24h]        ; eff->DURATION
00566EF2  fld  dword ptr [edx+18h]        ; eff->elapsed
00566EF5  fadd [ebp+arg_0]                ; + dt
00566EF8  fcompp                          ; DURATION vs (elapsed + dt)
00566F01  mov  byte ptr [...var_1EC], 1   ; 到期 → 置 1
          …或者…
00566F08  mov  edx, [edx+28h]             ; flags
00566F0B  and  dl, 20h
00566F11  setz byte ptr [...var_1EC]      ; flags & 0x20 == 0 → 也置 1

第二，CUnit+0x1BC 不是标志位，是 CSkillManager*。CUnit__getOrCreateSkillManager（0x513840）惰性创建它： 0x51384B 判空、0x513894 写回。所以 cmp [ecx+1BCh], 0 问的是 「这个单位有没有技能管理器」，不是「某个开关开没开」。

合起来，这段的真实语义是：

若 效果本帧到期:
    若 TYPE ∈ {20 个 CAST SKILL ON x} 且 自己有技能管理器
        → 调虚表槽 90，把技能卸掉
    否则若 TYPE == 183 CAST SKILL ON DEATH FROM EFFECT OWNER
        且 eff->来源单位 存在 且 来源单位有技能管理器      ← 查的是**来源**，不是自己
        → 同样调虚表槽 90

7.1.2 CAST SKILL ON x 的真实机制：装一个真技能上去 ​

顺着虚表槽找下去，这一族的完整生命周期是：

7.1.3 触发端：从事件到施法 ​

装上技能之后，谁在什么时候把它放出来？整条链有三段。

第一段 —— 事件发生处直接 push 一个效果类型号。 入口是 CBaseUnit__fireProcEffects（0x53D3C0）：

fireProcEffects(this, chance@st0, eventType, other, bcast, srcSkill, strikeFlags)

fireProcEffects 内部：

若 bcast 且本地权威 → 发 NetUnitProcMsg 广播        （0x53D4A5）
CUnit__hasActiveEffectOfType(eventType)  ← 快速门    （0x53D4B1）
扫两个桶，挑出 TYPE == eventType 的效果               （0x53D4F7）
  每个: CEffectMgr__evalEffectValue → execProcCastSkill，返回 false 就 break
若有背包 → sub_7C8130 逐件装备再触发一轮             （0x53D588）

最后那一步值得注意：装备上的 proc 是单独一轮，走 sub_7C8130 → sub_7CB870， 与身上效果的那一轮互不干扰。

第二段 —— 22 个触发点，逐个核实过的事件类型：

199 与 200 共用 0x54E2AF 这一个 call——0x54E279 推入 200 之后 jmp 过去， 近战／远程只是选了不同的常量。

第三段 —— execProcCastSkill（0x53C7E0）真正施放。

CEffect__evalSlot + rand_int_between            掷概率      （0x53C8EF / 0x53C916）
161 SPAWN UNIT ON DEATH 特判                                （0x53C8F7）
183 特判 → 查**来源单位**的技能管理器                        （0x53CA47 / 0x53CA66）
CSkillList__findSkill / CSkillMgr__findSkillByName  找已安装的技能
CSkillList__isSkillOnCooldown                    查冷却      （0x53CAD9 / 0x53CC8F / 0x53CD37）
第三张跳转表 → 决定施法模式                                  （0x53CDA5）
CSkillList__executeSkill                         施放        （0x53CB92 / 0x53CE0F / 0x53CE69 …）

第三张跳转表同样是「字节索引表 + 跳转表」结构，可以直接读表：

0053CD8D  mov   esi, [esi+1Ch]           ; eventType
0053CD90  lea   eax, [esi-4Ah]           ; -74     ← 覆盖 TYPE 74..211
0053CD93  cmp   eax, 89h                 ; 137
0053CD98  ja    def_53CDA5
0053CD9E  movzx eax, ds:byte_53D32C[eax] ; 138 项字节索引表
0053CDA5  jmp   ds:jpt_53CDA5[eax*4]     ; 6 项跳转表，default 槽位 = 5

解出来的真分支又是同样那 20 个类型（118 个落 default），分成五种施法模式：

四段合起来：

7.1.4 五种施法模式各自做什么 ​

五段的骨架一致——组装两个位置参数，然后 CSkillList__executeSkill。 位置靠 sub_61DCE0(unit, &vec3, 1) 取（把某个单位的位置写进栈缓冲）。区别全在取谁的位置。

sub_61DCE0(unit, &vec3, 1) = 取某个单位的位置写进栈上缓冲，五种模式都靠它组装 executeSkill 的位置参数。

7.1.5 锥形查询的实参与判定公式 ​

CLevel__queryUnitsInCone（0x5FC670）的签名：

queryUnitsInCone(this, out1, out2, Matrix4* xform, alignment,
                 float minDist, float halfAngleDeg, float maxDist, exclude, skill, …)

模式 2 传进去的三个浮点：

两个 DAT 键已确认到写入指令：

判定公式（0x5FC8B1–0x5FC988）：

1. 局部坐标 = 目标位置 × Matrix4::inverse(xform)
2. 把 Y 压平（v43 = 0.0），长度即距离
3. atan2(x, z) × 57.295826 即角度（度）
4. 命中 = 距离 ≤ minDist 或 ((|角度| ≤ 半角 或 (半角>0 且 距离<3.0 且 |角度|<30°)) 且 距离 ≤ maxDist) 或 (半角>20 且 (距离>1.5 或 |角度|>180))

7.1.6 CUnit+0x7DC：proc 的 1 秒内置冷却 ​

7.2 23 个逐类型动作块 ​

7.3 三处共享实现与一处跨路径回调 ​

• 227 SKILL ENABLE 与 228 SKILL DISABLE 共用 CSkillMgr__setSkillEnabledByName（0x5674CC）。

CUnit__tickDrawHealthMana（0x53F6A0）—— 229 / 230 的全部实现

槽位：MIN_PER_HEALTH／MAX_PER_HEALTH（或 MANA）、PULSE_RATE、RADIUS、MAX_TARGETS

1. 类型门：cmp eax, 0E5h(229) / cmp eax, 0E6h(230)（0x53F6ED / 0x53F6F4）
2. CEffect__evalSlot ×3 取 PULSE_RATE／RADIUS／MAX_TARGETS（0x53F703 / 710 / 71D）
3. CLevel__gatherUnitsInRadius（0x53F7BB）—— 范围抽取，不是单体
4. 229 分支（0x53F815）：floor(目标当前血) ≥ getMaxHealth 就跳过 —— 满血目标不被抽
5. CUnit__isLocallyAuthoritative 后再比一次满血
6. 目标状态 +0x314 ∈ {12, 50, 51} 时追加一道 +0x284 判定（0x53F87E–0x53F89E）
7. hasUnitType(0xA7)、hasStateNamed 两道排除（0x53F8A4 / 0x53F8D7）
8. sub_535570 + 虚表调用完成实际抽取；CEffect__playParticleFx 放特效

CUnit__tickDamageByMonsterCount（0x532660）—— 231 / 234 的全部实现

槽位：MIN_PER／MAX_PER、RANGE（槽 2）、MAX_COUNT（槽 3）、槽 4 被引擎占用

1. 只认 231 / 234，其余立即返回（0x5326C2）
2. 刷新周期 0.2 秒硬编码：当前时间 - evalSlot(eff,4) < 0.2 就跳过（0x532701）
3. CEffect__setSlotAndReroll(eff, 4, 当前时间) —— 槽 4 被当刷新时间戳写入（0x532712）
4. 按 findEffectByTypeAndName(26 或 25, eff->NAME) 找同名伙伴效果（0x532727 / 0x53273C）
5. CLevel__gatherUnitsInRadius 半径 = 槽 2 数到周围单位数
6. 值 = eff->+0xD4 × min(数量, MAX_COUNT)，写进伙伴效果的槽 0 与槽 1（0x5327F4 / 0x532817）

8. 239 行路径归属总表 ​

列的读法

• 被动／扫表／布尔 —— 该类型是否被路径 1／2／3 消费。
• INSTANT 分支 / 挂载分支 —— 处理代码地址；空白表示落 default，即无行为。这两列完整。
• tick 比较点 —— if 链里比较该类型的指令地址。
• 生效方式 —— 由前几列推出的结论。