Sidebar
Table of Contents
HAR File Format (.AF)
The AF files contain all the information related to HARs; sprites, key-combos, projectile sprites, base damage, etc. The format is not entirely understood but a large portion has been dissected and understood. All AF files are broken up into the following sections:
Fighter Header
This contains the basic data about the HAR. Unmodified speeds, endurance, power, etc.
| HAR Number | 1 WORD | Must be the same number as in the filename eg: FIGHTR1.AF |
| Unknown Data | 2 bytes | Always 10, Timing window for executing special moves, 1 for very small window, 100 for very large |
| Endurance | 4 bytes | Stun resistance Bar. Max is 548,801,280. Above or below that results in permanantly stunned state. Multiplied by 3.6 after loading |
| Unknown Data | 1 byte | Usually 2, exceptions from 1-50 |
| Power | 1 WORD | Health or Hit Points, max is 8717. |
| Forward Speed | 1 signed DWORD | Speed at which the HAR moves towards opponent |
| Backward Speed | 1 signed DWORD | Speed at which HAR retreats from opponent |
| Upward Speed | 1 signed DWORD | Initial jump speed, this should be negative. Outside tournament mode, used value = 256 * (upward speed / 256 + jump height (in advanced menu) / 100) |
| Downward Speed | 1 signed DWORD | How quickly the HAR falls while being airborne, should be positive |
| Unknown Data | 1 byte | ? Always 0x32 |
| Unknown Data | 1 byte | ? Always 0x14 |
There then follow a number of blocks. Each block starts with a one byte animation number.
| Animation Number | 1 BYTES | Unique Identifier for animation (less than 70), end of animations (>= 70) |
If this value is less than 70, then an Animation and a Move footer follows. A value of 70 or higher marks the end of animations, and the fighter footer follows.
Animation
Animation Header
| X Start | 1 SIGNED WORD | Initial X position of sprite (unless spawned from another animation) |
| Y Start | 1 SIGNED WORD | Initial Y position of sprite (unless spawned from another animation) |
| Unknown Data | 4 BYTES | ??? - Seems to be [00 00 00 00] in all AF and BK files. Maybe just UDWORD null ? |
| Overlay Amount | 1 WORD | Number of DWORDS in the Overlay Table |
| Frame Count | 1 BYTE | How many frames in this animation |
| Collision Coordinate Table | N DWORDS | Contains the collision data. Check below for more info. |
Collision coordinate table
The following applies for every DWORD in collision coordinate table.
| Coordinate frame information | 6 bits | Frame index for x,y coordinate |
| Y coordinate | 10 bits | Y coordinate for the collision point |
| NULL | 6 bits | Always 0 ? |
| X coordinate | 10 bits | X coordinate for the collision point |
So, for the current frame, you look at the collision table and use any points with the index for the current frame. The frames are 0 indexed.
Animation String Header
| String Length | 1 WORD | Length of the string |
| String | N BYTES | Animation String |
| Unknown Data | 1 BYTE | Nul terminator |
| Number of Extra Strings | 1 BYTE | How many other animation strings there are |
There then follow N extra animation strings, where N was the number specified in the Animation String Header. The extra strings are stored as follows:
Extra Animation Strings
| String Length | 1 WORD | Length of string |
| String | N BYTES | Extra Animation String |
| Unknown Data | 1 BYTE | Nul terminator |
Sprites
There then follow N sprites, where N is the frame count specified in the animation header, followed by the animation footer.
See Sprite format for the format of the sprites.
Move Footer
The first 21 bytes of the animation footer have an unknown purpose. Some possibilities are listed.
(Note: Unknown 1 & 3 removed, since they seem to be part of WORD Unk 0 and WORD Unk 2)
| Unknown 0 | 1 WORD | AI related bitmap ? |
| Unknown 2 | 1 WORD | Seems to be related to airborne attacks, possibly constraints for positioning (near wall, etc) |
| 0x1 Must be close to a wall | ||
| 0x2 Must be airborne | ||
| 0x4 Must be close to other HAR ? | ||
| 0x20 ? | ||
| 0x40 scrap/destruction constraint ? | ||
| 0x2000 scrap/destruction/fire+ice ? | ||
| 0x4000 scrap/destruction/fire+ice ? | ||
| Unknown 4 | 1 BYTE | Not used ? |
| Unknown 5 | 1 BYTE | Not used ? |
| Unknown 6 | 1 BYTE | Not used ? |
| Unknown 7 | 1 BYTE | Not used ? |
| Unknown 8 | 1 BYTE | Not used ? |
| Unknown 9 | 1 BYTE | Not used ? |
| Unknown 10 | 1 BYTE | Not used ? |
| Unknown 11 | 1 BYTE | Not used ? |
| Unknown 12 | 1 BYTE | Next animation to play, if the current one hit |
| Unknown 13 | 1 BYTE | Animation Category |
| 0 - Misc. | ||
| 2 - Close Quarters/Throw | ||
| 4 - 'Low', 'l' tags | ||
| 5 - 'Medium', 'm' tags | ||
| 6 - 'High', 'h' tags | ||
| 7 - Jumping, 'j' tags | ||
| 8 - Projectile, 'p' tags | ||
| 9 - Basic | ||
| 11 - Victory/Defeat | ||
| 12 - Scrap | ||
| 13 - Destruction | ||
| These are just educated guesses, but they are definitely used by OMF to decide which animation to play when a player uses a specific key combo. | ||
| Unknown 14 | 1 BYTE | Health/damage related ? |
| Unknown 15 | 1 BYTE | Time to keep enemy stunned on block (Blockstun) |
| Pushback is applied during blockstun and the amount is calculated based on the duration | ||
| Unknown 16 | 1 BYTE | The successor animation id |
| Unknown 17 | 1 BYTE | Damage (Value divided by 2.0) |
| Unknown 18 | 1 BYTE | Some sort of special animation selection. Maybe corner case fix of some sort ? Only used in collision handling. |
| 0x20 - Move HAR backwards to fix overlap | ||
| Unknown 19 | 1 BYTE | Extra string selection flag, describes which speed modifier should be used to select extra string. 1 = Arm, 2 = Leg, 3 = Special arm, 4 = special leg, 5 = arm+leg or some combination ? |
| Unknown 20 | 1 BYTE | Points if this move hits, in hundreds (Multiplied by 4 after loading) |
| Move String | 21 BYTES | Move String NULL terminated (trailing data after the first NULL seems to be reusable to label animations) |
| Footer String Length | 1 WORD | Length of footer string |
| Footer String Length | N BYTES | Animation string for animation 9 on the other HAR if this move 'hits' |
Big-Footer
| Unknown | 1 BYTE | ??? - 0 in all known AF/BK files. An animation tag of 's0' does not seem to play the sound stored in this byte. |
| Sounds | 29 BYTES(?) | Sound mapping table - when an animation string contains a tag like 's<n>', OMF looks at the Nth element of this table, which contains the ID of the sample to play from SOUNDS.DAT (numbered starting from 1, not 0). For example, INTRO.BK contains multiple instances of the 's1' tag. Position 1 in this table for INTRO.BK contains '15', which is the ID of the thunderclap sound in SOUNDS.DAT. |
For all known AF files, the last 5 bytes are FGHED, which correspond to sounds 70, 71, 72, 69 and 68.
Sample Implementations
- Link removed on request by Vagabond.
Magic Numbers
To check if a file is a valid AF file, there are 2 magic sequences you can check for:
- Seek to the -31st byte (the 31st byte before the end of the file). The value is 250 for all known AF files, and is required to be >= 70.
- The last 5 bytes in the file are the string 'FGHED'. This is the case for all known AF files.
