Difference between revisions of "HAR File Format (.AF)"

From WTFwiki
Jump to navigation Jump to search
 
(41 intermediate revisions by 5 users not shown)
Line 8: Line 8:
 
|HAR Number || 1 WORD || Must be the same number as in the filename eg: FIGHTR1.AF
 
|HAR Number || 1 WORD || Must be the same number as in the filename eg: FIGHTR1.AF
 
|-
 
|-
−
|Unknown Data || 3 bytes || ?
+
|Unknown Data || 2 bytes || ? Always 10
 
|-
 
|-
−
|Endurance || 3 bytes || Max is 2,143,755. Above or below that results in permanantly stunned state.
+
|Endurance || 4 bytes || Max is 548,801,280. Above or below that results in permanantly stunned state. Multiplied by 3.6 after loading
 
|-
 
|-
−
|Unknown Data || 1 byte || ?
+
|Unknown Data || 1 byte || ? Always 1 or 2
 
|-
 
|-
 
|Power || 1 WORD || Damage Resistance, max is 8717.
 
|Power || 1 WORD || Damage Resistance, max is 8717.
Line 20: Line 20:
 
|Backward Speed || 1 signed DWORD || Speed at which HAR retreats from 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
+
|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
 
|Downward Speed || 1 signed DWORD || How quickly the HAR falls while being airborne, should be positive
 
|-
 
