510dcf29d8
Method-diffing settled the structure but not the semantics, so nothing is named this time. 26 damage_unit vt76 sub_8226ACD0 (67) opcode 800 97 sites 28 vt84 sub_82268F98 (69) opcode 801 410 sites 29 vt88 sub_822690B0 (69) opcode 802 164 sites 101 vt276 sub_822691C8 (78) opcode 802 133 sites (broadcast) 28 and 29 differ in two words only -- the opcode (0x21BA vs 0x22BA) and a descriptor pointer 8 bytes apart -- and are otherwise instruction-identical. All three take (unit, double). 26 differs from both by one guard: it rejects only state 3, while 28 and 29 reject states 1 and 3. The operand distributions separate them: 26 97 sites 7 distinct [0, 100] 0 x69, 80 x10, 100 x6 28 410 sites 13 distinct [0, 2000] 200 x116, 120 x76, 300 x74 29 164 sites 6 distinct [0, 100] 0 x64, 100 x53, 50 x38 26 and 29 are percentage-shaped; 28 is an absolute quantity an order of magnitude larger. That casts doubt on an existing name. damage_unit (26) passes 0 in 69 of its 97 calls -- dealing zero damage is a no-op, so 71% of its call sites would do nothing, while SETTING a percentage-valued property to 0 is a natural thing to do 69 times. 29 has the same shape. The name predates this session and I have not withdrawn it, but it should not be relied on. Where this stopped: the three commands' descriptors at 0x820A8D10/+8/+16 point into 0x8210E5xx, which is BELOW the disassembly DB's range (it starts at 0x82150000) and holds no code, so that route cannot reach an execute method. Opcodes 800-802's semantics need the interpreter command table instead. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PMRJjbxLqZtsb5Vb7KunPE