AFS (File format): Difference between revisions

Latest revision as of 13:18, 7 October 2023

This article is about the AFS file format. See AFS (Gotcha Force) for current research on Gotcha Force AFS.

This file format is almost completely documented.
The structure of this file is well known.

The AFS file format allows to pack a group of files sometimes in folders in one unique file. There is no compression. Each element (packed files or AFS system files) is aligned to block of 0x800 bytes. Except for packed files AFS system files are in Little Endian.

An AFS file can be divided into 4 parts:

The Header:

Offset	Value	Observation
0x0	u32	Magic number = "AFS\x00" or "AFS\x20"
0x4	u32	Total number of packed files

The Table Of Content (TOC):
- It's an array of couples:
  - 4 bytes: file offset
  - 4 bytes: file length
- After this array we can find 3 configurations:
  - We find the offset of the Filename Directory (FD) (4 bytes) and its length (4 bytes).
  - We find a padding (NULL bytes) and then the offset of the FD (4 bytes) and its length (4 bytes).
  - There is no FD (no offset nor length).
The files area containing all packed files
Le Filename Directory (FD) where we found for each file:
- 32 bytes: file name or path padded with NULL bytes
- 2 bytes: years
- 2 bytes: months
- 2 bytes: days
- 2 bytes: hours
- 2 bytes: minutes
- 2 bytes: seconds
- 4 bytes: in some AFS we found the length of the file, in some others we found file_offset, file_len, file_offset, file_len ... for every file entry of the FD taking TOC entries in the order. And finally in some AFS this field has a fixed value or random values.

The FD is not present in all AFS. When present we can find multiple files with the same names and sharing sames data areas or not. The filename can also contain relative or absolute file paths "../data/file" like found in the game "Kidou Senshi Gundam - Gundam vs. Z Gundam (Japan)".

The AFS is handled by the main executable (boot.dol). So in theory files could be retrieved by 3 different ways that could also be mixed:

Get the file by index: the index of the offset/length in the TOC.
Get the file by name in the FD.
Get the file by a relative offset from the start of the AFS / somewhere in memory / DVD. This method is conceivable since align is the same for multiple file format packed in the DVD: MDT/PZZ and AFS (0x800). The retrieval of the length would be easy using different methods (headers and so on.).

The Virtual World RE afstool.py allow rebuilding the AFS by adding a folder tree and changing every parameters with 4 rebuild strategies: auto, index, offset, mixed.

