Miscellaneous Forums > Scripting and Reverse Engineering
(FFVII PC) The **ab files
nfitc1:
So I put my mind to it yesterday and I found out quite a bit about those elusive **ab files in the battle.lgp archive (I don't know the PSX equivalent). Thanks to DLPB who discovered that the death animations are set there, it got me wondering more about the structure of the entire file. Let me share what I've learned. Because I don't want to keep typing "**ab file" I'll refer to them as animation script files or script files or maybe just "ab".
Each model grouping (aa**, ab**, etc) has an ab file, even backgrounds. They are at least 8 bytes in size and contain lots of info on how to group animations stored in the associated **da files. The models are assigned to actors which each get a large chunk of memory to determine lots of things like position, orientation, height, model info, and a bunch of other stuff. The chunks for each model are 6892 bytes in size and exist for three player characters, the battle background model, and up to six enemy models. This chunk is where the bulk of the info in the ab file goes, just in different places.
There's also another actor-related chunk that is 116 bytes in size. This also gets a few settings from the ab file.
The ab files are broken up into three chunks:
Header:
This is what I know very little about. It has some things related to rotation of the model and possibly defines "front" and "up" for the model. I DO know where it all maps to in memory (at least on the PC version) and most of it goes into that chunk I just mentioned.
--- Code: ---ab address memory size
0x00 0xBE1178 word
0x02 0xBE119F byte
0x04 0xBE118A word
0x06 0xBE1180 word
0x08 0xBE1182 word
0x0A 0xBE1184 word
0x0C 0xBF23E6 word
0x0E 0xBF23E8 word
0x10 0xBF23EA word
0x12 0xBE11A3 byte
0x13 0xBE11A4 byte
0x14 0xBE11A5 byte
0x15 0xBE11A6 byte
0x16 0xBE11A7 byte
0x17 0xBE11A8 byte
0x18 0xBE11A9 byte
0x19 0xBE11AA byte
0x1A 0xBE11AB byte
0x1B 0xBE11AC byte
0x1C 0xBE11AD byte
0x1D 0xBE11AE byte
0x1E 0xBE11AF byte
0x1F 0xBE11B0 byte
0x20 0xBE11B1 byte
0x21 0xBE11B2 byte
0x22 align word
0x24 translate dword
0x28 translate dword
0x2C translate dword
0x30 translate dword
0x34 translate dword
0x38 translate dword
0x3C translate dword
0x40 translate dword
0x44 0xBF23C4 word ;address of last actual script pointer (others may follow, but they are ignored?)
0x46 0xBF23C6 word
0x48 0xBF23C8 word
0x4A 0xBF23CA word
0x4C 0xBF23CE word
0x4E 0xBF23D0 word
0x50 0xBF23D2 word
0x52 0xBF23D4 word
0x54 0xBF23D6 word
0x56 0xBF23D8 word
0x58 0xBF23DA word
0x5A 0xBF23DC word
0x5C 0xBF23DE word
0x5E 0xBF23E0 word
0x60 0xBF23E2 word
0x62 0xBF23E4 word
0x64 0xBF23F0 word
0x66 align word
--- End code ---
I grouped them like that because that's the way the game stores them or loads them. I assume they're all related. Right now, we only really know what byte 02 does. That's the death animation.
The first word determines what type of actor it is. Most enemies is just 1, backgrounds is 501h, player characters are 0h. There might be other values, I don't know.
Now the second group. Script headers. Just like it is in text files and AI script blocks, these point to a raw memory address within the file to a script that defines an animation group for an actor. These don't get stored anywhere. Instead they are translated, but I'll mention that later. There are no more than 74 scripts in these files. Players use all of these, while enemies typically need less than 20, though those are bosses.
The file group is the actual animation scripts. These are pretty powerful scripts that control a lot about the actors. For example, using an item plays three different animations from the da file. One is hopping foward, one is tossing the item, and the last is hopping back to position. These scripts will merge all three of the actions while setting new positions, orientations and, in some cases, speed and even volume.
There are 113 opcodes ranging from 8E - FF inclusive. Some take arguments some don't. I'm still going through them. If it comes across something less than 8E it will assume it's a defined animation and attempt to execute that animation index from the **da file. If it doesn't find it...well....bad things will happen. So codes, like B2 and C9, do absolutely nothing and are skipped over and even sometimes picked up later.
For example, most enemy animation 0 (the idle animation) scripts look like this:
--- Code: ---A9 C9 00 C1
--- End code ---
A9 takes two parameters, but completely ignores the first one. The second one gets mapped to 0xBE1186 (It's probably safe to assume that's the **da animation that will serve as the idle animation for that actor).
Now we're at C1. It's function is to find the C9 value and treat that as the next code. It will then set the animation script location at the first C9 it finds in that script. So C9 and C1 are like a loop (although C9 by itself does nothing). There might be something similar to B2 because it doesn't have a function either.
If anyone wants to help me derive the functions of these codes or functions of the header values feel free. The function that handles all this starts at 0x41FBA4 with the individual opcode handler addresses starting at 0x4248C2. First one of those handles 8E, the second handles 8F and so forth. Some are shared like 9A and FB.
I almost forgot, the translations. For the script pointers and the few dwords in the header, they get translated into RAM addresses after being loaded into memory. So if something points at 0x190 within the file, it may get translated to 0x3492A8F or wherever that file's location ends up in memory. It will still point to the same location within the file that it pointed to before so all the unique pointers will point to different places. I hope I explained that adequately.
DLPB_:
8) Good progress! I'd help but bogged down with 100 things. Good luck with it :)
nfitc1:
This is like 100 NEW things to do. :(
DLPB_:
Come on Square, give us the bloody source code (when you find it).
Lazy Bastard:
--- Quote from: NFITC1 on 2013-04-18 15:30:03 ---So I put my mind to it yesterday and I found out quite a bit about those elusive **ab files in the battle.lgp archive (I don't know the PSX equivalent).
--- End quote ---
The PSX equivalent is the actual battle model (*.LZS) file section named Model Settings Data by Akari (a nomenclature I carried over into my battle model breakdowns on the forums and wiki).
I didn't get a chance to dig around at all last night, but I'll try to make time to do so tonight. This will certainly make custom battle models with proper animations much easier to create. Glad I could nudge you into uncovering a crucial part of the battle module :)
Navigation
[0] Message Index
[#] Next page
Go to full version