Why I'm here posting this is a long story.
I probably won't be around to reply to any questions about this, so if there's something you need clarification on and SP can't clarify it, feel free to drop me an email. Shouldn't be too complicated to do though.
There isn't some kind of script file somewhere that describes how enemies react to Quote: each specific enemy and weapon is hardcoded into the game. Every enemy/weapon in the game also defines their frames in this fashion: the game literally says something to the ends of "To draw this frame, set X to this, set Y to this, set the width to this, and the height to this." So don't bother looking for a friendly list of positions because they don't exist.
Luckily all frames are grouped together, so once you find the appropriate enemy you can edit every frame without having to dig through the code and trying to make sense of what's going on. So, I guess it's ALMOST a friendly organized list of positions.
A frame looks like this...
mov [ebp-00A0],00000000
mov [ebp-009C],00000060
mov [ebp-0098],00000010
mov [ebp-0094],00000070
It helps immensely if you have an assembly dump. This particular bit of code comes from 0x0043E1E9 and is the first of a series of frames that define sprite ID 117 (dunno which one that is, I'd have to look it up.)
Once you know what the structure looks like, it'll leap right out at you. I believe there's an NPC AI pointer table sitting around somewhere - use that to look up where in the code the NPCs are handled, and then look for blocks of code like above. I believe SP has my notes anyway, so I know there's a list of offsets available
somewhere.
Here's a hands-on example: the treasure chest. Its three frames are defined as follows...
(at 0x0429BF6) { 0x00F0, 0x0000, 0x0100, 0x0010 }
(at 0x0429C12) { 0x0100, 0x0000, 0x0110, 0x0010 }
(at 0x0429C2E) { 0x0110, 0x0000, 0x0120, 0x0010 }
In hex, it looks like this...
0x00429BF6 - C7 45 D0 F0 00 00 00: mov [ebp-0030],000000F0 ; left : 240
0x00429BFD - C7 45 D4 00 00 00 00: mov [ebp-002C],00000000 ; top : 0
0x00429C04 - C7 45 D8 00 01 00 00: mov [ebp-0028],00000100 ; right : 256
0x00429C0B - C7 45 DC 10 00 00 00: mov [ebp-0024],00000010 ; bottom: 16
0x00429C12 - C7 45 E0 00 01 00 00: mov [ebp-0020],00000100 ; left : 256
0x00429C19 - C7 45 E4 00 00 00 00: mov [ebp-001C],00000000 ; top: 0
0x00429C20 - C7 45 E8 10 01 00 00: mov [ebp-0018],00000110 ; right: 272
0x00429C27 - C7 45 EC 10 00 00 00: mov [ebp-0014],00000010 : bottom: 16
0x00429C2E - C7 45 F0 10 01 00 00: mov [ebp-0010],00000110 ; left: 272
0x00429C35 - C7 45 F4 00 00 00 00: mov [ebp-000C],00000000 ; top: 0
0x00429C3C - C7 45 F8 20 01 00 00: mov [ebp-0008],00000120 ; right: 288
0x00429C43 - C7 45 FC 10 00 00 00: mov [ebp-0004],00000010 ; bottom: 16
The first 3 bytes are used to determine the instruction (MOV) and addressing mode ([ebp-xxxx]). Because these are negative numbers, they'll sometimes be represeted in a different form. The last 4 bytes on each line is what interests us though: they're the coordinates of all 3 frames a chest can have.
It should be trivial to edit the frames a chest uses, now.
(While I'm at it, if you're doing a little assembly hacking, the frame is stored in [eax+0068], assuming eax is set to [ebp-0008] to point to the sprite data earlier.)