@@ Line 1: / Line 1: @@
-__toc__
+[[Gotcha Force | &larr; Gotcha Force]]
-== Format ==
+''This article is about the AFS file format. See [[AFS (Gotcha Force)]] for current research on Gotcha Force AFS.''
-== Nommage des fichiers ==
+{{Research | 1| The structure of this file is well known. }}
-Fichiers compris dans afs_data.afs  :
+The AFS file format allows to [http://wiki.xentax.com/index.php/GRAF:AFS_AFS pack a group of files sometimes in folders in one unique file]. There is no compression. Each element (packed files or AFS system files) is aligned to block of 0x800 bytes. Except for packed files AFS system files are in Little Endian.
+An AFS file can be divided into '''4 parts''':
+# The Header:
 {| class="wikitable"
+! Offset !! Value !! Observation
 |-
-! Nom
+| 0x0||u32||  Magic number = "AFS\x00" or "AFS\x20"
-! Description
 |-
-| pl####.pzz
+| 0x4||u32|| Total number of packed files
-| Décrit chaque borg ('''Pl'''ayer Character)
-|-
-| mnxxxx.tpl
-| Noms des borgs dans les '''M'''e'''n'''us (206)
-|-
-| st##.pzz
-| Comprennent en position 1,2,3 les fichiers hitsxx.bin
-|-
-| firstld.pzz
-| Utilisation liée à la carte mémoire ('''First l'''oa'''d''' - Image de la carte mémoire inclue dans le pzz)
-|-
-| icon.bin
-| Identique à firstld\003C_firstldicon.bin - Icone 3D pour l'image de la carte mémoire
-|-
-| facexxxx
-| Décrivent les NPC du jeu et les prop utilisé lors de la touche spécial
-|-
-| itxxxx_mdl.arz
-| (90 fichiers) - '''It'''em Data Crystal -> le numéro xxxx correspond à chaque fois à un borg qui demande plusieurs Data Crystal
-|-
-| setxxxx.arc
-! (61 fichiers) ?
 |}
+# The '''Table Of Content''' (TOC):
+#* It's an array of couples:
+#** 4 bytes: file offset
+#** 4 bytes: file length
+#* After this array we can find 3 configurations:
+#** We find the offset of the Filename Directory (FD) (4 bytes) and its length (4 bytes).
+#** We find a padding (NULL bytes) and then the offset of the FD (4 bytes) and its length (4 bytes).
+#** There is no FD (no offset nor length).
+# The files area '''containing all packed files'''
+# Le '''Filename Directory''' (FD) where we found for each file:
+#* 32 bytes: file name or path padded with NULL bytes
+#* 2 bytes: years
+#* 2 bytes: months
+#* 2 bytes: days
+#* 2 bytes: hours
+#* 2 bytes: minutes
+#* 2 bytes: seconds
+#* 4 bytes: in some AFS we found the length of the file, in some others we found file_offset, file_len, file_offset, file_len ... for every file entry of the FD taking TOC entries in the order. And finally in some AFS this field has a fixed value or random values.
-L'investigation mené par la communauté de [https://zenhax.com/viewtopic.php?t=13419 GioGio Bizarre Adventure] montre une certaine logique qui peut potentiellement être utilisée dans le nommage des fichiers interne de afs_data.afs :<br>
+The FD is not present in all AFS. When present we can find multiple files with the same names and sharing sames data areas or not. The filename can also contain relative or absolute file paths "../data/file" like found in the game "Kidou Senshi Gundam - Gundam vs. Z Gundam (Japan)".
-<br>
- '''d#####.pzz''' - Character and/or prop data for 3D Cutscenes
- '''pl##p.pzz''' - Character specific props
- '''pl##.hit''' - Character collision data
- '''st###.pzz''' - Stage model data
-Fichiers absents :
- files containing "'''tbl'''" in the filename seem to be animations
- '''ga00p''' - Gallery room (several textures and models in here
- '''ball.pzz''' - Seems to just be a sphere model with a 32x32 blank texture
- '''re00.pzz''' - Results screen
- '''dcomn.pzz''' - Speech bubbles, onomatopoeia, zoom lines and others
- '''ld###.pzz''' - Loading screen model and textures (they're just planes)
- '''demo.pzz''' - Title screen textures (can be used to decompress data)
- '''se###.pzz''' - Stage props
- '''lw###.pzz''' - Stage collisions
- '''npc###.pzz''' - NPC files
- '''ks##.pzz''' - 2D Drama cutscene data (panels are 3D models)
- '''k###.pzz''' - 2D cutscene data (panels are 3D models)
-=== Observations ===
-Pour chaque borg on a :<br>
- plxxxx.pzz
- plxxxxdata.bin  <- position 0 du pzz (fichier pouvant être nommé data2 ou data3, parfois absent de l'afs_data)
- plxxxxhit.bin   <- position 2 du pzz (toujours présent dans l'afs_data et le pzz)
- plxxxxmot.bin   <- position 3 du pzz (souvent absent de l'afs_data)
- plxxxx_mdl.arc  <- position 4 du pzz (parfois absent de l'afs_data)
- plxxxxb_mdl.arc <- position 5 du pzz (parfois absent de l'afs_data)
- plxxxxg_mdl.arc <- position 6 du pzz (parfois absent de l'afs_data)
- plxxxxs_mdl.arc <- position 7 du pzz (parfois absent de l'afs_data)
- plxxxxc_mdl.arc <- position 8 du pzz (parfois absent de l'afs_data)
- plxxxxk_mdl.arc <- position 9 du pzz (parfois absent de l'afs_data)
-Position 000 : pour pl0604 et quelques autres borgs il s'agit de pl0604data2.bin ou plxxxxdata3.bin (seul un des trois data est présent, jamais deux, et ce fichier data2 ou data3 est identique au fichier data du pzz->000). (Version NTSC)
-Position 002 : pour le borg pl0507 et pl0513, le fichier 2 et le hit diffèrent. (Version NTSC)
-Position 003 : pour le borg "pl0009", le fichier 3 et le mot diffèrent. (Version NTSC) (Mot - '''Mo'''uvemen'''t''') - On peux observer que pour ces fichiers, on retrouve des références pouvant faire penser à de l'animation '''plxxxx_xx_animjoint'''.  L'investigation mené par la communauté de [https://smashboards.com/threads/melee-dat-format.292603/ Smash Bros Brawl] montre une structure de fichier similaire. Il s'agit d'une autre version de HSD (Les structures de bases sont les mêmes).
+The AFS is handled by the main executable (boot.dol). So in theory files could be retrieved by 3 different ways that could also be mixed:
+* Get the file by index: the index of the offset/length in the TOC.
+* Get the file by name in the FD.
+* Get the file by a relative offset from the start of the AFS / somewhere in memory / DVD. This method is conceivable since align is the same for multiple file format packed in the DVD: [[MDT (Gotcha Force)|MDT]]/[[PZZ (Gotcha Force)|PZZ]] and AFS (0x800). The retrieval of the length would be easy using different methods (headers and so on.).
-Position 004 à 009 : contiennent '''"scene_data"''' en fin de section data, et sont des fichiers ''''"Scène"''' (HSDLib) qui contiennent les lumières, les caméras, les vertices, les bones à la manière d'un .blend.
+The Virtual World RE [https://github.com/Virtual-World-RE/NeoGF/tree/main/afstool afstool.py] allow rebuilding the AFS by adding a folder tree and changing every parameters with 4 rebuild strategies: auto, index, offset, mixed.
-pl0803 - pl080b - pl0f07 :
+[[Category:File format]]
-Il reste uniquement le fichier pl0803hit.bin et pl080bhit.bin et aucun de leurs fichiers associés (notamment, pas de pzz associé), ce qui indique qu'ils sont à priori des restes de borgs non implémentés ... De même que le pzz pl0f07 n'a pas son fichier hit, ni ses 4 TPL internes (4 fichiers vides à la place) mais juste son fichier pl0f07_mdl.arc, ce qui indique que ce borg n'est pas implémenté non plus. (Version NTSC).
+[[Category:Gotcha Force]]