|-
−
|Unknown Data || 1 WORD || ?
+
|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''.
 +
{| border="1"
 +
|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 ==
−
 
−
When reading in an animation, check if the next byte (the Animation Number) is less than 250. If its '''not''' less than 250, read in the fighter footer instead.
 
  
 
=== Animation Header ===
 
=== Animation Header ===
 
{| border="1"
 
{| border="1"
−
|Animation Number || 1 BYTES || Unique Identifier for animation (less than 250)
+
|X Start || 1 SIGNED WORD || Initial X position of sprite (unless spawned from another animation)
 
|-
 
|-
−
|Unknown Data || 8 BYTES || Zero padding?
+
|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 || TODO
 
|Overlay Amount || 1 WORD || TODO
Line 47: Line 55:
 
=== Animation String Header ===
 
=== Animation String Header ===
 
{| border="1"
 
{| border="1"
−
|String Length || 1 DWORD || Length of the string
+
|String Length || 1 WORD || Length of the string
 
|-
 
|-
 
|String || N BYTES || [[Animation string]]
 
|String || N BYTES || [[Animation string]]
 
|-
 
|-
−
|Unknown Data || 1 BYTE || ?
+
|Unknown Data || 1 BYTE || Nul terminator
 
|-
 
|-
 
|Number of Extra Strings || 1 BYTE || How many other animation strings there are
 
|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 ===
 
=== Extra Animation Strings ===
Line 63: Line 72:
 
|String || N BYTES || Extra [[Animation string|Animation String]]
 
|String || N BYTES || Extra [[Animation string|Animation String]]
 
|-
 
|-
−
|Unknown Data || 1 BYTE || ?
+
|Unknown Data || 1 BYTE || Nul terminator
 
|-
 
|-
 
|}
 
|}
Line 69: Line 78:
 
=== Sprites ===
 
=== Sprites ===
  
−
There then follow N sprites, where N is the frame count specified in the animation header.
+
There then follow N sprites, where N is the frame count specified in the animation header, followed by the animation footer.
−
 
 
−
==== Sprite Header ====
 
−
 
 
−
{| border='1'
 
−
|Length || 1 WORD || Length of sprite
 
−
|-
 
−
|X Position || 1 SIGNED WORD || TODO
 
−
|-
 
−
|Y Position || 1 SIGNED WORD || TODO
 
−
|-
 
−
|Width || 1 WORD || Width of the sprite, in pixels
 
−
|-
 
−
|Height || 1 WORD || Height of the sprite, in pixels
 
−
|-
 
−
|Mirrored || 1 BYTE || Is the sprite Mirrored
 
−
|-
 
−
|}
 
−
 
 
−
If the sprite's mirrored value is '''non''' zero, the sprite data appears elsewhere and the sprite data is fetched from the sprite whose '''index''' value is the current's sprite's ''mirrored'' value.
 
  
−
==== Sprite Data ====
+
See [[Sprite format]] for the format of the sprites.
−
If the sprite is '''not''' mirrored, Length bytes of sprite data follow. The sprite data is decoded thusly:
 
  
−
* Initalize X and Y to 0
+
== Move Footer ==
−
* Read 1 WORD as P
 
−
* Modulus P by 4 to get OPCODE
 
−
* Integer divide P by 4 to get DATA
 
−
* Compare the OPCODE against the following and take that action
 
−
<ol start="0">
 
−
<li>Set X to DATA</li>
 
−
<li><ul><li>While DATA is greater than 0</li><ul><li>Read 1 BYTE</li><li>Store that byte as the pixel at X,Y in the sprite</li><li>Increment X</li><li>Decrement DATA</li></ul></ul></li>
 
−
<li>Set Y to DATA</li>
 
−
<li>End of sprite data</li>
 
−
</ol>
 
−
 
 
−
=== Animation Footer ===
 
 
The first 21 bytes of the animation footer have an unknown purpose. Some possiblities are listed.
 
The first 21 bytes of the animation footer have an unknown purpose. Some possiblities are listed.
 
{| border='1'
 
{| border='1'
Line 134: Line 111:
 
|Unknown 13|| 1 BYTE|| Next animation to play?
 
|Unknown 13|| 1 BYTE|| Next animation to play?
 
|-
 
|-
−
|Unknown 14|| 1 BYTE||
+
|Unknown 14|| 1 BYTE|| Animation Category
 +
* 0 - Misc.
 +
* 2 - Close Quarters/Throw
 +
* 4 - Crouching?
 +
* 5 - Standing?
 +
* 6 - Standing? Walking backward?
 +
* 7 - Airborne
 +
* 8 - Projectile
 +
* 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 15|| 1 BYTE|| [[HAR_File_Format#Animation_Categories|Animation categories]]
+
|Unknown 15|| 1 BYTE||
 
|-
 
|-
 
|Unknown 16|| 1 BYTE|| Stamina damage?
 
|Unknown 16|| 1 BYTE|| Stamina damage?
Line 148: Line 138:
 
|Unknown 20|| 1 BYTE||
 
|Unknown 20|| 1 BYTE||
 
|-
 
|-
−
|Unknown 21|| 1 BYTE||
+
|Unknown 21|| 1 BYTE|| ? Multiplied by 4 after loading
 
|-
 
|-
−
|Move String|| 21 BYTES|| [[HAR_File_Format#Move_String|Move String]]
+
|Move String|| 21 BYTES|| [[HAR_File_Format#Move_String|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||1 WORD || Length of footer string
Line 157: Line 147:
 
|}
 
|}
  
−
==Fighter Footer==
+
==Footer==
  
 
{|border='1'
 
{|border='1'
−
|Magic Number || 1 BYTE || '''Always''' 250
+
|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.
 
|-
 
|-
−
|Filler? || 9 BYTES || ?
+
|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.
−
|-
+
 
−
|Footer Length || 1 WORD || -
+
For all known AF files, the last 5 bytes are FGHED, which correspond to sounds 70, 71, 72, 69 and 68.
−
|-
 
−
|Footer || N BYTES || ??
 
 
|}
 
|}
 +
 +
== Sample Implementations ==
 +
 +
[[PythonAfBkParser|Sample python parser for .af and .bk files]]
 +
 +
==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.

Latest revision as of 19:16, 8 January 2013

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
Endurance 4 bytes Max is 548,801,280. Above or below that results in permanantly stunned state. Multiplied by 3.6 after loading
Unknown Data 1 byte ? Always 1 or 2
Power 1 WORD Damage Resistance, 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 TODO
Frame Count 1 BYTE How many frames in this animation
Overlay Table N DWORDS TODO

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 possiblities are listed.

Unknown 1 1 BYTE
Unknown 2 1 BYTE
Unknown 3 1 BYTE Seems to be related to airborne attacks, possibly constraints for positioning (near wall, etc)
Unknown 4 1 BYTE
Unknown 5 1 BYTE
Unknown 6 1 BYTE
Unknown 7 1 BYTE
Unknown 8 1 BYTE
Unknown 9 1 BYTE
Unknown 10 1 BYTE
Unknown 11 1 BYTE
Unknown 12 1 BYTE
Unknown 13 1 BYTE Next animation to play?
Unknown 14 1 BYTE Animation Category
  • 0 - Misc.
  • 2 - Close Quarters/Throw
  • 4 - Crouching?
  • 5 - Standing?
  • 6 - Standing? Walking backward?
  • 7 - Airborne
  • 8 - Projectile
  • 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 15 1 BYTE
Unknown 16 1 BYTE Stamina damage?
Unknown 17 1 BYTE Seems to be related to throws, maybe velocity of victim?
Unknown 18 1 BYTE Damage (Value divided by 2.0)
Unknown 19 1 BYTE
Unknown 20 1 BYTE
Unknown 21 1 BYTE ? 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 Footer string

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

Sample python parser for .af and .bk files

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.
Retrieved from "http://wtf.hijacked.us/wiki/index.php?title=HAR_File_Format_(.AF)&oldid=1197"